The TL;DR vendor-prefix post

With my post yesterday I appreciate it might be a bit long and perhaps focused mostly on my take on the meeting minutes. I wanted to be super clear about what I think about the situation, what will happen and what we can do – in super easy bullet form.

  1. Browser vendors for Firefox, Opera and IE will eventually implement -webkit- prefixes (a subset). Sad, but true. It’s an amazingly bad idea, and I’d love to be wrong, but browsers are like bulldozers, they’ll go where they want and more importantly: need to go.
  2. Vendor prefixes are a good thing. Or rather experimental prefixes are a good thing. They allow developers to test and feed back to vendors.
  3. Vendor prefixes should be dropped from production level browsers and only made available in beta browser versions.
  4. Point above will not happen (or at least in the short term). Google and Apple have said as much. This was the same reasons Microsoft gave: they didn’t want to break the web. Microsoft did eventually drop propitiatory tech like CSS filters (well, it vendor-prefixed it, but the effect non-prefixed is “broken” in IE9), so maybe in the future this may happen.
  5. Maybe the middle ground is we draw a line in the sand, and say: All current prefixes will remain as they are (WRT production browsers). All new experimental properties will have a finite lifetime, and not make it to production.
  6. Yep, the working group should move faster to retire beta technology (if it works), but this hasn’t happened any time soon (see the irony?!).
  7. Do not go duplicating every -webkit- prefix you find: they’re not all supported, nor are all the values always the same. Use your head, obviously! This needs to be done on a case-by-case basis. ie. Add -moz- et al for -webkit-border-radius but when you encounter linear gradients the syntax is different.
  8. Do check your code against tools like csslint – it will tell you which vendor-prefixes can be reused today. I’m close to having a tool ready that will automatically fix these for you – but to be clear: this will only stem the flow of the wound, and doesn’t fix it ultimately for the future.
  9. Should all browsers use the WebKit render engine? Hell no. WebKit would continue to innovate until it was finished, then we’d have that really long quiet period that Microsoft demonstrated with IE6, where expectations move on but browsers don’t. No, this a stupid suggestion.
  10. Don’t stop evangelising. It’s a slow slog and is never a completed job.

11 Responses to “The TL;DR vendor-prefix post”

  1. Why are we giving Google/Apple a special treatment? There was a serious dev uproar when Microsoft didn’t want to “break the web”! We didn’t let MS abuse their close-to-monopoly market position – neither should we allow Google/Appled do that. Just sayin’…

  2. Good summary!
    One minor addition to the statement about linear gradients: they do have the same syntax now, but the initial WebKit implementation had a different one.

  3. Hi Remy – I totally agree with your points above. Although it would be a fairly “drastic” change… I think PPK’s suggestion of an “alpha” (expect behavior changes) and “beta” (basic conceptual behavior & syntax is ready) prefixes might actually be a good way to handle the various scenarios needed. http://www.quirksmode.org/blog/archives/2012/02/alpha_and_beta.html

  4. I first read the beginning of #10′s last sentence as “it’s a slow SNOG,” instead of “slog.” And I thought, uh, no, evangelizing is important and all, but not really anywhere near as pleasant.

  5. #9 is in conflict with pretty much the rest of your points though. If everyone should implement the standard and only the standard and put only that into production browsers, what is the point of other rendering engines?

    You then put the onus on everyone to agree to a standard quickly and implement that standard quickly. Politics are slow and this is utopian, unfortunately.

    Also, by not putting out the vendor prefixes in production browsers, there is no reason for developers to use them in pre-production browsers. There is no ability to determine if said prefixes will be standardized by the time you ship. So you either waste lots of man hours on using prefixes that may not be there, or you waste lots of man hours on mimicking the behavior of the prefix, or you keep with your LCD design.

    So, we are stuck in a world where we are bound by essentially four browsers moving at different paces all with different agendas: Chrome, FireFox, IE, and Safari.

    As much as vendor prefixes suck, I love it when I get better usability from my browser, especially mobile browser, when devs took the time to make use of some of the browser specific functionality that hasn’t been made a standard yet.

  6. I agree with Steve — PPK’s vendor-wide alpha and beta prefixes are the best solution I’ve seen so far. And the idea is 2 years old: http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref_1.html

  7. With all respect but point 9 is pretty senseless from my point of view.
    First you can’t compare WebKit with IE – neither technically nor politically. IE is a WebBrowser with closed source. WebKit is not a browser but an open-source HTML and CSS rendering engine.
    With that said why in God’s name should the development in WebKit stagnate? Apple and Google have their own fork of WebKit. Both companies push the the project forward with their own ideas.

  8. @David Owens – erm, I’m not sure how #9 is conflict with all the previous points. We don’t need one render engine does not conflict with browsers will implement what they want. And does not conflict with vendor prefixes are a good thing. And does not conflict with experimental features should be in experimental browsers, etc, etc. I don’t think vendor-prefixes suck either – aside from your opening, I think we agree… :)

    @Markus – that’s fine to have your point of view :) As with many others, I was there when IE4, IE5 and IE6 came out. They were the best of the very best and amazing forward drives in innovation on the web (both with it’s filters and dynamic HTML). I never expected, upon release of those browsers that I would come to shake my first so much at poor old IE6. We have different points of view – neither of us know the future, so until then, we’ll agree to disagree :)

  9. The goal of your points seem to be: implement the standard and only the standard in production browsers. Thus all browsers should behave exactly the same way. Correct?

    If that is correct, what is the point of other CSS and HTML rendering engines? They should all act exactly the same. Differences on the non-vendor prefix tags are either a bug or due to ambiguity in the spec: both very bad things and drive divergence on websites.

    It would seem better for everyone involved to use a common engine, we can name Webkit, for all standards approved CSS and HTML specifications. That way everyone is working from a common base.

    Browser vendors could then build on that with their own browser extensions.

    But back to your point about shipping browser extensions, there still are not practical needs that need to be met: how does Apple (just as an example) implement special touch functionality in their browser for their iOS devices if the standards body doesn’t approve what they need and there is no alternative?

    I guess I see -webkit as not experimental, but core functionality requirements for that browser. Yeah, maybe (and hopefully) based on recommendations to the standards body. An experimental feature, in my mind, is like WebGL. That is rightly not included in production browsers.

    And I do completely agree that FireFox implementing -webkit is retarded. =)

  10. “Vendor prefixes should be dropped from production level browsers and only made available in beta browser versions.”

    I kinda thought similar today on my own website. Maybe they should only be enabled when the browser has “developer mode” enabled in the advanced options.

  11. I think prefix-free deserves a mention.

Leave a Reply
Not required

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