On the vendor prefixes problem

People have asked me to explain the vendor prefix problem. This is me (Bruce) explaining what I believe to be true (a couple of details are fuzzy to me, so forgive any errors – I’m trying to explain the concept). This is NOT a statement of Opera’s position or intents, so don’t be a dick and blame them for my opinions or mistakes.

Right.

On Monday at the CSS Working Group, Microsoft, Mozilla and Opera announced that each are considering supporting some -webkit prefixed CSS properties. (Search the minutes for “Vendor Prefixes”. Florian is from Opera, Tantek represents Mozilla, Sylvaing is Microsoft’s glamorous rep, and Tab is from Google. Glazou is Daniel Glazman and Plinss is Peter Linss, the two co-chairs of the Working Group.)

Lots of developers, despite evidence to the contrary, have assumed that mobile Web = WebKit browsers, because that’s the rendering engine in Android and iThings.

Suppose a developer made site a while ago and used the experimental, pre-standardised code -webkit-border-radius and didn’t use the cross-browser future-proof method.

The real CSS property border-radius has been long been standardised and supported without prefixes in all the major browsers. But the -webkit- prefixed version still lingers on in Safari and Chrome, so that legacy code looks fine in the webkit browsers, but broken in Opera, Firefox and Internet Explorer.

The webkit team have said that they won’t remove such legacy properties for compatibility reasons, and I haven’t heard howls of indignation about this. So the recent proposal is that non-webkit browsers will support -webkit-border-radius as if it were border-radius and thus won’t look “broken”.

I imagine that sites that only use -webkit-transition and -webkit-text-size-adjust etc will be similarly supported.

This is an approach suggested by Daniel Glazman, co-chair of the CSS Working Group:

The rule should be this one: if the CSS parser encounters a prefixed property for another browser, honour that property as if it were prefixed for us UNLESS an unprefixed or prefixed for us valid declaration for that property was already set.

Exactly which prefixes would be supported in this way and whether they would be the same in Opera, Microsoft and Firefox, I don’t know.

Personally – PERSONALLY – I’m pretty depressed about all this. I’ve spent 10 years – pretty much since IE6 came out – evangelising cross-browser, accessible, standards-based sites. As a development community we chased the Shiny and we caused IE6 to linger around like a vindaloo fart in a windowless loo. And now we’re doing the same again.

Daniel has put out a call to action for developers to fix their sites and mend their ways: CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*. Chris Heilmann of Mozilla has launched a community action called Pre-fix the web!. Read them. Join in. I truly hope they work (although fear it’s too late).

Comment if you like, but I won’t be able to moderate them for a few days, so better to write your own blog posts!

(added 18:45)

I should add that we will still need responsible developers using vendor prefixes right – this is not the end of vendor prefixes. From those who teach, from those who developers look up to, from those selling frameworksWe still need better, responsible evangelism and demos.

The proposal is to support a subset of -webkit- prefixes, especially the archaic stuff like -webkit-gradient, so that those sites don’t look dreadful in non-webkit browsers. The plan is not to support everything that the webkit devs pull out of their hats, every time they get the urge to extend CSS.

So, we still need to use cross-browser future-proof vendor prefixes if we decide to let experimental, pre-standardised code out on production sites.

(added 10 Feb 09:30)

Robert O’Callahan of Mozilla has a post on Alternatives To Supporting -webkit Prefixes In Other Engines which pretty accurately sums up the situation, too.

35 Responses to “ On the vendor prefixes problem ”

Comment by Peter Gasston

I don’t think it’s border-radius and transition that are at issue here; remove either of those and the site should function more or less fine without it (unless JS is being used with transition events, which is a whole other kettle of fish); it’s more properties like text-size-adjust, which can be actively prejudicial to the way a site displays to the user. As Tantek says, the idea is not to implement all -webkit- properties, but rather to weigh up which ones are harmful and decide on whether or not to implement those.

BTW, I wrote an overview of vendor prefixes on Ubelly the day before this all kicked off: http://www.ubelly.com/2012/02/vendor-prefixes-the-good-the-bad-and-the-ugly/

Comment by Neal G

Maybe the problem here (specifically text-size-adjust) is the way in which Webkit bull-rushes CSS properties without actually getting them into the standardization process (ahem, Microsoft, of the 90′s)

Innovation is great, and I really do like the idea and properties that they’re coming up with but perhaps they’re not going about it the best way?

Comment by Blog - Britoweb

Le monopole de fait d’un navigateur ou d’un moteur de rendu est nuisible au Web ouvert…

Il y a dix ans, les parts de marché d’Internet Explorer étaient écrasantes. Aujourd’hui, WebKit est un moteur de rendu particulièrement bien répandu….

Comment by Dave Smith

What if the CSS validator gave feedback more akin to “Property -webkit-border-radius is old-style-like-init-man, use border-radius the funk-grime-disco-core standard instead” rather than “Property -webkit-border-radius is an unknown vendor extension”? I wouldn’t need to know what has recently become a standard or not, but just run through the validator and voila, green light and notices on how to make the code more compatible/fab!

I’m encouraging more CSS validator use here, but truth is I don’t use it that often myself. Reason being that the experience of using it is sadly one of muh! Running a project through it produces loads of errors because of vendor prefixes and CSS3 properties. This makes it useless to me; I’m testing for CSS errors. True, there are options to validate in CSS3 or change vendor prefixes to warnings or off, but who wants to do this each time; the current defaults aren’t the expected ones, at least to me.

Otherwise I love it, especially when I get that special green light :D

Comment by David Corbacho

Your frontpage makes Firefox and Google chrome to freeze. Really annoying. I managed to load this page so I can post this comment. But you should look into it:
The console log showed this:
Failed to load resource: the server responded with a status of 404 (Not Found)
http://www.brucelawson.co.uk/wp-content/plugins/comment_quicktags_plus.phpFailed to load resource: the server responded with a status of 404 (Not Found)
/2011/javascript-and-screenreaders/:620Uncaught ReferenceError: edToolbar is not defined
http://www.brucelawson.co.uk/wp-content/themes/default/print.cssFailed to load resource: the server responded with a status of 404 (Not Found)

Comment by Apostas

There is so much crazy in this proposal. If all browsers start adopting -webkit, does that mean that Firefox, say, could introduce a new -webkit-property that webkit itself hadn’t introduced? The mind boggles. And what if, like in gradients, different browsers use different patterns. Do all browsers have to go with whoever got there first, just because they’re all using the same prefix?

I just can’t understand the thinking here.

Comment by Alan Gresley

Once a browser version supports a property that is un- prefixed, it should drop support for it’s prefixed counterpart. I can’t believe that this has come to this.

Comment by Kim

What if the CSS validator gave feedback more akin to “Property -webkit-border-radius is old-style-like-init-man, use border-radius the funk-grime-disco-core standard instead” rather than “Property -webkit-border-radius is an unknown vendor extension”? I wouldn’t need to know what has recently become a standard or not, but just run through the validator and voila, green light and notices on how to make the code more compatible/fab!