Breadcrumbs

Do We Really Need Proprietary CSS Properties?

Recently, I was working on a project that utilised Webkit's CSS transforms to create a cool effect as a little extra to anyone viewing the page in Safari. Firefox 3.1 will also introduce CSS transforms to Firefox. However, Webkit uses the -webkit-transform property and Firefox uses the -moz-transform property. The question I ask is: what is wrong with just transform? Do we really need proprietary CSS properties? Isn't that entirely counterintuitive to web standards?

Basically, the answer boils down to that, yes, proprietary CSS properties are ludicrous. I could understand having a proprietary CSS extension for something specific only to that particular browser, but that is not the case with CSS transforms. The same goes for things like border radii and opacity. It is almost nearly certain that these properties will be part of CSS 3's final implementation. Hence, it is not appropriate to implement them as proprietary CSS extensions.

In order to use a CSS rotation across web browsers, you have to use three properties:

Code: CSS

-moz-transform: rotate(-3deg);
-khtml-transform: rotate(-3deg);
-webkit-transform: rotate(-3deg);

Instead of just using transform:

Code: CSS

transform: rotate(-3deg);

Everyone is busy praising Webkit and Gecko for their "great" CSS 3 support, but what good is their implementation if it is done in a proprietary fashion? CSS 3 isn't a proprietary specification. If everyone could just implement web standards in an open, non-proprietary fashion that would be great. CSS really isn't the place for any proprietary rubbish.

Comments

  • I don't see the point in them either. Surely if they have implimented them correctly then there is no need to split them off into different names for each browser. This just makes it messy to use them. For example if Opera suddenly supports the transform attribute, it wont be able to make use of it on most sites that use it because they'll be using a webkit or mozzila only version of the attribute.

    Posted by Matt Oakes (external link) on Wed 18 Feb 2009 at 7:34

  • Both Webkit's (and Gecko's and KHTML's) implementation and the "working draft" are still rudimentary. I think it would be rather premature to remove vendor extensions for this one. I'm glad that Microsoft has finally adopted this practice (external link). I think it's crude to portray the situation as if all vendor prefixes are related to proprietary CSS extensions. If the specification changes, even if it's only a little bit, then webpages which are depending on this behavior will break, which wouldn't be pretty. You might say the same for vendor prefixed properties, but then you knew that you were using unfinalized business that's still prone to changes. The present implementations are what helps the spec to get better, after all.

    Posted by Frans (external link) on Wed 18 Feb 2009 at 11:49

  • The difference is that since these are draft specifications, no one is trying to use them in a non-draft way. Websites making use of these vendor specific prefixed properties are purely experimental. They aren't relying on some fixed behaviour of these properties. The behaviour is of course prone to change, developers understand that. My fear is that the practice of vender-specific prefixes is that the values won't move to their prefix-less intentions. CSS3 could very well become just a list of vender-specific prefixed properties at the current rate.

    Posted by Ethan Poole (external link) on Wed 18 Feb 2009 at 18:46

  • There are various -moz- and -o- properties from which the prefixes were removed when the draft became stable. Except from Microsoft perhaps, given the rate of their updates. But in that specific case I especially maintain my position.

    Posted by Frans (external link) on Thu 19 Feb 2009 at 3:47

  • I guess my main fear is Webkit, which seems to be the one integrating all the "CSS 3" stuff nowadays.

    Posted by Ethan Poole (external link) on Thu 19 Feb 2009 at 8:20