Part of Theory.
11 July 2012
Last week I got annoyed at the large differences in syntax for vendor-prefixed device-pixel-ratio media queries. I said, half in desperation and half as a threat, that it might be better to have only the WebKit rendering engine and ditch the rest.
Meanwhile I’ve had some time to think about it, and I find that I still support the idea of multiple rendering engines. Competition is still good, just as it was ten years ago.
HOWEVER. There’s an important exception.
OK, I’m now officially fed up with vendor prefixes, and to a lesser extent with Firefox and Opera who’ve gone batshit crazy on us all once more.
I’ve been going through my CSS tests last week, and thought I’d jot down some notes on how the browser treat vendor prefixes. It’ll bring some much-needed practicality into the discussion.
This does not prove that vendor prefixes are either good or bad. It’s just one more data point to consider.
My article yesterday about the vendor prefix mess garnered quite a few interesting comments, and today I’d like to respond to those that object against my proposal to replace the current system by a universal
-beta- prefix by proposing an additional
This is one of those weeks where everything happens simultaneously. I think that the vendor prefix discussion is the most important topic, so that’s what will get my attention.
Daniel Glazman, co-chair of the CSS WG, posted a call for action that warned of the dire consequences of web developers using only
-webkit-prefixed CSS declarations: IE, Mozilla and Opera would also implement
I will argue that the proposed solution of making web developers aware of the problem may be technically and ideologically correct, but does not address the true causes of the problem: the developer-hostility of vendor prefixes, and the lack of mobile test devices.
A week ago W3C published the first working draft of the W3C CSSOM View specification (written by Anne van Kesteren), and I must say I'm very happy with it. Since I was testing stuff anyway I created a new compatibility table for most of the methods and properties specified in this document, and browser compatibility is already excellent.
That's no coincidence. This specification contains definitions for many properties (and a few methods) that browsers have already been supporting for ages (such as
offsetWidth), and W3C has paid scrupulous attention to the current implementation. No more theorizing into the blue — just check what browsers do and describe it in the specification. Excellent idea.
Well, the new W3C HTML Working Group is slowly getting into gear. It seems as if W3C has learned from past mistakes, since right now the openness surrounding the new WG is commendable. There's a blog for sharing information, anyone can join the mailing list as an Invited Expert, and even if you don't you can still read the list. Good!