Vendor Prefixes Are A Rousing Success

tl;dr version: Henri Sivonen’s arguments against vendor prefixing for CSS properties focus on harm without considering value, which in turn has caused him to come to a non-sensical set of conclusions and recommendations. Progress is a process, and vendor prefixes have been critical in accelerating that process for CSS.

For a while now I’ve been hearing the meme resurface from CSS standards folks and a few implementers that “vendor prefixes have failed”. I’d assumed this was either a (bad) joke or that it was one of those things that web developers would scoff at loudly enough to turn the meme recessive. I was wrong.

Henri Sivonen, Mozilla hacker extrordinare, has made the case directly and at length. Daniel Glazman, co-chair of the CSS WG posted a point-by-point response. If you have the patience, you should read both.

Lost in the debate between “browser people” and “spec people” is the the essential nature of what has happened with prefixes: they worked. From the perspective of a web developer, any first approximation of the history of vendor prefixes are pure win, even if only a fraction of the value that has been delivered behind them is attributable to prefixes un-blocking vendors from taking risks and shipping early.

Daniel’s rebuttal to Henri gets a lot of things right, but he gives in on an essential point; by agreeing with Henri that vendor prefixes are “hurting web authors” he wites off the benefits that they’ve delivered — namely the ability of vendors to get things out to devs in a provisional way that has good fallback and future-proofing properties and the ability for devs to build with/for the future in an opt-in, degradable way.

Rounded corners, gradients, animations, flex box, etc. are all design and experience enablers that developers have been able to take advantage of while waiting for the standards dust to settle, and thanks to W3C process, it takes a LONG time to to settle. Yes, that has some costs associated with it. Henri is very worried that browsers that aren’t keeping up quickly will be “left behind” by webdevs who use only one vendor’s prefix. But surely that’s a lesser harm than not getting new features and not having the ability to iterate. And it provides incentive for following browsers to try to make a standard happen. What’s not to love? More to the point, I just don’t believe that this is a serious problem in practice. What front-ender in 2011 doesn’t test on at least two browsers? Yes, yes, i’m sure such a retrograde creature exists, but they were going to be making non-portable content regardless of prefixes. Assuming you’re testing fallback at all (e.g., by testing on more than one browser), prefixes not appearing on some browser are just the fallback case. CSS FTW! Webdevs who don’t test on more than one browser…well, they’re the ones hanging the noose around the neck of their own apps. Vendor prefixes no more enable this stupidity than the existence of the User-Agent header. Compatibility is a joint responsibility and the best each side (browser, webdev) can hope of the other is some respect and some competence. Cherry picking egregious examples and claiming “it’s hurting the web” seems, at a minimum, premature.

And how did we think we’d get a good standard, anyway? By sitting in a room in a conference center more often and thinking about it harder? Waiting on a handfull of early adopters to try something out in a tech demo and never stress it in practice? That’s not a market test (see: XHTML2), it doesn’t expose developers to the opportunities and tradeoffs that come with a new feature, and doesn’t do anything to address the inevitable need to integrate feedback at some point.

Yes, we could go with Henri’s suggestion that the first person to ship wins by default, never iterate on any designs, and avoid any/all first-mover disadvantage situations, but who among the browser vendors is perfect? And what would the predictable consequences be? I can only assume that Henri thinks that we’ll end up in a situation where vendors coordinate with the CSS WG early to add new stuff, will design things more-or-less in the open, and will only ship features to stable (no flag) when they’re sure of their design. That could happen at the limit, but I doubt it. Instead, the already fraught process of adding new features to the platform will be attempted by even fewer engineers. Who wants the responsibility for having to be perfect lest you screw the web over entirely? Fuck that noise, I’m gonna go work on a new database back-end or tune something to go faster. Browsers are made by smart people who have a choice of things to be working on, and any time you see a new platform feature, it probably came about as the result of an engineer taking a risk. Many times the engineers in a position to take those risks don’t have a great sense for what good, idiomatic web platform features might be designed, so they’ll need to tweak/iterate based on feedback. And feedback is painfully hard to extract from webdevs unless you’ve made something available in a tangible way such that they can use it and discover the limitations. Shipping things only to dev is perhaps a good idea for other aspects of the platform where we can’t count on CSS’s forgiving parsing behavior (the basis for prefixes). Syntax changes for JS and CSS seem like good examples. But for features that are primarily new CSS properties? Oy. Making the stakes even higher, reducing the ability to get feedback and iterate isn’t going to lead to a harmonious world of good, fast standards creation. It’s going to predictably reduce the amount of new awesome that shows up in the platform.

Prefixes are an enabler in allowing the necessary process of use, iteration, and consensus building to take place. Want fewer messes? There’s an easy way to achieve that: try less stuff, add fewer features, and make each one more risky to add. That’s Henri’s prescription, wether or not he knows it, and the predictable result is a lower rate of progress — advocating this sort of thing is much worse for the web and for developers than any of the harm that either Henri or Daniel perceive.

Which brings me to Henri’s undifferentiated view of harm. His post doesn’t acknowledge the good being done by prefixed implementations — I get the sense he doesn’t build apps with this stuff or it’d be obvious how valuable prefixed implementations are for work-a-day web app building — instead focusing on how various aspects of the process of prefixed competition can be negative. So what? Everything worth having costs something. Saying that things “hurt the web” or “hurt web developers” without talking in terms of relative harm is just throwing up a rhetorical smoke screen to hide behind. If you focus only on the costs but write the benefits out of the story of course the conclusion will be negative. In many cases, the costs that Henri points out are correctly aligned with getting to a better world: having to type things out many times sucks, creating demand among webdevs for there to be a single, standardized winner. Having multiple implementations in your engine sucks, creating demand from vendors to settle the question and get the standards-based solution out to users quickly. Those are good incentives, driven by prices that are low but add up over time in ways that encourage a good outcome: a single standard implemented widely.

And as Sylvain Galineau pointed out, what looks like pure cost to one party might be huge value to another. I think there’s a lot of that going on here, and we shouldn’t let it go un-contextualized. The things that Henri sees as down-sides are the predictable, relatively minor, costs inherent in a process that allows us to make progress faster and distribute the benefits quickly, all while minimizing the harm. That he’s not paying the price for not having features available to build with doesn’t mean those opportunity costs aren’t real and aren’t being borne by webdevs every day. Being able to kill table and image based hacks for rounded corners is providing HUGE value, well ahead of the spec. Same for gradients, transitions, and all the rest. Calling prefixed implementations in the wild a bad thing needs to argue that the harm is greater than all of that value. I don’t think Henri could make that case, nor has he tried.

I think the thing that most shocks me about Henri’s point of view is that he’s arguing against a process when in fact the motivating examples (transforms, gradients) have been sub-optimal in exactly the better-than-before ways we might have hoped for! Gradients, for example, saw a lot of changes and browsers had different ideas about what the syntax should be. Yes, it’s harder to get a consistent result when you’re trying to triangulate multiple competing syntaxes, but we got to use this stuff, get our hands dirty, and get most of the benefits of the feature while the dust settled. Huzzah! This is exactly> the way a functioning market figures out what’s good! Prefixes help developers understand that stuff can and will change, and they clear the way for competition of ideas without burdening the eventual feature’s users with legacy bagage tied to a single identifier.

So what about the argument that there might be content that doesn’t (quickly?) adopt the non-prefixed version, or that vendors can’t remove their prefixed implementations because content depends on it?

To the first, I say: show me a world where 90+% of users have browsers support the standard feature and I’ll show you a world in which nobody (functionally) continues to include prefixes. That process is gated in part by the WG’s ability to agree to a spec, and here I think there’s real opportunity for the CSS WG to go faster. The glacial pace of CSS WG in getting things to a final, ratified spec is in part due to amazingly drawn-out W3C process, and in part a cultural decision on the part of the WG members to go slow. My view is that they should be questioning both of these and working to change them, not blaming prefixes for whatever messes are created in the interim.

As for removing prefixes, this is about vendors just doing it, and quickly. But the definition of “quickly” matters here. My view is that vendors should be given at least as long as it took to get a standard finalized from the introduction of their prefixed version for the removal process to be complete. So if Opera adds an amazing feature behind a -o- prefix in early 2012 and the standard is finalized in 2014, the deprecation and eventual removal should be expected to take 2 years (2016). This has the nice symmetry of incentives that punish the WG for going slow (want to kill prefix impls? get the standard done) while allowing the vendors who took the biggest risks to provide the softest landings for their users. And it doesn’t require that we simply go all-in on the first person’s design to ship. Yes, there will be mounting pressure to get something done, but that’s good too!

The standards process needs to lag implementations, which means that we need spaces for implementations to lead in. CSS vendor prefixes are one of the few shining examples of this working in practice. It’s short-term thinking in the extreme to either flag the costs associated with them as either justifying their removal or even suggesting that the costs are too high.

And webdevs, always be skeptical when someone working on an implementation or a spec tells you that something is “hurting the web” when your experience tells you otherwise. The process of progress needs more ways to effectively gauge webdev interest, collect feedback, and test ideas. Not fewer or narrower channels.


  1. Posted November 18, 2011 at 8:57 am | Permalink

    Thank you for joining the discussion. I added a link and commentary to

  2. Posted November 18, 2011 at 9:07 am | Permalink

    It doesn’t seem strange to me that the browser vendor responsible of at least 75% of the prefix mess tries to justify itself.

    Yes, you are hurting the web because you START implementing features in your browser BEFORE taking time to send working drafts to the w3c.

    How do you want the w3c to “keep up” if you send the draft after your own implementation? It’s not possible. And by allowing authors to use the feature early, you just make the w3c discussion more difficult, because changes could “break compatibility with existing content”.

    If medical corporations were selling experimental drugs at large scale, they could maybe save lifes because they shipped early. But, clearly, it is not allowed today anymore because it has become clear that the risks are more important than the gains. When they are developing new drugs, there’s firstly an experimental period in labs and with a small amount of people. It takes time, but is what has allowed us to have faith in the drugs we buy. To me, it seems we are in the same situation here: testing should be reserved to testers. Don’t put the whole web at risk.

    If you are not going to change your egoïstic attitude with experimental properties because it gives you the lead, please be decent and say it loudly. Don’t find fake arguments.

  3. Posted November 18, 2011 at 9:08 am | Permalink

    Alex, this article starts with the premise that, vendor prefixes have been adopted widely hence they must stay. But, what we do not know (or never know) is if these properties would have found wide-spread adoption without prefixes? I assert they would have found such success with or without these prefixes (historical implementations of IE-only unprefixed properties seem to indicate this). Hence I do not see why we should restrict ourselves to a prefixed model.

    While Chrome is doing good in quick updates, same cannot be said of Android browser or Mobile Safari, in their glacial pace to update. Again, would all browser vendors commit to deprecating legacy prefixes in as short a time period as possible (say within the next 3 versions?).

  4. Sylvain Galineau
    Posted November 18, 2011 at 9:20 am | Permalink

    Man, this works way better than Twitter:)

    Lots of good stuff here but one note: I honestly never felt limited by W3C’s ‘amazingly drawn out process’. Quite frankly, I think that is a red herring. Specs have reached CR in a year in recent times. The only expensive step is test suite creation. That is not cheap but imo quite necessary in order to achieve interop (setting aside what kind of testcases are needed). Otherwise I don’t see where you get the idea the process itself is so onerous, especially in the CSSWG.

    Any big delays I have witnessed are 100% self-inflicted e.g. when half a spec has 4 implementations while the other half has zero and some heated debate is *needed* to agree the latter should move to the next level. Or when a widely implemented feature sits on top of a module that hasn’t been updated for two years. Blaming process may be more polite than blaming people; I find bad judgment or plain mistakes have far more of an impact than any process. The hard part of course is that often, the quality of a judgment is only obvious in retrospect.

  5. Posted November 18, 2011 at 9:29 am | Permalink

    When authors use all the vendor variants plus unprefixed in advance, how is iteration enabled better than if the iteration happened in the one standard namespace? Isn’t the level of breakage from iteration the same in both cases?

  6. Posted November 18, 2011 at 9:30 am | Permalink

    Hi Henri,

    Thanks for that.

    A couple of quick thoughts:

    • Vendors can have an arbitrary number of turns around the wheel so long as each property value grammar is incompatible with the other. Else, the prefix can be extended to include a new name/version. This isn’t one-per-vendor. Not sure why you assume it should be?
    • I’m not assuming maintenance of sites. Only that fallbacks are tested at *some* point. Vendors dropping prefix support is the same as the fallback being invoked.
    • Faster-moving browser upgrade cycles change the overall cost of the prefix dynamic. The challenge is going to be for the W3C to keep pace, but I have hope. Nobody wants to write things out 3 (or more) times and webdevs get to drop their use of prefixes based on *deployed browser population*, not spec status. Faster updates enable faster un-prefixing (among a bazillion other wonderful things).
  7. Posted November 18, 2011 at 9:34 am | Permalink

    Henri: RE: iteration in one namespace vs. many.

    Could work if the versions in the standard namespace are similarly incompatible, but it removes the ability to change your prefix (-ms-feature, -ms-next-feature, -ms-near-final-feature, etc.) as you iterate.

    More to the point, you’re not assuming that the deployed population of browsers *all* support the *same* right-hand-side syntax/semantics. That’s a dis-incentive for vendors to disagree and therefore bad for the competition of ideas.

    As a webdev, I want vendors to have their own opinions about how a feature should be exposed (if at all), not just to chase tail-lights or block on some WG scrum before trying things. I *also* want the argument settled quickly so that a winner emerges and we can all just drop all of the prefixes SRTL.

  8. Posted November 18, 2011 at 9:41 am | Permalink

    Sylvain: < 1yr to enter CR/Last Call? That's pretty good. What's MTTPR (Mean Time To PR)? I agree about people vs. process. Part of what I was hoping to illuminate in this post (but failed to, it seems) is that it's all people all the way down. Giving those people better tools and a better framework that sets them up for success is what I hope we're all gunning for.

  9. RichB
    Posted November 18, 2011 at 9:51 am | Permalink

    Everyone is ignoring the real problem exposed by vendor prefixes – that there are too many vendors.

    Browser monoculture FTW!

  10. Posted November 18, 2011 at 9:55 am | Permalink


    It’s a little difficult to take your critique seriously. I’m not suggesting that the W3C should “keep up” in perhaps the sense you mean…no WG should ever be a gate-keeper for experimentation. Instead, I want to see the WG continue it’s current fast-follower behavior which is primarily enabled by the vendors themselves attempting to throw the “we want to play nice, what do y’all think?” flag. How? By sending draft specs. It’s emergent social behavior and the first step in writing insurance on the feature. But don’t confuse that with asking permission.

    As to your medical analogy, well, I think you’ve simply lost all attachment to any reasonable perspective and have become unhinged from the reality of CSS’s reliable parsing algorithm. Hopefully you can find a way to be less angry some day.


  11. Posted November 18, 2011 at 10:32 am | Permalink

    @Alex: Yes, I’m angry on this matter. And reading your article actually made me angrier, especially the “Don’t trust the impletors, don’t trust the spec editor, listen to me instead” part at the end. Sometimes, being angry leads me to write hard words (especially in English since I’m not native English speaker and I find it difficult to express nuances).

    I hope it doesn’t hide the fact that more than 75% of the prefixed properties used on the web today are -webkit- ones and they have often no equivalent prefix for other browsers (meaning only webkit browsers can understand them, like in the old “IE-optimized” days).

    If those properties are useful (which they usually are) but are used widely on the web using a -webkit- prefix, I have to conclude that either (1) they were not ready to be used in production,(2) webkit devs didn’t gave enough time to other UA to understand and comment the spec before shipping in RTM or (3) the property is stable enough and should have shipped prefix-free.

    In those cases, I don’t see any other culprit for the prefix mess than the browser vendor that made misuse (intentionnaly or not) of them and has put other browser vendors and web authors in difficulty (using the webkit prefix or don’t use the property).

    To many, the response to this problem is simply to ship experimental properties in experimental builds only (with a prefix or not, I don’t mind), and ships in RTM builds when either (1) the spec has reached a consensus or (2) the spec will never get a consensus anytime soon but the feature is considered as needed by the implementor.

    Shipping in an RTM browser a prefixed property while the standardisation is in progress is a mistake. I would prefer an unprefixed property that support only cases that are known as stable enough.

  12. Sylvain Galineau
    Posted November 18, 2011 at 10:46 am | Permalink

    You may not have failed; the ‘living standard vs. w3c’ background noise is so pervasive lately that I may have missed the signal.

    And, by the way, I fully understand how, from a Ian Hickson Editor-In-Chief prospective, the W3C process is unbearable (‘What do you mean I can’t just go remove this element? I AM THE EDITOR!’). When worldviews and goals reach that level of opposition, one man’s bug will be the other’s feature.

    I have no idea what the MTTPR would be. I also very much doubt it would mean anything if it were to compare massive documents like CSS2.1 with modules like CSS3 Color; or if it encompassed a period of time where the browser vendor with a 90% market share was peripherally involved when it wasn’t outright absent. So while I do suspect the number would look horrible, there is such a cross-current of outlier inputs I very much doubt we could reach any useful conclusions about the W3C process.

    So yes, it is about people. And there are many aspects to that broad category. One of which being that we may not have enough editors, for instance. While up to 30 people might seat around the table at a WG meeting these days, how many are active editors? Is that due to the nature of the process? Maybe. Having ownership and accountability without authority is something few people are really good at managing. The level of expertise and amount of time required are also barriers regardless of how light you make your process. Not everyone can spec things like CORS or Writing Modes. The tooling is not very easy or forgiving either. I think Community Groups indicate some of those issues are understood. There is more to do.

    So the predictable and conveniently ill-defined swipes at the ‘process’ deserve some serious qualification to be helpful imo. I yet have to see standardization really harmed by process. I’ve seen it delayed by lack of consensus, unilateral editor decisions, spec neglect, low level of interest from implementors, feature creep or bloat, lack of testcases (we have modules that could be REC by now, but no test suite…) etc. The list goes on and on. Problems that can and do occur on many software projects, in fact. Pretending, even indirectly, that some process or methodology can magically fix them – or that the lack of either would – seems wishful and largely beside the point.

  13. Ojan Vafai
    Posted November 18, 2011 at 10:52 am | Permalink

    The problem is not using vendor prefixes. It’s now long it takes to remove them. It’s fine that features need to go to CR in order to remove the prefixes. The problem how long it takes the a spec to get to CR.

    The very optimistic 1 year to CR is not at all good enough when certain features in the spec are stable much earlier. We should redesign the process so that stable features naturally go to CR within a couple months of being considered stable.

    I made one such proposal here:

  14. Robert O'Callahan
    Posted November 18, 2011 at 2:59 pm | Permalink

    “What front-ender in 2011 doesn’t test on at least two browsers?”

    Most developers of mobile-focused Web sites, who test only on Webkit. This includes Google developers. When we’ve asked Google teams to change this behavior, they generally haven’t. I’m surprised you’re not aware of this.

    “As for removing prefixes, this is about vendors just doing it, and quickly.”

    Webkit, and by extension Google, has a de facto policy of never removing support for prefixed features.

    “My view is that vendors should be given at least as long as it took to get a standard finalized from the introduction of their prefixed version for the removal process to be complete.”

    The first vendor to introduce a prefixed feature usually benefits the least from browsers being allowed to drop prefixes. Your proposal adds an additional incentive for the first-moving vendor to delay standardization as long as possible.

  15. Boris
    Posted November 18, 2011 at 3:41 pm | Permalink

    > What front-ender in 2011 doesn’t test on at
    > least two browsers?

    90+% of developers of mobile sites. They all test in a single UA (WebKit) and move on. And since that UA actively encourages use of prefixes (pushing them extensively via developer documentation and so forth), this causes a good deal of harm to the web and to users, who end up being locked into a particular browser.

    Now you may happen to not care about this and think it’s not a problem, but the current situation with WebKit on Mobile is very similar to the situation with MSIE in 2000 or so, and just as bad.

  16. Posted November 19, 2011 at 1:03 am | Permalink

    To me, this is the money shot in Alex’s article:

    “And how did we think we’d get a good standard, anyway? By sitting in a room in a conference center more often and thinking about it harder? Waiting on a handfull of early adopters to try something out in a tech demo and never stress it in practice? That’s not a market test (see: XHTML2), it doesn’t expose developers to the opportunities and tradeoffs that come with a new feature, and doesn’t do anything to address the inevitable need to integrate feedback at some point.”

    We cannot simply wait until “it’s ready” to ship the features to real developers, because it does not expose the feature to enough real developers to learn valuable information.

    I, personally, do not know any developer who thinks that using experimental features is risk-free. Experimental features have the same expectations as library code (may change, become deprecated, or removed entirely some day), and *not* the expectations of fully specified code.

    Everybody needs to stop coddling those of us who build apps for a living, release features as available with the appropriate caveats, and iterate on them until we, *together*, arrive at a final, standardized solution.

  17. Jon Rimmer
    Posted November 19, 2011 at 8:20 am | Permalink

    I don’t see a spot of evidence in your post to back your assertion that vendor prefixes have been “critical” in accelerating innovation. Nothing suggests that Apple wouldn’t have shipped transforms, transitions, gradients and animations in Webkit even if prefixes had never existed. It seems clear that their decision to start adding proprietary innovations was based around a commercial desire to differentiate Mobile Safari prior to the release of the original iPhone, and I don’t think Dave Hyatt would have hesitated to add these features even in the absence of the fig-leaf of process-compliance provided by prefixing.

    What’s more, following that brief flurry of commercially-driven innovation, what great iterative improvements have their prefixed nature enabled? Endless bike-shedding over the gradient syntax has simply resulted in Webkit now supporting two syntaxes, both of will be available in perpetuity because their is too much production content using the original to ever consider removing it. Minor fiddling aside, transforms, transitions and animations remain basically untouched since their original implementation.

    Ever time I copy out a dozen identical, prefixed, properties, I curse the day the CSS WG decided on prefixing as a sensible approach. And I curse implementers like yourself who have the temerity to tell us they’re for our own good, when they’re manifestly for your own convenience, not in innovating, but simply in putting of the need to finish the specification and write a test suite.

  18. Posted November 20, 2011 at 11:54 pm | Permalink

    @Alex: We’ve had the prefixing policy in place for over a decade. It’s been use particularly much in the last four years. At this point, I think it’s fair to expect the dynamics that the policy gives rise to to have showed up. We aren’t seeing a dynamic where the same vendor implements a given feature in many iterations with different prefixes. Instead, we are seeing a dynamic where vendors implement a feature with a prefix once and then may keep doing non-breaking tweaks, but if a breaking spec change shows up, they stop changing their prefixed feature and start waiting for unprefixing.

    That is to say: I think arguments about what prefixing would theoretically allow are entirely unconvincing if we haven’t seen those things happen by now.

    As for testing solving problems: What roc and bz said. Consider the time from 2007 until now. I.e. the period when iOS was out in the wild but Mango was not. When Web developers during that time added -webkit-text-size-adjust, how often did they also add -ms-text-size-adjust for future IE on Windows Phone? How many of them are promptly going back and adding it? If they don’t and if IE on Windows Phone doesn’t support the WebKit prefix, surely it means that users of IE on Windows Phone get a worse user experience than users of Mobile Safari on iOS. That’s bad for users and bad for the competitiveness of IE on Windows Phone. Why shouldn’t this stuff just start working in IE on Windows Phone like insertAdjacentHTML started working in WebKit as soon as WebKit implemented it?

    IE on Windows Phone is facing a prefix barrier to entry that desktop Safari didn’t have to face when entering the desktop IE-dominated market earlier.

    @Ojan: Changing the W3C Process is harder than changing CSS WG policy or how vendors behave relative to CSS. That’s why I think it makes sense to decouple prefixing from CR, do what makes sense about prefixing now and worry about recalibrating CR later.

    @Yehuda: Part of the problem with knowing about risks is that Web developers are the ones that choose to take the risk but if the risk actualizes, users of other browsers and, by extension, the other browsers are the ones that suffer.

  19. Posted November 21, 2011 at 11:54 pm | Permalink

    @Henri the risks to other browsers could be mitigated if the working groups moved more quickly to approve recommendations that are gaining traction in the marketplace.

    Microsoft hasn’t exactly been rushing to move these specifications, so complaining that, years later, there is wide deployment of a proprietary prefix for what essentially became a proprietary feature feels disingenuous to me.

    Having brand-new, experimental and unvetted features land immediately without a prefix strikes me as irresponsible, but so does letting these features languish for years in the WG. Everyone’s problems, mine included, would be addressed by a more rapid pace of standardization of new (especially mobile) features.

  20. Sylvain Galineau
    Posted November 22, 2011 at 9:08 am | Permalink

    @Yehuda, there is a very significant difference between submitting specs that move too slowly – which by the way? and compared to what other modules? Animations and Transitions were submitted, edited as little then didn’t change for 2+ years despite three additional implementations – vs. never submitting features that are in wide use despite public requests to do so…..But implement the darn feature in a Beta for your phone and you’ll suddenly get a *lot* of feedback!

    The WG can deal with situations like Animations and Transitions eventually. If Apple won’t submit -webkit-text-size-adjust and a myriad other mobile features that benefit their platform, the WG could decide to standardize it for them which is doable but awkward on many levels; it really is the creator’s responsibility to submit their work. Yet even if the WG did this, subsequent implementations will not derive any benefits from their -moz, -o or -ms work until enough content reflects their existence. The end result remains an inferior user experience for anyone who does not use iOS.

    For some features -webkit is effectively no more than an inventor prefix. Maybe Mozilla, Opera and Microsoft should treat it as such and implement the feature using the exact same name? I think the web would be better off with some usable level of interop backing up a de facto standard than no interop and no standard.

    Most importantly, a well-designed process is no different than a well-designed feature: it makes doing the right thing natural and easy; doing the wrong thing should take work. The prefix system makes it far too easy for authors, editors and implementors to do the wrong thing:
    – For authors, it takes less work to couple your content to a single
    browser than to create cross-browser content! For careful developers who care about all browsers, copying/pasting the same value 4 times makes it completely natural to add an unprefixed version of the property; why on earth would a *standard* body mess with such a level of agreement?
    – For implementors, it rewards first-movers and offers no incentives to standardize a successful feature
    – For editors, decoupling the spec from implementations allows standards to diverge from deployed reality because “prefixed properties are not CSS yet”.

    No acceleration of the standardization pace will change the fact that misusing prefixes is essentially the path of least resistance for everyone.

  21. Posted November 27, 2011 at 8:45 pm | Permalink

    Geez, is that what happens when you work on Chrome? Forget about facts? Saying that “Vendor Prefixes Are A Rousing Success” is like trying to convince people the Earth is a flat disc.

    Vendor prefixes are not and will never be a success for a simple reason: vendor prefixes are browser specific, but the internet is NOT browser specific. Therefore, no one really uses them frequently as they are (a) NOT STANDARDS and therefore (b) not worth “learning”.

  22. Justin
    Posted December 1, 2011 at 5:16 am | Permalink

    As a very active web application developer, it’s clear who builds web apps, and who does not.

    +1 Yehuda Katz

    Btw, copying 4 lines for every rounded corner? Everyone uses LESS now right?

4 Trackbacks

  1. By Bruce Lawson’s personal site  : Reading List on December 5, 2011 at 3:29 am

    […] Vendor Prefixes Are A Rousing Success. I tend to agree with Alex here, but think that Robert O’Callahan makes an excellent point that Alex’s proposal benefits WebKit (and thus his employer, Google). […]

  2. By Vendor prefixes: the good, the bad and the ugly on February 7, 2012 at 5:04 am

    […] This divided opinion. DanielGlazmandisagreed in a point-by-point rebuttal, but Alex Russell was more emphatic still, saying “vendorprefixesarearousingsuccess”: […]

  3. By CSS Vendor Prefixes! | folktrash on February 9, 2012 at 2:30 pm

    […] pointed me to this: – #word. Also, -beta- would be better, though responsibility stays in developers […]

  4. By Misdirection | Infrequently Noted on February 15, 2012 at 4:04 pm

    […] Infrequently Noted Skip to content About Me « Vendor Prefixes Are A Rousing Success […]