CSS vendor prefixes, an answer to Henri Sivonen
Disclaimer: I'm one of the two co-chairmen of the CSS Working Group and the opinions below reflect exactly what I think of the CSS process not only as an individual contributor but also with my co-chair hat on.
The ineffable Henri Sivonen has contributed a long, a very long, a probably too long post about CSS Vendor Prefixes. In short, he thinks they are harmful and should be dropped. I tend to totally disagree and will explain why below. In bold, Henri's words. Indented and normal, my responses.
- vendor prefixes are hurting the Web
- No. Said like that without justification and as a first sentence in
Henri's prose, no. They are not. Vendor prefixes allow vendors to
implement experimental CSS features without harming the namespace of
- They are hurting Web authors
- Here, I agree. As they are now, vendor prefixes are hurting Web
authors because a) the browser market does not evolve that fast, in
particular on mobile devices b) some browser vendors never get rid of
prefixed properties. As a result, Web authors have to maintain several
prefixes properties per feature.
- They are hurting competition in the Web browser space
- I totally fail understand why, maybe the rest of Henri's article will
- It would also make sense for browsers to implement other browsers’ prefixed features to the extent existing content uses prefixed features
- This is non-sense. There are only two cases : first case, the prefixed
property was proposed for standardization and then all browser vendors
will probably implement it ; second case, it was not proposed, probably
because it's too proprietary or badly spec'd, and no other browser
vendor will implement it because it lacks a good definition or use case.
- Why do we have vendor prefixes?
- Henri says the discussion is Member-confidential. It is only because
that discussion is super old, long before the CSS WG decided to go
public. There is nothing secret here : we have vendor prefixes because
vendors needed a way to start implementing new features w/o saying their
implementation was the official final CSS property.
- there is no clear rule for using vendor prefixes in the DOM
- That's correct and that is hurting the Web. Mozilla does it right:
when it implements a new API these days, everything is prefixed with
moz. That way, if the final standardized API differs from the experimental implementation, it's easy to get rid of the moz-prefixed version, tell authors hey guys this was experimenal anyway, and finally switch to the stable standardized version.
- Vendor Prefixes are “Hell” for Web Authors and Authoring Tool Vendors
- That is 100% true, as I detailed above for Web authors. For Authoring
tool vendors, it's a nightmare. But let me tell you one thing: the "HTML
live standard" of the WHAT-WG is a nightmare of a MUCH greater magnitude
than this one. In comparison with the fact what the whole world has now
to call "HTML" can change overnight, CSS vendor prefixes are a sweet,
predictable, simple candy.
- Web authors have to say the same thing in a different way to each browser
- Only because browser vendors are shipping "experimental features" in
non-experimental versions! Experimental features should be available
only in "technology previews" of the browsers, not in stable versions.
That way, everyone could still test the experimental features according
to the W3C rules BUT Web authors would not use prefixed versions in
production. Since almost all browser vendors switched to a fast release
process, I don't see the problem here. A feature would move from
prefixed to unprefixed as soon as the spec reaches stability, ie CR
- pure hell
- I have the feeling Henri is using my opinion here to tell the world a
"Live CSS Standard" would be better. I have the gut feeling he's
advocating for a WHATWG way of doing in the CSS Working Group. I think
this is totally wrong. I think this would make CSS collapse and trigger
the hatred of CSS Authors because they will be totally unable to say
what is CSS at a given point.
- When the possibility of using engine-specific prefixes exists, engine-specific Web content follows.
- This is just false. CSS stylesheets are full of CSS hacks because the
different browsers don't evolve at the same speed, because they don't
all offer the same feature set at the same time. Even if prefixes are
removed, that will persist and therefore engine-specific Web content
- Thus, a Web author who does not want to poison the standard namespace will only use the prefixed CSS keywords or DOM APIs
- NO. Henri just doesn't understand Web authoring here. The only way to
stop harming a stylesheet with different prefixes for the same property
is to stop using prefixed properties. EXPERIMENTAL features are
experimental, and Web authors are using them because browser vendors are
shipping these features as if they could be used in production. They
cannot. They're subject to change or even disappear at any time.
- If a site uses CSS with the -webkit- prefix, users of Firefox, Opera or IE get a worse experience even if they implemented the same feature with their own prefix or without a prefix
- It's only because browser vendors are dumb. And I do mean it. 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. That would drastically reduce the problems on
the Web. Of course, if
-moz-fooare not based on the same version of the spec - and that happens all the time - that will be helpless.
- Back in the old days when Internet Explorer introduced a feature that they just made up, they did not make their mark on it by baking their name into the identifier
- Totally false for CSS. Microsoft Word is full of totally proprietary
-ms-*properties since the first version of Word based on XML and CSS, in the "old days".
- Last week,
insertAdjacentHTMLfinally shipped to the Firefox release channel.
- Unprefixed, yes. But that's normal, we have here a de facto
standard, IE and its online doc, where we usually have a de jure
standard, a W3C specification. That IE feature is more than ten years
old and the IE-specific Web is full of it. It is totally out of question
to do something even lightly different from what IE does. So prefixes
are not needed. We already have the standard!
- The situation is harmful for Firefox for mobile, Opera Mobile and IE on Windows Phone.
- That's possible and I don't care. What I see is that your proposal to
get rid of prefixes will be even more harmful to non-browsing tool
vendors, Web authors who will never know if a feature is experimental
(and then subject to changes) or not, and finally Web users.
- In a word: No.
- No only because at the time a standard is published, the Web is
already full of prefixed properties. And the Web is full of prefixed
properties because browser vendors ship experimental features to all
final users, allowing Web Authors to use these experimental features in
production Web sites. Even telling them "go ahead, it's tagged
experimental but it's shipped to everyone anyway".
- Lea Verou's prefix free...
- ...is in my opinion dangerous. It tells Web authors that a prefixed
version of a property equals another prefixed version of the same
property. And that is just false. Lea's prefix-free tool is FAR from
enough. Trust me on that please, I had to implement a
few thousand lines to start working around the problem and I only
have a partial solution... This is MUCH MORE complex than what Lea's
tool lets Web Authors think it is.
- In practice, vendor prefixes don’t prevent legacy from accumulating ahead of CR. It’s not useful to pretend that they do.
- Again, only because of browser vendors themselves. They wanted CSS
prefixes but don't use them according to their original wishes.
Experimental is experimental, ie "should not be used in production".
Since whatever you ship will ALWAYS be used and abused, shipping
experimental features to the masses could only lead to legacy prefixes
accumulating in the wild. This is browser vendors' fault.
- If -webkit-CSS meets the client requirement within budget today, -webkit-CSS is used.
- Exactly what I said above. So don't make -webkit-CSS available to the
masses. Make it available in tech previews, beta channels, etc. But not
- browser vendors should stop adding more prefixed CSS features and DOM APIs
- Basically, it says CSS should become a Live Standard. I totally
disagree and will do all I can to avoid that.
- For CSS, features like this include at least Transitions, Animations, 2D Transforms and 3D Transforms
- That opinion would be hilarious if it was not tragic... These features
are almost similarly implemented but there are still stuff discussed in
the spec itself. The standardization is NOT done yet, and the features
are complex enough a new painful hole could emerge in the coming weeks.
- I also think that it would make sense to unprefix single-vendor features
- Ah, that I could agree with IF there is some sort of formal
environment here : a) the vendor must consider its implementation is
frozen b) it was shipped for the first time more than a year ago, so
this implementation is now a de facto standard because Web
sites are using it.
- In these cases (flexbox, gradients), I think it would make sense to stop changing the spec, to unprefix the features in browsers that are closest to the current drafts and then prioritize work to match the spec in other browsers
- Clearly no. That's what the WHATWG does, only implementations matter
and specs don't, as Hixie told me during TPAC. I don't want to see that
happen in CSS, ever. Furthermore, it would trigger an absolute nightmare
for Web Authors and Web Authoring Tool vendors.
- I think when browser vendors implement a feature experimentally, the feature should stay in experimental builds (nightly builds, “labs” builds or similar) until it is close enough to a “final” design that it can be taken as a constraint for future changes to the feature.
- AAAAAH FINALLY. Here we agree entirely. Just what I said above.
- I think the system where a WG can change anything until Candidate Recommendation (...) is fundamentally broken. I think decisions whether a feature can be changed should be depend on deployment.
- I totally disagree. It's broken because browser vendors break it
shipping experimental features in non-experimental versions. Basing
prefix removal strictly on deployment is the most harmful decision to
Web Authors and Web Authoring Tools that you could take. Only stability
matters, not deployment.
Update: now it's clearer. One of Henri's goal is to make CSS adopt the Living Standards way of doing things. My opinion is that it would kill CSS or at least be incredibly harmful to it. So I will fight that. And to reply to Rik in that IRC log, no, I don't always mention my co-chair role when I discuss CSS. I even mention "hat on" or "hat off" when I do.