Webkit not well taken care of

Posted Feb 26, 2013 1:19 UTC (Tue) by pjm (subscriber, #2080) [Link]

It's one thing to worry about this development, but we also need to think about what we can actually do about it.

Regarding bugginess: Among the comments in that jQuery-related page is a WebKit developer asking whether these workarounds are for bugs still present in current WebKit, or whether they're just for old versions of WebKit. Another couple of comments ask whether the jQuery developers made any attempt to have the bugs fixed (even if only by filing bug reports). So far there's no reply to any of these queries, so it's not clear to me that current WebKit (as adopted by Opera) is more buggy than other browsers.

As noted both here and in the comments to the referenced blog post, many (or even most) differences between WebKit and Gecko are where the specs aren't clear what the right behaviour is. Opera switching to WebKit will surely only make this problem worse.

Opera adopting WebKit says that the CSS specs (and other, not-yet-specified, expected browser behaviour) are too onerous not just to implement to begin with, but even just to keep up with when you already have an implementation.

These two observations do not bode well for the future of an open web, given that not everyone's HTML/CSS-related needs can be met by a single implementation.

If we want an Open Web, then it has occurred to several people (independently) that we need a different approach to providing advanced functionality, making more use of Javascript polyfills and providing useful basic building blocks. Tab Atkins, who works on both WebKit and spec development, is one person thinking along these lines.

LWN readers might compare HTML/CSS interoperability with (La)TeX interoperability. In TeX, the usual way of adding functionality is with a package file. I don't remember having to upgrade the latex binary to read a document, I've only needed to install packages. For web pages, "installing packages" is even easier, because the browser does it automatically from the URIs in the referring document. With proper versioning, implementers could even implement native versions of commonly-used libraries that prove to be performance costly.

The limiting factor for a polyfill approach is what hooks CSS provides for changing functionality, and what building blocks are available. A lot of polyfills today work well enough in common cases, but fail once there's a user stylesheet or the document gets viewed in a medium other than screen, or the content uses a layout feature beyond the basics.

The challenge, then, is for each new CSS feature to think how it could be implemented with a Javascript polyfill, and what changes to CSS (hooks and building blocks) would make a polyfill implementation more practical; and to get these generally useful extensibility changes implemented instead of once-off features.

Comments, suggestions?