CSS vendor prefixes, an answer to Henri Sivonen
By glazou on Wednesday 16 November 2011, 09:47 - CSS and style - Permalink
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
unprefixed properties.
- 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
explain why.
- 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
status.
- 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
will persist.
- 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
-webkit-fooand-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
stable versions.
- 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.
Comments
I must say I agree to Henri's ideas more than yours, but if the only thing you share in common could become true, I would be completely happy. Please make that happen. We strongly need it.
The only way to do it would be to define "beta" and "RTM" at the w3c level and enforce some stricter rules for RTM versions than now.
I would also define "private engines" that are used inside OSes as an application platform. Those will need platform specific API anyway.
Beside that, I would drop prefixes altogether (or use a w3c wide prefix) in experimental builds to allow demos to move from browser to browser. Those demo should specify the version of a reference browser they are made to work on. If that's done there could be more than one implementation of the same property in browser experimental browser to achieve compatibility. But you don't seem to buy that anyway. That's not important if we can achieve the first part already.
Did you really read Henri's article ? You don't "tend to totally disagree".
In fact, you have pretty much the same idea. Stop shipping experimental features in stable releases. FYI, that was what his article was about.
@David: there is much more than that in Henri's article. There is also the "stop implementing prefixes" message. See "I think browser vendors should stop adding more prefixed CSS features and DOM APIs" in his article. That I disagree with.
If you suggest browsers should honour properties prefixed for other rendering engines, why not just implement one common prefix, like -beta-*?
But I agree experimental features shouldn't be supported in stable releases.
Two things:
1) The last time a UA was considering supporting another UA's vendor prefixes there was all sorts of stink.
2) Related to this, some UAs are using vendor prefixes to gain an competitive edge: they ship them in stable releases, heavily advertise them to developers, and never remove them, even after the property becomes a standard. This encourages sites to use those prefixes. The same UAs then object loudly if any other UA wants to support content using those prefixes.
Issue #2 is actively bad for the web, because it leads to UA-specific content, and if you aren't planning, as co-chair, to convince those UA vendors to change behavior we need a different approach to prefixing in CSS.
@Daniel: By the Henri's own confession, he think you agree on the key point. The exact names of css properties in alphas is anecdotal, IMHO.
@Boris: Exactly. If UAs can't implement other vendors prefixes, they are similar to patents. Apple cherishes both, and they both hurts the web.
"Even if prefixes are removed, that will persist and therefore engine-specific Web content will persist."
Nope. :) from daily experience of Open The Web activities at Opera. The issue that henri mentioned is that Web authors are often putting CSS features for Webkit only and it is never been fixed. Never. The project is in production. The Web goes on. The old "best viewed in IE" still exists. The Web authors are creating "best viewed in Webkit".
Without prefixes, some late browsers will break, but at least once everyone has caught up sometimes after a few years, the site is working.
>> 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.
> 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 -webkit-foo and -moz-foo are not based on the same version of the spec - and that happens all the time - that will be helpless.
What you propose does not help when a site uses only -webkit-foo and it has different syntax to -othervendor-foo or foo. What Henri suggests -- implementing -webkit-foo with the syntax WebKit supports -- would make such sites work.
I agree that "Experimental features should be available only in 'technology previews' of the browsers, not in stable versions." However, if this were true then why do we need any prefixes at all? If experimental features are only in technology previews, there's no need for any prefix as far as I can see. The technology preview might render CSS properties without a final specification incorrectly but that is not a problem. It's a technology preview for a reason!
Later you claim that "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." Did you read Henri's post? Especially parts "Would the change break existing content too badly?" and "acknowledging such contraints is much better than pretending that content using prefixed syntax isn’t constraining anything."
The thing everyone fails to mention is the fact that we only have these problems because the W3C is moving much too slowly. Browser vendors have to implement the prefixed versions because the W3C fails to finish specifications in a reasonable timeframe. Implementing these CSS3 features is highly beneficial to the web, though the current prefix mess is a pain. But the solution is not to get rid of all the prefixed features, but rather agree on a single prefix for experimental features - and speed up the W3C. The web is evolving at a very rapid pace - and the W3C needs to keep up.
"But the solution is not to get rid of all the prefixed features, but rather agree on a single prefix for experimental features"
No, this won't do. As already mentioned in this thread this will neither solve cases where the syntax differ nor when encountering major implementation differences. Actually, limiting experimental CSS features to a common prefix might end up causing the situation to get worse by making it impossible for web developers to accommodate the different implementations by specifying it separately for each browser-specific prefix, so that the end result looks acceptable and not totally broken in at least one browser.
@Erruno: then we could have a -tmp- prefix AND a -webkit- prefix. If you are confident you use a property correctly, no problem. If you encounter a bug only on webkit, you can use the browser specific prefix to override the default declaration.
To overcome problems of changing implementations, we could use versioning: -exp-magic-key:2 alt,a; -exp-magic-key:1 ALT+A;
Versionning would be introduced by w3c for experimental support of a standard.
Personally, my views are in the middle of this argument.
I agree that the vendor prefixes cause many of the problems that Henri mentioned, but to stop using them is ridiculous. It's important to show what's experimental and non-standard. However, I think many of the issues could be solved by using one prefix instead of many. Would it cause any further issues if we made all UAs use the same prefix, such as "x-foobar". For example, "x-transform". This would solve the fragmentation of code and repetition.
Also, I agree that experimental CSS properties should be disabled by default in stable builds of browsers.
I think that a combination of the above two suggestions will solve all of the problems that Henri mentioned without jeopardising the ability to make big changes to the syntax of a property.
Well, I'm for keeping vendor prefix, so that I can stay away and don't touch them even using a 10ft pole.
I don't need cool features, I need correctly implemented standard features, to begin with.
Re: "there is no clear rule for using vendor prefixes in the DOM"
a little mistake there: Mozilla's vendor prefix starts with -moz (and not with moz). That is an important distinction as this dash allows web designers (and parsers and hackers) to easily distinguish _all_ vendor specific prefixes as exactly that. OTOH IE's vendor specific css does _not_ prefix a - (e.g. filter) and this is hurting the web and polluting the name space.
If I’m deducing this correctly, at the core of the argument is whether or not CSS should be a living standard.
I’d be interested to hear your opinion on the difference of applying a living standard to the HTML spec as oppose to the CSS spec. And why you think it is a bad idea for CSS and why (or not) it is a good idea for HTML.
All in all, if a browser is going to launch an experimental feature of CSS that can make my web app better then I'm all for it. Sure that means I may have to do some feature detection here and there, but this practice is so common now that we have a kick ass library like Modernizr to make it less painless. A little bloated CSS (and probably Javascript) is a small price to pay for delivering an top level user experience.
I tend to agree with those who think you are much more in agreement with Henri than you may think. Some of the disagreements noted above are extremely minor or tangential e.g. when Henri says Microsoft didn't prefix its properties back in the day you answer it's 'totally false' because of Word's -mso- prefix. Well, he is talking about IE, not Word or Microsoft products in general, and in this respect, he is absolutely correct. IE did not prefix new CSS features until relatively recently.
Far more importantly, Henri argues from what authors and browser makers do every day. Much of your rebuttal is about what they should be doing instead. What we have may be the best we've come up with so far but I think we should establish that based on actual practice; arguing about what we think the unwashed masses should obviously do irrespective of what they are objectively and actively doing all around us seems unlikely to yield good results.
In the real world, influentials like Jeffrey Zeldman and Eric Meyer run awesome conferences where you can sit back and drink -webkit- Koolaid all day. Saying they shouldn't do this is besides the point: they do. Saying they shouldn't also recommend authors 'future-proof' their CSS by adding an unprefixed copy of every -webkit declaration is likewise irrelevant: they do that as well.
Arguing browser vendors are not using prefixes as they should is also puzzling. While you're absolutely right they're not using them that way the paywalled meeting minutes linked by Henri suggest that was the case from day one: the issue appeared to be about Microsoft releasing new CSS properties in IE to support behaviors. In other words, this scheme was not an answer to a request for some kind of experimentation space but dealt with an actual vendor-specific feature intended for a shipping product. Since that 1998 conversation, how many times have prefixed browser features that made it into public bits not been released into a product as a percentage of the whole? Why should we believe browser vendors want this for experimental purposes only? Maybe we don't. Maybe browser vendors are no dumber than you are :)
You have obvious issues with the whole Living Standard vs. W3C process debate and that is the one clear item where you and Henri disagree. Fine. Henri's preference is no more a secret than yours. I don't think that changes Henri's statement of the problem though. I don't think he's suggesting the CSSWG going WHATWG would fix anything either. In other words, he believes the prefix scheme to be harmful however we run our day to day business.
Last, shipping prefixed features in products is not 'dumb'. It is not dumb for a browser vendor to want to gather as much real-world user feedback as possible; nightlies and other dev channels go a few millions *at best*, only a few tens of thousands of which will really try out a particular feature (if that), never mind provide actionable feedback representative of the larger population. Releases of IE, Firefox or Chrome are deployed to hundreds of millions. So while previews are very important, one could also say - hugely oversimplifying for emphasis - that they gather anecdotes while releases gather data. And the latter often confirm the old saying that data is not the plural of anecdote. Real-world implementation experience does yield better products and better standards. But when a new feature hits all the right author buttons, it may also *risk* fragmenting content by tightly coupling it to some browsers vs. others, similarly to what happened in the past when IE's market share was in the 90s.
The most valuable feedback of all for any new feature is seeing it used by authors. This direct feedback is absolutely invaluable in gauging author interest and understanding how the feature is actually used (use-cases can emerge that were not thought of initially); would the IE team be making gradient standardization a priority if the biggest user of the feature were apple.com? Would authors spend as much time as they do building gradients or animations or flexbox demos and blog posts if the result of their experiments couldn't be shared beyond the tiny population of nightly build users for years to come?
The alternative is to wait until CR and testsuites to really ship the feature and find out whether it's the one authors at large really wanted. I do not believe this will be as effective as iterative implementation experience by multiple vendors.
But while real-world feedback is extremely valuable to browser vendors - and to the WG, who gets great spec feedback from it - it also builds up a collateral technical debt in the form of content that depends on prefixed implementation. This entire conversation is really as to whether the benefits are worth the costs vs. an approach that focuses on standardizing what browser features authors choose to use. (The latter is also certainly more WHATWG-like in its philosophy and that obviously rubs you the wrong way as well...).
So I hope we can put the 'living standard' vs. 'w3c' argument to one side and keep Henri's ball rolling. I don't know where it will land but I think we'll be better off for keeping the discussion open. This topic keeps coming back for a reason. Thanks for the rebuttal!
Vendor prefixes are the worst way to provide access to experimental features, except all those other ways that have been tried from time to time.
We could have a “namespace” for experimental CSS features:
http://lists.w3.org/Archives/Public...
Essence: The burden of being valid should be on the authors. At the same time, they should have oportunity to use experimental features without being punished for being non-valid.
Well said.
Living standards make me feel slightly nauseous.
Scratch my head as I don't understand the problem.
I thought it was common sense that CSS vendor prefixes are known to be highly browser specific and experimental?
If you want your sites to work on most browsers, keep yourself within the published standard.
Storm in a Tea cup.