TL;DR: I think vendor prefixes are hurting the Web. They are hurting Web authors. They are hurting users of browsers. They are hurting competition in the Web browser space. I think we (people developing browsers and Web standards) should stop hurting the Web. It would also make sense for browsers to implement other browsers’ prefixed features to the extent existing content uses prefixed features.
Disclaimer: This is only my opinion. You should not consider this to represent any kind of position of any group you may perceive me to belong to. I wrote this as input to policy-setting discussions after realizing that simply responding piecemeal to email threads or commenting on bug trackers would be less coherent than writing a blog post.
The CSS WG wanted to have a way for vendors to behave when they need to mint CSS keywords that are not in a standard.
However, the exact discussion and reasoning that lead to the vendor prefixes is W3C Member-confidential. If you can see behind the W3C paywall, I recommend reading this email and another email as well as these meeting minutes.
Later this prefixing idea has spread from CSS to DOM APIs.
For CSS, prefixes are used unless there is a W3C specification for the CSS feature and the specification is at the Candidate Recommendation stage or higher on the Recommendation track. The CSS WG has documented rules.
The preamble of the rules says that vendor prefixes are used for vendor-specific extensions and experimental implementations. Prefixes are also used for extensions by non-W3C consortia (-wap- and -epub).
To my knowledge, there is no clear rule for using vendor prefixes in the DOM.
In practice, vendor prefixes lead to a situation where Web author have to say the same thing in a different way to each browser. That’s the antithesis of having Web standards. Standards should enable authors to write to a standard and have it work in implementations from multiple vendors.
Saying the same thing multiple times is annoying in .css files. Authors may end up saying the same thing five times: once for each of the top four browser engines and once without the prefix in anticipation of the keyword getting unprefixed in the future. This means that Web authors have to write crufty style sheets that are less readable and that require making every edit five times when changing something.
The problem has reached the point where it is being abstracted over and the abstraction being offered off the shelf. Furthermore, an article promoting an abstraction layer refers to the problem as “hell”.
Scripting is problematic, too. In the case of CSS, scripts accumulate more layers of abstraction in order to perform all style changes five times or to detect what single prefix is needed in the browser the script is running in. For prefixed DOM features, what could be simple method calls end up with five-fold cruft to deal with different names in each browser engine.
The problems faced by Web authors who work in text editors are faced by authoring tool vendors, too, making it “pure hell”. Putting a GUI over repetitive CSS properties is harder than putting a GUI over unprefixed non-repetitive properties.
When the possibility of using engine-specific prefixes exists, engine-specific Web content follows. Even though one should always expect someone on the Web to do the wrong thing if doing the wrong thing is possible, this does not even require lack of clue on the part of Web authors. A Web author doing the most due diligence can contribute to the problem: The whole point of prefixes is to avoid poisoning the standard namespace before a feature is stable and standardized. Thus, a Web author who does not want to poison the standard namespace will only use the prefixed CSS keywords or DOM APIs that exist at the time the Web author creates a site or an app. The Web author then moves on to other things and content specific to the engine that implemented a feature first stays around on the Web.
This even happens at Mozilla. It would be naïve to expect Web authors in general to do better when this happens even at a Web expert organization.
Engine-specific content is bad for users. 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. If a site uses moz-prefixed DOM APIs, users of IE, Opera and WebKit-based browsers get a worse experience even if they implemented the same feature with their own prefix or without a prefix.
This is bad for competition in the browser space. Even if vendors kept on the treadmill perfectly by quickly implementing new features, user would still perceive the products working less well than another product with those features, because Web content using the prefix for one (or two) engines but not the others makes the feature not actually activate in some browsers. Thus, vendors cannot be competitive on prefixed new Web features when the feutures are behind a prefix and Web content is favoring some prefixes and not others.
In addition to user perception differences on real sites, demos matter, too. When a feature first appears in some browser, demos are written with the prefix of that browser. When those demos don’t get updated when other browsers add the same feature (with their prefixes or unprefixed), people who are trying to gauge browser coolness or advancement by trying demos think that the other browsers are lagging more than they actually are. I expect Firefox, Opera and IE to continue to bleed mindshare because of demos written with the WebKit prefix when 2D Transforms, 3D Transforms, Transitions and Animations first appeared in WebKit even now that they are implemented by all the four engines.
It is even intuitively and historically reasonable for people to expect demos for a feature to start working once other browser catch up and implement the feature. Intuitively, people think that “the feature” means the same thing in different browsers instead of something that works the same way but that deliberately has a different identifier making it not the same. Also, historically, Web browsers have not sabotaged their own success like this. Back in the old days (supposedly “the bad old days”, but were they really worse than this prefix situation?) 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. For example, innerHTML, outerHTML and insertAdjacentHTML() are not called msInnerHTML, msOuterHTML and msInsertAdjacentHTML(). While there Mozilla of the old days had a self-imposed principled “can’t implement non-standard IE-isms” barrier, there at least was no “can’t write someone else’s name into our APIs” ego barrier that is often seen when e.g. Java libraries (which bake the domain name of the organization that created them into identifiers) or XML vocabularies (which bake the domain name of the organization that created it in the namespace URL) move from an organization to another. When other browser implemented innerHTML, existing code that used innerHTML started working (if it was unconditional or used feature sniffing—not if it was behind UA sniffing). Last week, insertAdjacentHTML finally shipped to the Firefox release channel. outerHTML is expected to ship in March. These feature had no prefixes in IE in the late 1990s and they have no prefixes in Firefox now. Absent of UA sniffing, some code written in the late 1990s might start working in Firefox! Not so with -webkit-CSS that is implemented with as -moz-CSS, -o-CSS and -ms-CSS much faster.
As far as I can tell, only WebKit is benefiting. WebKit currently has near-monopoly market share among mobile browsers that run on the user’s device (i.e. excluding Opera Mini which is in a different product category). In such a monoculture situation, it is no wonder that mobile-oriented Web sites put their effort into targeting WebKit. Combined with targeting WebKit meaning using -webkit-CSS, this leads to lock-in.
The situation is harmful for Firefox for mobile, Opera Mobile and IE on Windows Phone. Yet, Mozilla, Opera and Microsoft are going along with the prefixing scheme. At one point, Microsoft planned to implement a -webkit-CSS feature for IE on Windows Phone, but people out of principle told them not to and they backed down.
Aside from the mobile situation, WebKit also benefits in terms of mindshare on desktop when demos written with -webkit-CSS make it seem that Firefox, Opera and IE are less capable. DOM APIs don’t demo as effectively as CSS, so there isn’t a symmetric mindshare effect for moz-prefixed API.
Any rational and scientific evalution of a policy should ask if the policy is actually delivering the benefits that it is supposed to deliver. In this case, since the original rationale for the policy is W3C Member-confidential, I’ll use both deducing a straw person policy goal from the policies themselves and point to a more recent public policy rationale.
The CSS WG nowadays publicly says that collision avoidance with subsequent expansions of the standard vocabulary is a motivation for vendor prefixes.
Another possible explanation is the wish make it clear to authors when they are using a non-standard feature.
The notion that using a prefix avoids poisoning the standard namespace before something has been proposed as a standard at all (the case for “vendor-specific extensions”) or before the standard has frozen (the case for “experimental implementations”) assumes that prefixing avoids the accumulation of legacy content that would eventually conflict with a standard. So is prefixing effective at avoiding the accumulation of legacy content before a given feature has reached its “final” standard form?
In a word: No.
Earlier, I mentioned that it is a problem that some Web authors use only the prefixes that have been implemented for a feature at the time they write a style sheet and then in the future when the feature is implemented by other browsers with other prefixes or implemented unprefixed, the style rules don’t work. Other Web authors foresee this problem and decide to anticipate the eventual unprefixed implementation and include the unprefixed version in their style sheet, too. This practice makes vendor prefixes totally ineffective at preventing the accumulation of legacy that might conflict with the eventual final standard, because Web content starts containing uses of the unprefixed syntax long before the CSS WG considers the feature frozen.
The practice of including unprefixed keywords in anticipation of eventual standardization is not a phenomenon that can be ignored as not mattering if one believes that accumulation of legacy during standard developement is a concern that matter. The precognizant use of unprefixed variants is taught by gurus who Web authors follow, for example Lea Verou and Paul Irish. Furthermore, even developer relations of Web browsers themselves suggest including unprefixed CSS in anticipation of future unprefixing, for example Mozilla and Microsoft.
Note that I am not suggesting that the gurus are giving bad advice. I think the advice is totally reasonable given the probability of success when guessing what the unprefixed feature will look like. My point is that you don’t need to agree with the advice to conclude that the advice is being given and that following the advice leads to an accumulation of unprefixed legacy.
In practice, vendor prefixes don’t prevent legacy from accumulating ahead of CR. It’s not useful to pretend that they do.
If we assume that another policy goal is to make it clear to Web authors that they are using non-standard features, authors may be aware of features being non-standard or engine-specific, but then what? Clearly, the proliferation of -webkit-CSS in the wild (especially on sites that target high-end mobile phones) shows that seeing cues that a feature is engine-specific isn’t enough to dissuade Web authors from using the feature.
Indeed, it doesn’t take much chatting with Web authors to discover that Web authors often make decisions that optimize immediate results given immediate client requirements and budget constraints. If -webkit-CSS meets the client requirement within budget today, -webkit-CSS is used.
In particular, it is rather useless to argue that Web authors are making an informed choice about creating engine-specific content. Web authors are known not to optimize the long-term health of the Web when they make desicions (if they were, WebM would be used a lot more by now and swf would already be used much less). Moreover, when the decisions Web authors make based on short-term incentives hurt other browser vendors and their users, standard group policies and the actions of browser vendors shouldn’t make it easy for Web authors to create engine-specific content even if they do so after an informed choice.
One of the guiding principles of the evolution of the Web platform (and entering the browser market) is Support Existing Content. As Web technology evolves, it should be implementable in such a way that old existing content keeps working. That is, spec writers (whom browser vendors take seriously) don’t get to require things that would make existing content no longer work. Also, when entering the market, a browser that seeks to succeed has to be able to successfully support content that was authored for browsers that came before.
Vendor prefixing tries to make us believe that the principle suddenly doesn’t apply if identifiers contain names of vendors. On one hand, the CSS WG feels that it gets to change features after deployment has started, because deployed vendor prefixed content doesn’t count towards needing to be compatible with what exists already. On the other hand, Mozilla, Opera and Microsoft are tricked to act as if their mobile products didn’t need to support content that has already been authored for Mobile Safari while the Android stock browser gets to support that content, because it uses WebKit, too.
I think vendor prefixing does not fit the known-good design principle to Support Existing Content. In the case where the CSS WG eventually standardizes something that’s different from the corresponding -webkit-CSS feature, we end up with a situation where the standards don’t document how to consume existing content. This is contrary to the purpose of standards as an enabler of competion by revealing what needs to be implemented without a new entrant to the market having to reverse engineer the incumbent(s). On the other hand, the notion that a new entrant to the market shouldn’t even try to support another vendor’s prefix is anti-competitive, because it would deny an entrant to the market the way to compete by supporting existing content that so far all vendors that have made an entry to the desktop browser market before widespread prefixing had a chance to use. (Netscape supported content authored for Mosaic. IE supported content authored for early versions of Netscape. Mozilla supported content authored for early versions of Netscape and selectively aspects of content authored for IE. Safari supported content authored for Mozilla. Opera supported content authored for IE and later for Mozilla.)
So vendor prefixing has downsides and it fails to deliver the upsides that it is supposed to deliver. Here is what I think should be done to remedy the situation:
The first thing to do about a bad situation is to stop making it worse. I think the CSS WG should rescind its vendor prefix policy. Insisting that keywords be prefixed until CR makes no sense in an environment where all the top engines implement the features in releases shipped to end users and the feature are advertised to Web authors before the specs reach CR. These are not experimental features. These are features that are getting shipped and deployed. (Compare status for Transitions, Animations, 2D Transforms and 3D Transforms on caniuse and the CSS WG’s spec status page.)
To stop making the situation worse, I think browser vendors should stop adding more prefixed CSS features and DOM APIs. (I’m not suggesting stopping adding features; more below.)
There are prefixed features that are implemented so similarly by all vendors that authors just repeat the same thing with different prefixes for webkit, moz, o and ms prefixes. That authors already just duplicate the same code with different prefixes shows that interop is good enough that these features can be unprefixed. Getting closure and moving on is more important than pretending that there’s still an opportunity to bikeshed the features before CR.
For CSS, features like this include at least Transitions, Animations, 2D Transforms and 3D Transforms. Possibly many more. For APIs, this includes at least requestAnimationFrame(). I think all browsers should add unprefixed versions of these features as soon as possible. Browsers who weren’t the first to add these features would probably benefit from removing the flavor with their prefix.
Note that requestAnimationFrame() could have been unprefixed all along and it still would have been possible to add a non-void return value later and to add an optional second argument later. The efforts to add those are not signs of success prefixing. They are signs of the prefixing of requestAnimationFrame() being useless in the first place.
I also think that it would make sense to unprefix single-vendor features (such as Mozilla’s proposed additional XMLHttpRequest responseTypes) immediately and treat them in subsequent standardization the way innerHTML and other ancient IE features and ancient Mozilla features like Range.createContextualFragment were treated.
In some cases, vendor prefixing has allowed the CSS WG to let the spec deviate significantly from what was originally shipped with a prefix. Examples include at least Flexbox and gradients. In these cases, 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.
I think browser vendors should stop treating vendor prefixes as if the need to support existing content didn’t apply to them. In particular, I think it would make sense for Mozilla, Opera and Microsoft (or anyone else for that matter) to identify and implement -webkit-CSS that is harming them competitively by making their users experience sites less well than users of WebKit-based browsers because Web authors have used WebKit-specific CSS. I wouldn’t be too surprised vendors other than Mozilla ended up implementing a moz-prefixed API or two in order to make their products look better on demos even if not to support actual content in the wild.
I think it would be good to document what features need to have prefixed aliases and to write actual specs for prefixed legacy features that don’t end up being mere aliases for standard features if it turns out that it’s important competitively to support such features (such as WebKit gradient syntax).
Features are claimed as “experimental” while they are being advertised as new browser features and being deployed on real sites by Web authors. Having the cake and eating it too doesn’t work here. Once a feature is deployed on real sites by Web authors, it is no longer “experimental” for practical purposes and it’s counter-productive to pretend that it is.
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. (See also Karl Dubost’s email on the topic.)
I think it should be a social norm that vendors ping the relevant working group early enough about new features they’ve come up with to make changes before shipping if peer review finds bad problem. This solves two problems. First, it removes the need to pretend that the major browser vendors needed vendor prefixes for collision avoidance. All the vendors are represented in the CSS WG, WebApps WG, etc., so the WG could just act as a central point of knowledge of which identifiers have been taken. Second, it would mean that designs would get some peer review before shipping, so problems would be avoided a bit better than in a model where vendors just ship stuff and the first to ship establishes how things are going to be without any review.
Now that even Microsoft does early Platform Previews, I think it’s not too unrealistic to expect vendors to ping WGs early instead of showing new features off only when a product is shipping already.
I think the system where a WG can change anything until Candidate Recommendation and that the Support Existing Content principle is considered not to apply if the existing content uses prefixes is fundamentally broken. I think decisions whether a feature can be changed should be depend on deployment. Specifically, two things should be considered when assessing whether a feature can be changed:
That’s it. If Web content depends on an interoperably implemented feature, the way the feature works shouldn’t be open to random bikeshedding even if there isn’t yet even a W3C Working Draft about it. On the other hand, it should be possible to change a feature that Web content doesn’t rely too much upon even if the feature is part of a Recommendation.
This means that once a vendor no longer has patience to keep an “experimental feature” in experimental builds only, the characteristics of the implementation become constraints on further work to the extent Web content starts relying on the characteristics of the new feature. I think acknowledging such contraints is much better than pretending that content using prefixed syntax isn’t constraining anything.
I feel I need to address a couple of typical counter-arguments.
The first counter-argument is that what I am proposing leads to badness like the early wrong IE implementation of the CSS box model which in turn was addressed by badness like multiple rendering engine modes. This line of argument assumes that the wrong implementations were really bad and that the solutions that were used were the best ones.
But the IE box model isn’t totally nuts. Instead, it made enough sense that it’s making a comeback via the box-sizing property! I posit that the situation would have been addresses with much less grief if back in 2000 or so the CSS spec had been changed to default to the box model that IE had shipped and box-sizing had been introduced as a means of opting into the model that stubbornly remained the default in CSS.
Likewise, I think the behavior that table cells shrink wrap around images that are shallower than the line height wasn’t nuts even though the CSS spec was interpreted to require something else. In retropect, I think the Almost Standards Mode should have never existed and the legacy-compatible mode should have been made the default and a new CSS property should have been added for opting into the behavior that is now the default in the Standards Mode.
It should be possible to change standards instead of stubbornly sticking to whatever the specs say when implementations and the specs disagree. Also, if a “wrong” implementation gets massive adoption from Web authors, it’s probably not that bad.
-moz- and -webkit-Typically, people working on CSS implementations can tell you that for any given pair of -moz-foo and -webkit-foo there are subtle differences. More broadly, people who know history point out that -moz-border-radius wasn’t exactly what got standardized.
Yet, if you look at how Web authors deal with vendor prefixes, with the possible exception of linear gradients, Web authors tend to duplicate a line of CSS and just change the prefixes instead of tweaking things further for each browser. This applies both to rounded corners earlier and to Transitions, Animations and Transforms now.
When the differences between browsers are small enough that authors are OK with duplicating code with mere prefix substitutions, the convergence on the exact same behavior could as well take place in the standard unprefixed namespace. Even when there are differences between -moz-foo and -webkit-foo, it doesn’t follow that the differences are so large that the Web wouldn’t be better off with both Gecko and WebKit implementing the feature as foo and ironing out bugs over time.
The following are responses to comments made about the text above.
-x- or -draft- Prefixes?”Having a common prefix for experimental featurs wouldn’t solve the problem as long as experimental features are shipped in non-experimental browser builds. Web authors would use -draft-foo: 0.5em if it solves their clients’ problem right now. Then, some Web authors would also use foo: 0.5em immediately, because it’s the better bet for future-proofing the site, since chances are that foo: 0.5em ends up working similarly enough to -draft-foo: 0.5em that it makes sense to make the bet. Thus, a common experimental prefix would fail to avoid the accumulation of legacy.
On the other hand, other Web authors would use only -draft-foo: 0.5em. If their content became significant enough a legacy, a new browser entering the market would need to support -draft-foo. If the CSS WG had by that time treated the prefix as a license to change the spec, -draft-foo would have become similar to a badly-documented proprietary feature from the point of view of what kind of barrier to entry the new browser faces. Thus, even a common experimental prefix would be harmful by making the WG believe it can change stuff after significant deployment, since the resulting situation would, from the point of view of enabling a competitive market, be one that documented standards are meant to avoid.
Features from other pre-Candidate Recommendation specs are routinely implemented without prefixes outside the CSS space. For example, HTML5 features like canvas and video have been moved forward unprefixed with a feedback loop between implementations and the spec. Prefixes aren’t a prerequisite for fast progress. In fact, when there are prefixes, the spec writers might feel it is OK to take a longer time to stop making breaking changes to the spec. (“Breaking” being the key word in the previous sentence. Non-breaking spec refinements are OK and are not harming progress.)
If experimental features were kept in experimental builds, browser vendors would be under pressure to stop treating features as experimental much sooner than the CSS WG stops treating features as experimental currently. Basically, vendors would bear to wait for a little while to convince themselves (while hearing out what others in the WG say) that a feature isn’t completely broken and then ship it. After adoption of the feature by Web authors, spec changes would be constrained to refinements that don’t break existing content too badly.
-webkit-”Demos that use -webkit- only are making Firefox (as well as Opera and IE) look less “hot” even if Firefox (and Opera and IE) implement the same features—only with a different prefix. One of the points I’m trying to make is that Firefox (and Opera and IE) seem less “hot” than justified by the features they implement, because they volunteer to go along with scheme that puts them at a disadvantage beyond just the initial delay of implementing a feature that another engine implemented first.
I think in an enviroment where the Web has multiple actively-developed browser engines, it doesn’t make sense to assume a priori that a newly-introduced feature—even one lacking spec consensus at first—is going to stay vendor-specific. Vendors ofter propose good features that others adopt, too. In that case, everyone is better off if the feature isn’t prefixed at any point.
Sometimes other vendors think that something another vendor introduced is bad for the Web and should not be implemented. So they refuse to implement it. However, looking at features that currently have the status of being rejected by some vendor, the features tend to be unprefixed! Mozilla and Microsoft are refusing to implement Web SQL Database and SVG Fonts. Opera and Mozilla are refusing to implement H.264 (Opera on desktop only). Microsoft is refusing to implement WebGL. All these are implemented without prefixes in the browsers that implement them! The features even have specs.
Clearly, the current prefixing practice is not effective at making it easier to refuse to implement bad features. And, as recounted above flagging features as vendor specific does not make authors not use the features. Not shipping the features in release builds would be a more effective way of making authors not use features.
Still, it might make it slightly easier to combat H.264 if Apple, Google and Microsoft were kind enough to volunteer to sabotage the network effects by making their implementations mutually incompatible (if WebM was kept combatible between multiple browsers at the same time).
There is a risk that authors would start nagging users to flip prefs and run a browser configuration that is not supported. Users won’t know which features are off by default due to spec status and which ones are still crashy or insecure.
Yes, sites really do tell users to flip unsupported prefs. A major company recently told users of their extranet to turn off the HTML5 parser in Firefox.
Letting authors abstract over the prefixes—whether by using future CSS features, JavaScript or server-side pre-processors—makes prefixes an ineffective means of avoiding the accumulation of legacy. That is, abstracting over prefixes defeats the point of having the prefixes in the first place. It makes more sense to remove the problem than to facilitate working around the problem.
Daniel Glazman wrote a point-by-point response. I recommend reading the whole thing. Even though he starts by saying he totally disagrees with me, he turns out to agree with me about keeping experimental features only in experimental builds. Also look for the part where he says “browser vendors are dumb” for following the CSS WG’s policy.
Alex Russell wrote a response from the point of view of considering the benefits of vendor prefixes. He focuses on the win of authors being able to use new features before the dust has settled and on the ability to iterate.
If CSS followed the model I described above, I believe features would be first available to Web authors in slightly later than vendor-driven features become available as prefixed in the current model but they’d be available in a form that doesn’t involve the “prefix hell” much sooner than in the current model. That is, I think the pressure to ship would lead to settling the central parts of the design sooner than in the model where the use of prefixes gives a license to keep changing the central parts of the design for a longer time. That is, features would have to become non-experimental much faster than the CSS WG takes specs to CR currently.
As for iteration, with the current model, you get a maximum of four experimental iterations (each of the top four engines doing implementing a substantially different version of the spec) if you assume that already-shipped prefixes cannot change their meaning. In practice, you are more likely to get fewer than four such iterations, since two vendors might implement the same snapshot and one vendor might choose to wait for a given spec to go final before implementing. If you assume a willingness to iterate in a way that changes an already-shipped prefixed feature that has X amount of deployment, surely an unprefixed shipped feature could be iterated on just as much until deployment reaches X. Also note that the model where each iteration is carried out by a different vendor degenerates to the model of iterating in one namespace when authors include all prefixes ahead of time.
Thus, the potential iteration win from prefixes is modest at best if you consider the differences of the two scenarios on their technical merit. The wins might be larger if prefixes actually do have the non-technical effects of changing the rate of adoption to slower (to buy more time to iterate before there’s too much content) or making vendors more willing to break existing content. To evaluate this, it would be necessary to see how much vendor have been willing to change their prefixed properties in breaking ways during spec development. I don’t have that data at this time. (If anyone tabulates this data, please let me know!)
In general, Alex seems to focus on an optimistic view that focuses on the most active and knowledgeable Web authors who keep maintaining content and following the process along. Google as a Web authoring organization probably acts that way, for the most part. One-off client projects might not work that way even if they are made by super-competent people. I tend to have a deeply pessimistic view that assumes that even though there are actively maintained sites, there will be so many sites that won’t be actively maintained that the unmaintained sites will have a notable effect on the landscape browsers have to deal with.
Speaking of optimism, Alex expects that it’s possible to remove support for prefixed CSS in a couple of years. I think it will be interesting to see how soon Apple removes support for the prefixed variants of major features like Animations, Transitions, Transforms and gradients. So far, browser vendors have been very reluctant to remove features that have been taken into use. Even DOM Load & Save isn’t quite gone yet!
Also, gradients were not a motivating example for me to write this. (Transforms were one motivation example, though.) I see gradients as a potential counter-example that might show that the model I’m suggesting is wrong. But see this email.
The CSS WG discussed implementing other vendors’ prefixes at a face-to-face meeting. Representatives from Mozilla, Opera and Microsoft said that implementing zero -webkit-prefixed CSS features is no longer an option for them. Interesting stuff about secrecy came up. I encourage you to read the minutes (but do note that Lea Verou was blamed erroneously). In case the minutes look too much like inside baseball, here’s a who’s who:
Afterwards, Daniel Glazman (glazou in the minutes) posted a call for action to Web developers to get them to stop making WebKit-only sites and to get them to lobby against Mozilla, Opera and Microsoft making their products compatible with WebKit-oriented sites.
Robert O’Callahan (layout developer at Mozilla) explained why the alternatives to supporting -webkit prefixes in other browsers will not work. Be sure to read Peter-Paul Koch’s reponse to Daniel, too.
In case it isn’t obvious, I agree with Robert. I think Daniel’s call for action is an exercise in futility when it comes to getting Web developers to change the landscape substantially and I think the call for action is harmful if it gets Mozilla, Opera and Microsoft to continue to volunteer to keep their products at a competitive disadvantage.
Daniel also disagrees that this problem should be blamed on the CSS WG. I disagree with Daniel, though he is of course correct that the CSS WG consists of browser vendor representatives. We got to where we are because Apple followed CSS WG policy and then the CSS WG (collectively; for various reasons) failed to follow up fast enough. Without the harmful prefixing policy in place, we wouldn’t have the current problem even if the standardization ball had been dropped (for any reason) at the same point that it was dropped. (Note that Apple submitted specs for Transforms, Transitions and Animation and only then dropped the ball. Not submitting text-size-adjust is a sidetrack in the big picture.)