Bruce Lawson's personal site

Here’s a quick tutorial (actually, rant) that came out of an aside I mentioned when doing my talk for Future of Web Design two weeks ago.

It came about when I was using the IE9 preview to test some sites. I noticed that a site that boasts rounded corners didn’t appear to have them in IE9, even though IE9 allegedly has border-radius support.

“Silly IE9”, I thought.

Wrong. Silly developer.

The difference between a pro developer and a wannabe is that the pro developer makes sites that are cross-browser and, as far as possible, future-proof. By contrast, the wannabe assumes that everyone is the same as him and therefore if the site works on the browsers he uses, that’s enough.

Our wannabe developer’s code looked like this

-moz-border-radius: 6px;
-webkit-border-radius: 6px;

By using only vendor prefixes, the wannabe developer ensures that this nice part of the design will only work on those browsers.

A pro, however, cares about his client so doesn’t leave them with a site that will need changing later. A pro cares enough about his site’s users to give the design to their browser and let it do with it as it will.

How?

Simply by adding the non-prefixed cross-browser version of the property, he can add border-radius support for IE9 now, Opera now and any new browser that comes along in the future:

-moz-border-radius: 6px;
-webkit-border-radius: 6px;
border-radius: 6px;

In the above example, border-radius is pretty mature, so IE and Opera jumped straight to using the standard prefix-less property, but other fancy CSS 3 properties are implemented only with vendor prefixes at the moment. Note I said “at the moment”; in two years’ time, a new browser may consider that feature stable enough to implement without a vendor prefix and, because you’re a pro rather than a wannabe, you want to ensure your code works in 2 years time as well as today.

For maximum compatibility, I advise adding all vendor prefixes (I do it in alphabetical order to help me remember) plus the non-prefixed version.

So here’s a version that future-proofs and cross-browserifies™ CSS3 transforms:

-moz-transform: scale(1.6);
-ms-transform: scale(1.6);
-o-transform: scale(1.6);
-webkit-transform: scale(1.6);
transform: scale(1.6);

If, for example, IE adds support for the prefixless version, or uses the -webkit- version, you have one line—27 bytes—of redundancy. So what? And now your code works everywhere that has support, today and tomorrow.

And that’s how it should be.

I feel very strongly that using JavaScript to remove all that extra CSS away is a bad idea. Apart from the absurdity of using “20kb minified js to avoid 5kb ‘untidy’ CSS” (as one person commented about eCSStender), it’s ducking responsibility. If you as a developer choose to use experimental, pre-standardised code on a production site, then you need to live with the consequence of that choice. There’s no getting around it: experimental, pre-standardised code is susceptible to change. If the specification changes, you’ll need to change your CSS (which is easier to do if it isn’t being hidden away by some library).

See -o- vendor prefixed CSS supported in Opera 10.50, also Vendor-prefixed CSS Property Overview which compares vendor prefixes across browsers.

Resources

(Added Nov 2011)

• Prefixr – web utility that adds all the prefixes for you
• MSDN: A Best Practice for Programming with Vendor Prefixes

(Last Updated on 4 November 2011)

Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)

20 Responses to “ Writing cross-browser, future-proof CSS 3 ”

Leave a Reply