Consulting Journal: Trends - Vendor-specific extensions in CSS3

Trends: Vendor-specific extensions in CSS3

by David Blakey

The benefits and dangers of vendor-specific extensions in CSS3.

[Monday 25 October 2004]

Now, in October 2004, the World Wide Web Consortium, www.w3.org, has several draft specifications for CSS3. One of these is that the syntax for identifiers should allow vendor-specific extensions. You can click here to view the draft.

How they work

This means that Mozilla can implement the identifier -moz-border-radius. The prefix -moz- identifies it as a Mozilla implementation of the identifier border-radius. There are several uses for these vendor-specific extensions. One use is in company intranets. An intranet at the Consulting Journal could use -cj- for extensions written specifically for us. Another use is in browsers, for testing new features of CSS that have not reached the status of a Recommendation. A browser could use -moz- for testing proposed features of CSS3. This is exactly what -moz-border-radius is. The border-radius property is in the CSS3 draft.

This seems like a good idea. Mozilla, or any other browser developer, could include new features in their browsers before those features were officially included in the specifications. Then, when the features were accepted, they could be implemented rapidly in the next version of the browser. Mozilla could easily change -moz-border-radius to border-radius.

There are some problems.

What might happen

The draft recommendation for CSS3 has a different format for the border-radius property than the one implemented by Mozilla. The specification allows for two radiuses, one horizontal and the second vertical. Mozilla only allows for one. Bear in mind that Mozilla intends -moz-border-radius only for its internal testing. Nonetheless, keen Web developers are likely to use it. And if only one radius is specified, then it is applied to both the horizontal and the vertical. Anyone who is happy with -moz-border-radius:10px; will be happy with border-radius:10px;

It is unlikely that a developer would produce an implementation that offered more options than the recommendation. It is possible, though, that the recommendation could be changed before its final version. These changes could remove features from an earlier draft. A developer of vendor-specific features that were based on the earlier draft would have two options.

They could remove the additional features in preparation for the final specification. This would keep their implementation in line with the specification. Eventually, anyone who had tested using the -xyz- prefix could be able to remove the prefix, and their code should then comply with the specifications.
They could retain the vendor-specific features. This would mean that anyone who wanted to use those features would have to continue using the -xyz- prefix.

If we take this second scenario into its worst case, let us use an example. Assume that two color properties, property-a and property-b are under consideration and that XYZ includes them both for testing as -xyz-property-a and xyz-property-b. Now we shall assume that property-b has some features removed for the final specification but that XYZ wants to keep those features. Then, when the specification was finalized, the proper way to code the CSS would be

property-a:yellow;
-xyz-property-b:red white blue;

Imagine now if other browser developers had implemented their own features for one of these properties. Anyone who wished to use these features could have several statements.

property-a:yellow;
-abc-property-a:yellow green;
-def-property-a:yellow green;
-abc-property-b:red white blue;
-def-property-b:red white blue;
-xyz-property-b:red white blue;

This worst case would put us back into the bad old days of browser-specific features.

What I recommend

There will always be a temptation for Web developers to read new draft specifications and to imagine ways in which they could use the new features. This is good. Web developers should be looking for new ways to enhance their clients' sites.

It is also good for Web developers to practise using the new features, if a browser contains vendor-specific features that will allow them to do so. So, using Firefox, developers can experiment with the border-radius property and see where it will work well and where they should avoid it.

But Web developers should remember that they are working with alpha versions. The CSS3 features have been implemented in Firefox for Mozilla's own testing. They are unannounced, despite most Web developers knowing about them. So, quite simply, they should not be in the code for clients' sites.

For consultants, this means that there is another item on their list when they review site coding. It is good that these pre-release features are available in some browsers. It is not good if they are used on Web sites.

[ List articles on Trends ] [ View printable version ]