bioneural.net

So you fancy using some of that über-cool draft CSS3 that WebKit browsers can handle, such as text shadows, drop shadows, opacity and rounded corners? But at the same time you want to present only valid CSS to the W3C CSS Validator? It's a dilemma, but it is possible to have your cake and eat it too—albeit by hiding CSS in JavaScript and thus cheating the Validator. However, there is even a precedent for doing so.

During the course of researching my review of the various ways to make rounded corners, drop shadows, and gradients I learned more about CSS3 and the jQuery JavaScript library. They just needed introducing to one another.

Text shadows, drop shadows, and round corners in Safari 3

A historical precedent

The concept of tricking the Validator to pass CSS that is incorrectly implemented or proprietary and not part of the W3C spec is not new. Many web developers have found it necessary to employ various hacks in their CSS to accommodate differences in the way browsers interpret the rules. Others have used proprietary code to overcome limitations or quirks in the way some browsers handle certain content. For example, the following in your document head could be used to fix IE6's lack of handling for transparent PNGs and mis-handling of the box model, floats, overflow, italics, etc.:

<!--[if lte IE 6]>
	<style type="text/css">
	#pnglogo {filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(enabled='true',src='../logo-trans.png'); padding-top: 57px; }
	</style>
	<link rel="stylesheet" type="text/css" media="screen" href="../ie6-patches.css" />
<![endif]-->

It's a hack: there's no other term for it. In the above example we're using proprietary conditional comments and filters to fix proprietary cock-ups. Seems fair, doesn't it?

So, if we can hack our way to supporting inferior or out-dated browsers, why should we not also employ hacks to support leading-edge browsers like Safari 3 that are already capable of rendering much of that draft CSS3 goodness?

Using jQuery's CSS injector

There are probably multiple JavaScripts that let you load CSS via the DOM, but since I'm using jQuery anyway that's how I've chosen to do it. If you don't have jQuery installed go get it and load it in your document head e.g.:

<script type="text/javascript" src="../jquery-1.2.3.pack.js"></script>

Below this we create a $(document).ready() function so that the contents load via the DOM and hopefully before the page content is displayed. Inside this function our "content" consists of a series of CSS selectors (inside the first bracket) paired with the CSS properties we wish to inject (name and value, comma-separated) joined via .css. Example:

<!-- Have jQuery inject WebKit CSS via DOM on selected elements -->
<script type="text/javascript">
	$(document).ready(function(){
	$("h1").css("text-shadow","black 0.2em 0.3em 0.2em");
	$(".description").css("text-shadow","black 0.2em 0.3em 0.2em");
	$("#page").css("-webkit-box-shadow","#333 0px 5px 10px");
	$("#footer").css("-webkit-box-shadow","#333 0px 5px 10px");
	$(".container").css("-webkit-box-shadow","#333 0px 5px 10px");
	$(".container").css("-webkit-border-radius","10px");
});
</script>

If you had a div with the class "container koru", for example, Safari 3 will blend the above box-shadow and border-radius styling (as inline CSS3) with any additional CSS2.1 styling for .container or .koru present in your stylesheet. You can see what's going on using that browser's Web Inspector:

Note: A -webkit- or -moz- prefix on CSS properties is used respectively by the Safari and Mozilla/Firefox browsers to indicate tentative support for as yet non-ratified web standards. Thus -webkit-border-radius: 10px; and -moz-border-radius: 10px; are both potentially differing implementations of "border-radius".

OK, so the "how" is easy. Now the "Should you?"

The positives

Effects are rendered without requiring images.

Effects are rendered without requiring add-on JavaScript effects libraries.

Effects are rendered without increasing page size or load time.

Effects are rendered that may be impossible with some JavaScript or image-based techniques (e.g. anti-aliasing, liquid layout support).

Effects can be targeted at specific web browser engines.

No changes to semantic mark-up are required.

Your stylesheets remain W3C-valid (if they were before!).

Browsers simply ignore CSS properties they don't understand, so degradation is graceful.

If JavaScript is disabled browsers will still load your stylesheets, so degradation is graceful.

It is compatible with template-based websites in not requiring page-specific effects scripts to be inserted into mark-up.

When the -webkit- or -moz- prefix gives way to the real deal of W3C-ratified CSS3 we can simply remove the script and move the content to our stylesheet without having to re-design effects elements or edit any mark-up.

If you don't start using CSS3 now you might have retired before it becomes W3C-ratified.

The negatives

Turning off your stylesheet does not disable styling loaded via the DOM.

Effects can be targeted at specific web browser engines (like browser-targeting, a double-edged sword that undermines the uniformity of the "web experience").

It could be construed as cheating. It is.

What are your views, if you have any, on the merits or otherwise of this technique?

Actions Send this article link by e-mail Print this article without other content Follow responses to this article (comments feed) Share on Delicious Digg Facebook StumbleUpon Twitter Translate this page: DE | ES | FR Follow tag feeds: css, howto, Internet, javascript, jquery, webdev.