WebKit Is Breaking The Web

### New Book Reviews!

 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

boxcolor:blue;

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:

-webkit-boxcolor:brightblue;

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:

-webkit-boxcolor:brightblue;-moz-boxcolor:darkblue;-ms-boxcolor:deepblue;

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 -webkit-* prefix, turning one single implementation into a new world-wide standard. It will turn a market share into a de facto standard, a single implementation into a world-wide monopoly. Again. It will kill our standardization process. That's not a question of if, that's a question of when."

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.

Daniel Glazman's blog post