|WebKit Is Breaking The Web
|Written by Ian Elliot
|Monday, 13 February 2012
WebKit's dominance is causing a real problem for other browser makers. It is a complicated story but an inevitable one, and perhaps would be better described as W3C's biggest blunder.
The problem all started with what appears to be a really simple and helpful idea. As CSS 3 was being developed, the idea was that vendor prefixes could be added to attributes to allow for flexibility during the early implementation. So, for example, if there was a CSS boxcolor property then you might set it using
In principle all browsers are supposed to support boxcolor in exactly the same way but, to allow for early adoption and general teething troubles, the W3C introduced vendor prefixes to allow designers to accommodate differences between browsers. If WebKit, say, implemented boxcolor slightly differently so that to get a blue box you have to set the color to brightblue, then you could use:
Only the WebKit browser would take any notice of the style because only WebKit reads -webkit- prefixed styles. Of course, if IE and Firefox do the same attribute differently then you would have to use vendor specific tags for these as well as WebKit:
and so on.
Is this a good idea?
The answer is obviously no, because it breaks any pretense of being a standard. The idea was that these vendor prefixes would be used for a while and then dropped as all browsers adopted the standard. Unfortunately this hasn't happened.
WebKit in particular is so popular, being the rendering engine in Chrome and Safari and particularly prominent on the mobile web, that designers tend to target just the vendor-specific tags that it uses. I have even had conversations with programmers who think that -webkit- is a prefix you use to target the mobile web. This lack of understanding, and the simplicity of just using webkit prefixes rather than making a site work with all of the browsers, is what is "breaking the HTML5 web".
A recent blog post by Daniel Glazman, the co-chairman of the W3C's CSS standards working group, has outlined the fact that his problem is about to become frozen into the web because the other browser makers are considering adding the WebKit-specific attributes to their own rendering engines. To quote:
"other browsers will start supporting/implementing themselves the
Yes, this would indeed mean that IE and Firefox would respond to attributes with the -webkit- prefix making a nonsense of any attempt at a standards-based web.
The suggested solution is for designers to simply stop using the vendor-specific prefixes, or to use all of the prefixes so as to support the full range of browsers, rather then having to put a "works with WebKit" notice on their pages. We are also asked to boycott sites that only work with a single browser - i.e. don't recommend them and don't link to them.
This seems unlikely to work.
The error was made some time ago in the introduction of vendor-specific prefixes. It never saved anyone any time and in fact it simply resulted in the need to write overly complex style sheets.
Let us hope that W3C and other standards bodies remember this fiasco and avoid adding escape clauses for customization to standards. They also have to consider working faster so that browser makers don't have to innovate on their own.
Vendor prefixes have always been a blunder.
or email your comment to: email@example.com
|Last Updated ( Thursday, 26 July 2012 )