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.