Bruce Lawson's personal site : On the vendor prefixes problem

On the vendor prefixes problem

Thursday 9 February 2012

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.

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

35 Responses to “ On the vendor prefixes problem ”

Comment by Peter Gasston February 9th, 2012 at 10:44 am

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 Now vendor prefixes have become a problem, want to help fix it? | Christian Heilmann February 9th, 2012 at 12:11 pm

[…] Lawson also chimed in and actually has a quote that very much resonates also my feelings about the […]

Comment by Neal G February 9th, 2012 at 4:21 pm

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 February 9th, 2012 at 5:55 pm

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 CSS Vendor Prefixes! | folktrash February 9th, 2012 at 9:29 pm

[…] and http://remysharp.com/2012/02/09/vendor-prefixes-about-to-go-south/, and http://www.brucelawson.co.uk/2012/on-the-vendor-prefixes-problem/, and the original […]

Comment by CSSquirrel : Vindaloo Fart | opinions and news on web design by Kyle Weems February 9th, 2012 at 10:25 pm

[…] Get Bruce Lawson’s perspective on the vendor prefix issue, taking advantage of the wisdom he’s gained in trying to educate against this exact sort of problem. Also see the first reference of the dreaded vindaloo fart. […]

Comment by WebKit-Dominanz bedroht das offene Web | virtualfiles.net February 10th, 2012 at 1:32 pm

[…] Project, Mozilla-Evangelist Chris Heilmann, der Barrierefreiheit-Experte und Opera-Mitarbeiter Bruce Lawson, der Entwickler Remy Sharp oder der Designer Gilles […]

Comment by Dave Smith February 10th, 2012 at 4:02 pm

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 😀

Comment by design for the web » Blog Archive » debating vendor prefixes February 10th, 2012 at 4:41 pm

[…] On the vendor prefixes problem, Bruce Lawson […]

Comment by My Stream | Do You Exclusively Use webkit Prefixes? | My Stream February 10th, 2012 at 5:36 pm