Vendor Prefixes – about to go south

We do like vendor prefixes. They give us access to bleeding edge CSS properties, and make our sites look cool. But there’s a serious problem: non-webkit vendors are giving serious consideration to implementing the -webkit prefix to a number of CSS properties.

This is bat shit crazy, but where the web has arrived to. This is one developer’s opinion, but you need to voice your opinion now, and if you’re in agreement that this is madness, you need to act now. Make your voice heard, blog about it, tweet about it: make a lot of noise.

Keep updated A week after the meeting more people have contributed to the discussion, a few of the important ones (I felt) I have listed here – please do also read them as they’re a good follow up to the vendor-prefix kerfuffle.

Updated February 16, 2012

How is this a problem?

The CSS working group met very recently and openly talked about whether they should implement `-webkit` as part of the CSS specification in Firefox. This means other browser such as Opera and Internet Explorer could and would also implement these prefixes which would result in your site working™ in their browser.

Clarification update (via Peter Linss’ comments: this was not a meeting to propose adding -webkit- prefixes to the specifications, it was a meeting called by Firefox to seek consent for adding -webkit- prefixes. The bottom line that Linss has laid down is:

Having a vendor prefix in a specification will simply not happen, ever.

Updated February 11, 2012

Tantek led the conversation with:

tantek: At this point we’re trying to figure out which and how many webkit prefix properties to actually implement support for in Mozilla

plinss: Zero.

tantek: Currently we have zero. Zero is no longer an option for us.

The fear the browsers have, understandably, is that developers are coding for webkit prefixes in their CSS because they’re only targetting webkit based browsers.

Now that -webkit prefixes are so prolific in the wild (not my statement, but as suggested from the meeting minute notes), it seems the approach most want in the CSS working group is to simply implement the non-standard feature in to their specification. An oversimplification, but worryingly true.

There is some voice of sanity, namely in Daniel Glazman / glazou and Peter Linss.

You have to still appreciate the politics of the problem:

tantek: What are the thresholds, even approximate, for implementing -webkit- properites (or none)?

glazou: Unbelieveable we are having this discussion.

Florian: Our job is to solve interoperability. We want to discuss it here, because that’s our job.

tantek: Help us minimize the damage.

They’re trying to get interoperability: a good thing. But implementing other vendor prefixes in a browser is not the way to go about it.

On minimising the damage

Minimising the impact of this change is a misnomer. This is pandora’s box, no matter how you look at it. Once you add a single -webkit vendor prefix the expectation of the developer changes. If you can use a -webkit prefix in Firefox for gradients or transforms (for example), why can’t I use it for other things like CSS masks. And then other things.

If developers are lazy today (and we are – it’s what makes us fast and good), by adding -webkit prefixes to other browsers it’ll allow us to be even lazier, and by adding -webkit to the spec, the CSS working group will have set the precedence that we can, as developers, put any prefixes property in the other browsers.

At which point: webkit won the browser game and all other browsers should retire.

The only sensible step after implementing WebKit’s experimental properties is to simply adopt the entire render engine. A silly analogy, but you can see how you could get there.

The working groups are there to give us specs on how to do things the right way:

glazou: I don’t think this is the right way. And this is the first time in this WG that we are proposing to do things that are not the right way.

And then its affect on JavaScript

What concerns me even more is this:

glazou: I think it’s very unfortunate timing, esp. now that we’re trying to use prefixes for JS APIs.

We’re already starting to see things like MozWebSocket and the like. The only saving grace we have is adopting polyfill techniques – but ensuring we code against the right specification, and not vendor prefixed APIs.

I may be wrong, but I feel like the evangelism is strong in this area, and developers are keen to avoid prefixes – and there’s enough libraries that takes this problem away from devs.

CSS hasn’t been so lucky.

Who’s guilty?

Apple and Chrome: They’re supporting vendor prefixed properties like they’re a standard part of development.

Firefox, Opera and Internet Explorer: They should have been on the ball more. Need to push their evangelism further. Teach developers that it’s not exclusively -webkit to style elements.

All the browsers: experimental suggests that it will either be discarded or implemented fully at some point. It’s both not clear what’s a real specification be experimentally supported, nor when those experimental prefixes will be dropped.

The working group: for not getting these properties to standards quickly enough. The web moves quickly, and as much as a I appreciate that the standards will not move as quickly, they’re still taking way too long.

Evangelists: We’re too eager to show off experimental effects. They’re cool, right? But it’s cost us, and we should always used vendor prefixes as a backup, not as the final thing.

Developers: We know better. We know/hope that eventually these prefixes will be dropped, but we’re propagating this problem.

You and me: I’m just as guilty as everyone else in using WebKit only prefixes.

How I’ve been guilty and why

  1. I don’t know which browsers support which prefixes or values for that matter. Firefox never seemed to have interoperability with CSS gradients or transforms which made it hard to know what would work.
  2. I honestly can’t tell what’s a real property from the CSS specs compared to something made up by the vendor (from what I can tell webkit-text-size-adjust is one of those examples)
  3. I have absolutely no clue when the prefix will be dropped. Firefox held on to the -moz-opacity for a looooonnng time. This is my expectation for the other prefixed properties I use today.

What can we do instead?

This is the question that they group should be asking.

There’s things we can do as developers and evangelists, and there’s things the browsers must do.

As developers we need to better educate. It worked with moving to standards away from spaghetti code back in the height of XHTML-esque coding, it can work again.

We need tools to make it easier not to propagate this problem. Tools like csslint and -prefix-free are a start. I’m about to embark on a tool that will plug all the missing vendor prefixes too (not a JS solution like Lea’s tool, but a standalone service – help me if you can/want).

Browsers need to:

  1. Non-production ready browsers should support experimental prefixes, production ready releases should not. If it’s Chrome 16 – the stable version – experimental support should not be baked in. The properties should be full available without the prefix.
  2. Drop experimental prefixes – not entirely, but after a finite amount of time. It’s unacceptable and a disservice to the developers working with your browser. You need to give timelines to dropping these things.
  3. Work with the working groups (…Apple).

And more. Blog about it. Tweet about it. Make some noise. If this happens, the working group will have failed. I’ll leave you with this:

plinss: If we go down this path we have broken standardization.

Updates and further reading

35 Responses to “Vendor Prefixes – about to go south”

  1. Hear hear.

    An alternative option could be that if one party implements an experimental feature, and no other party follows within a given (short) time frame, that party can submit a standardisation process using their own implementation as the de facto standard. If other vendors did not show interest in a feature within the time frame, they probably weren’t interested in the feature and there should be no harm in standardising it in the “proprietary way” of the single existing implementation.

    And the prefix rewriting tool could be an intermediate solution but I think it hinges on it being served from a CDN (so that it can be updated and be kept actual). When added in a lazy enhancement thing, it should not cause problems for any browser. If you need help let m

  2. I believe the blame is on us, developers. We are caught too easily in the fancyness of the new features, that we forget vendor-prefixes are non-standar.

    I say, DONT use them in production sites. even if you still need to use images for gradients.

    Some may argue this may be too radical, but I think we need to stand our ground in defense for standars. Even at the price of immediate CSS-awesomeness.

  3. Couldn’t agree more… exactly my thoughts.

  4. I’ve been using khtml since konqeuror 1 and have always used a “webkit” based browser throughout my career as i like the way it renders the web and it seems the rest of the world agree. These vendor prefixes exist mostly because the lack of user base for webkit based browsers meant they didn’t have a high enough user base to be deemed worth listening to in driving forward the spec, however clearly have always had the best browser (gecko is still a joke IMO)

    The fact that other vendors want to use -webkit just makes me laugh as it were them that forced them to go down that route in the first place!

  5. The problem arises for browsers to drop support for prefix’s is that it should have been done years ago as a standard. But similar to the dilema of ie6 support that continued long after any sane person stopped using it. However sites were still coded dependant upon ie6 so business’ had to continually use ie6.

    Browsers won’t drop support for prefix’s and in fairness I don’t think they should be expected to, however they should support none prefix versions as well as the none-prefix.
    Then when educating developers in css, instead of as was widely done previously and still is rampant that educators showed code with -webkit prefix’s only. This is the main problem with the abundance of -webkit prefix rather than the others. Its not just the browsers that are at fault it is those educating developers.

    Both areas need work over time we can get there but leaping on just using -webkit is a short term fix and shouldn’t ever even have been mentioned. Hopefully some good does come from this mess and we can start progressing at a more rampant speed.

  6. Prefixr by Jeffrey Way is essentially the tool you’re talking about, I think: http://prefixr.com/
    Also there’s css3please.com and Compass for managing your prefixes for you.

  7. [...] Developer and author Remy Sharp has a very detailed post on the subject called vendor prefixes about to go south where he discusses the dangers of supporting alien vendor prefixes in [...]

  8. I agree that we need rid of vendor prefixes, but I think the first browser that drops them loses. We’re in this situation because webkit’s seen as “the best” as it has the most non-standard toys, much as IE6 was the best for its non-standard toys. If webkit turns round to its users, tells them they’re very naughty and takes away all their toys, Firefox can steal users by not doing that. Really tough.

    Also, the browser that keeps vendor prefixes gets better testing of those features (because people are relying on them for production sites) and hits the ground running whenever the CSSWG finally make the feature a recommendation.

    Although it doesn’t fully solve the problem, I like the initial idea discussed at http://felipe.wordpress.com/2012/02/02/a-proposal-to-drop-browser-vendor-prefixes/

    @-vendor-unlock {
      box-shadow: gecko, webkit, trident, opera;
    }
    ...
    #elem {
      box-shadow: 0 0 10px gray;
    }

    In the case of gradients, where the syntax for different browsers was different, we can rely on CSS’s error recovery. That would mean having (currently) 2 background rules per gradient, but that’s better than the 5 we currently have.

  9. [...] Remy Sharp weighs in on the same issue as the post I linked to earlier: We do like vendor prefixes. They give us access to bleeding edge CSS properties, and make our sites look cool. But there’s a serious problem: non-webkit vendors are giving serious consideration to implementing the -webkit prefix to a number of CSS properties. [...]

  10. I feel the prefixes got out of hand very fast. With HTML5 we got so excited about implementing the future that we completely forgot about how hard it was to work with incompatible browsers in HTML4. Rather, I think the browsers should depend more on their own upgrade schedules (particularly now that Chrome and Firefox are both on rapid-release). So what if border-radius is not fully implemented in Chrome 9? It will be in Chrome 10, or 11, or 12. If a parameter order gets changed from proposal to draft, that, too, is something that will not last (and often the browsers have shown themselves capable of supporting multiple shorthand orders). All the prefixes are doing is making our CSS ugly and invalid. (For example, if you want input elements to obey the CSS 2 box model, you must override the built-in stylesheets for all the browsers – with a vendor prefixed box-sizing property.) What do we get out of vendor prefixes that couldn’t have been implemented as simple prototype css?

  11. I completely agree with Enrique, stick with the standards and don’t be dazzled by vendor prefixes or next specification.

  12. I’m as guilty as anyone of developing in Chrome and using -webkit prefixes, which I then have to backfill with -moz and (gasp!) -ms prefixes to get some things working.

    What I think browsers should be doing is going towards an experimental prefix (-exp? -proto?) which they all agree on. So Webkit implements a new ‘foo’ property, so Chrome starts accepting:

    p {
      -exp-foo:24px;
    }
    

    Then, when Mozilla’s ready to support it, it can pick up the same prefix to implement it. Otherwise it gets ignored, as happens with other vendor prefixes. Finally, everyone supports it, ‘foo’ becomes a recommendation and everyone’s happy.

    Seems like a decent compromise – developers have experimental features that cutting edge browsers can implement, without having to declare four different vendor prefixes.

    Oh, and browser makers still have a fallback to their proprietary vendor prefix if they can’t agree on implementation.

  13. [...] with pre­fixes other than Web­kit, let alone writ­ing the unpre­fixed ver­sion at all. Remy Sharp makes some good sug­ges­tions on mov­ing for­ward (but I have some reser­va­tions about some [...]

  14. Seems to me like most of the solution just lies with webdevs. When little sites like… oh say Google.com (on mobile) decide that they don’t need to bother with support for more than one prefix, what other choice do browser vendors have? They can do one of two things, tell users to start using a different search engine (DuckDuckGo’s mobile site works brilliantly on all browsers, but I don’t seriously see a lot of users giving up Google for it anytime soon), or implement the CSS features Google refuses to fix.

    Evangelism has been going on for years now. Its failed. The fact that people on the committe are still campaiging for it is shocking to me, given many of them have sites that don’t property use prefixed css (i.e. evangelise yourself!). AFAICT, its just a lie and a stalling tactic, and most webdev’s honestly just don’t care.

  15. Le monopole de fait d’un navigateur ou d’un moteur de rendu est nuisible au Web ouvert…

    Il y a dix ans, les parts de marché d’Internet Explorer étaient écrasantes. Aujourd’hui, WebKit est un moteur de rendu particulièrement bien répandu….

  16. I can’t believe people are freaking out about the other vendors adopting a single standard. You really think it will harm the web if all browsers use -webkit- for experimental features? Besides, no one can keep up with the non-prefixed rules so forget it. All browsers should just adopt WebKit as their rendering engine so we would FINALLY have a single way to render everything. I’m sick and tired of writing special rules and code for specific browsers.

    Having one rendering engine is extremely effective and will speed along progress faster than ever before. It worked for Flash, it can work for CSS. WebKit is open source even, so what’s the problem?

  17. “Besides, no one can keep up with the non-prefixed rules so forget it” – But you can keep up with all sorts of less than well documented, experimental features? All standards w3 standards are easy to read and if the browser vendors would submit their proposals you could take advantage of non-prefixed versions with js-shims like prefixfree.

    If you think using webkit is easier I would argue that you are lazy and you don’t like testing in other browsers and when styling with tables was the way people structured their markup you were on board all the way, because it is “easier”. Table-styling was a mess and so was the vendor lock-in of ie6 specific features. We need to keep the standards process going, keep prefix use to a minimum.

    Most other sane programmers will not rely on “beta” code in a shipping piece of software.

    “and most webdev’s honestly just don’t care.” – Then they aren’t really doing their job.

    My advice is, be a bit more serious about your work. Take pride in doing a job that works on all platforms, is accessible and perfoms good.
    I know it is a toxic thing, the web, but it’s been cleaned up a lot the past decade.

  18. [...] read Remy Sharp’s article on the topic and his suggestions on how to [...]

  19. [...] Vendor Prefixes – about to go south 10 [...]

  20. They might as well do away with prefixes as they stand and just have a -beta- prefix that all browsers interpret their own way. After all, isn’t that essentially what they’re saying they want to do here?

    Of course the problem is then that the browsers are still going to have their quirks, the odd thing that renders in a slightly different way, and that was the beauty of having the platform specific prefixes while they were in development.

  21. I say: to the WG, “hurry the hell up with those standards”. To the developers out there, “be responsible in your craft or it’ll come back to bite you”.

  22. I totally agree. We need to have a timeline so we know when to expect these vendor prefixes to be cycled out and browsers start implementing THE standard- which should be moving at a much faster pace!

    Developers by definition are lazy (DRY), but it’s not practical to expect us to use vendor prefixes for some unknown timeframe until they are actually standardized. New css properties should be standardized rather quickly by the working group and then the browser should be using the vendor prefix to make sure they support it properly- and then it should be dropped.

  23. There is so much crazy in this proposal. If all browsers start adopting -webkit, does that mean that Firefox, say, could introduce a new -webkit-property that webkit itself hadn’t introduced? The mind boggles. And what if, like in gradients, different browsers use different patterns. Do all browsers have to go with whoever got there first, just because they’re all using the same prefix?

    I just can’t understand the thinking here.

  24. Peter Linss (plinss) February 11th, 2012 at 11:09 am

    There is one error in this article. The CSS Working Group never discussed simply adding -webkit- prefixed properties to the CSS specifications. Please correct that. This issue is important and contentious enough without spreading misinformation.

    Having a vendor prefix in a specification will simply not happen, ever. What has been discussed is simply adopting the WebKit implementations of those properties as the standard, however the standardized properties will not have the -webkit- prefix.

    The issue here is other vendors implementing support for -wekbit- prefixed properties in direct violation of the standards.

  25. @Peter – I’m keen to update my post to ensure it’s *not* spreading misinformation. I totally agree that this problem doesn’t need more fuel thrown on it.

    What I’m not clear on is if you’re saying that the discussion was *not* about implementing -webkit- prefixes (albeit a specific subset) in the CSS standards then why is the CSS working group even involved?

    If the issue is “other vendors implementing support for -webkit-” surely this is outside the remit of the working group?

    I’m not trying to bait an argument, just trying to get it straight in my head so I can update the post and point people to the update.

    Cheers – looking forward to your reply.

  26. Remy, the issue realty is “other vendors implementing support for -webkit-”. Doing this is actually a violation of the standard where the mechanism of vendor specific prefixes are defined (although while this was always clearly understood by the WG members, maybe it needs to be more clearly stated in the spec).

    Mozilla brought this up during a WG meeting seeking consent from the WG to do so (although a lack of consent is not in itself sufficient to stop them). To their credit, they are soliciting feedback on ways to do this while minimizing the negative impact, or potentially a way to avoid doing this altogether.

  27. I hope all browsers drop their prefix for all css3 pretty soon, that would obviously be the best way.

  28. and if anything I use -moz- a lot more than -webkit-

  29. I either bother with the full prefix stack or non at all. The majority of time I will go with the latter. Prefixes are a pain, and its a bigger pain going back into a project and looking for them. If Firefox want to adapt the web-kit mindset, then make web-kit drop the prefix and everyone implement it.

    What ever you do, adding prefixes as part of the standard is NOT the answer.

    I can see this becoming another “kill ie6 issue” in half a decade.

  30. Once a browser ships support for a non prefixed property, it’s prefixed counterpart should not work.

  31. I think developers are the most to blame.

    It’s totally fine for a browser vendor to allow vendor-prefixed properties. Otherwise how can people test stuff out and provide feedback. If I’m a developer (which I am) and I publish a web app and don’t update it in a timely fashion to correspond to specifications, then *I* am the one who is being lazy and irresponsible. The blame rests entirely on me. If Adobe pushes out the next version of Photoshop but fails to update/patch the product to stay in line with a platform’s API, do we blame the users, the OS vendor, or Adobe? Of course Adobe, since it’s their code. Likewise here.

    Having Firefox/Opera/Explorer implement support for interpreting “-webkit” CSS properties is a temporary band-aid solution that is only going to make already lazy developers more lazy and make otherwise disciplined developers lazy.

    Maybe browsers vendors SHOULD all adopt the WebKit engine and then all gang together and collectively improve upon it to make it the one [open-source] engine to rule them all. Then authoring websites and web apps will then be truly “write once, run anywhere.” Not kidding at all. Instead, we now have competing implementations where everyone is doing their own thing; the result is a 3-fold increase in effort, or basically a duplication of effort. So right now, for example, Mozilla invents something cool. WebKit then implements their version. Then WebKit does something cool and Mozilla re-implements their own version. And on and on. They say competition is healthy in the software world. But in this specific case I think it’s better to have a shared codebase or “ante” that everyone can add their stuff to. Individual vendors can still be innovative by contributing features to the main, shared codebase (or branching, testing, and, if kosher, then merging). So it won’t stifle innovation. Really, I cannot think of one good reason to have competing engines. I say we take WebKit and adopt that. Then take all the good things from the other engines and fold them in. It’s not as though anyone benefits from having multiple engines.

  32. One more thing. If we don’t end up using just one single engine and must support vendor-prefixed properties, here’s a cool idea: take something like LESS or SASS and combine it with some kind of web service which is kept up-to-date and knows all of the vendor prefixes.

    That way, you always only stick to the specification when writing CSS. When SASS/LESS preprocesses your code, it uses the web service to do a look up; it then adds vendor-prefixed properties to the resultant CSS. You could do some kind of caching, too, so that it doesn’t have to make a web service call each time you re-compile. “What about extensions that haven’t even been proposed to the WG yet?”, you ask. Well, the preprocessors could emit a warning when it encounters those.

    So in the end you have auto-updating CSS.

  33. Vendor prefixes baffled me from day one, whenever that was.

    Why did they ever come in to play in the first place? The only reason I can think of is to deal with differences in syntax between vendor implementations. That has barely happened (correct me if I’m wrong), the only example I can think of is the initial implementation of gradients by Webkit.

    The one thing I have noticed with new specifications; is that syntax barely changes during implementation in CSS. Some properties are so simple, such as opacity… Why the hell was that prefixed? Not much could go wrong there…

    In my opinion, instead of introducing a universal prefix for experimental features, just stop implementing future features with the prefix… Simple, no? This may break code, but it’s the developers fault for using experimental features in the first place without taking into account the consequences.

  34. I totally agree. We need to have a timeline so we know when to expect these vendor prefixes to be cycled out and browsers start implementing THE standard- which should be moving at a much faster pace!

Leave a Reply
Not required

CODE: Please escape code and wrap in <pre><code>, doing so will automatically syntax highlight