Thoughts on the CSS prefix situation

The last week I’ve been contemplating whether to write anything or not about the situation with web browser vendor prefixes in CSS. I decided to share my thoughts on the problem and possible solutions.

Let’s me first start by saying that while I work for Mozilla, these opinions expressed here are my own.

The situation

We have lots of web sites out there, especially mobile targeted ones, where -webkit prefixes have been used in CSS code to achieve certain design or visual effects for the WebKit rendering engine, most notably available in Google Chrome and Safari. The impact of this isn’t a guess game either, but based on data collection and analysis for a huge number of mobile web sites out there.

There are a number of problems with this:

  • These features are implemented as experimental, hence the prefix, and generally not meant to be used in production code.
  • When web developers have been using them, they’ve usually just provided the -webkit prefix and none of the prefixes for other web browser vendors, i.e. -moz (Mozilla – Gecko), -o (Opera) and -ms (Internet Explorer) nor unprefixed versions.
  • While the idea with these experimental features is to become standardized, many aren’t, and also, some of those that become standardized might have a changed implementation when it reaches that level.

The effect of all this is that web sites might be perceived to offer users a richer experience in WebKit-based web browsers, and naturally, all other web browsers want their users to have that experience as well since they have implemented that support.

Blame game

When there is a situation, there will always be a blame game. I’ll address the most common ones and reply to them:

Developers should have never used prefixed features in production code
Sure, but I do understand developers here. They work to offer the best user experience for their user, and any technical capability that offers it to them, they will grasp it. Even if they know it’s experimental, I believe they take for granted that the same thing will be standardized in the same way (where how gradients changed in WebKit is a good example of the fact that it is experimental, and it might very well change over time). What you could argue is they should’ve added all web browser prefixes and an unprefixed version, but usually at the time of implementation, they had no idea if that would work or if the implementation in other web browser would be the same.
The W3C CSS Working Group haven’t been working fast enough to standardize things
It’s a given that a process where everyone will reach consensus and agree on the best implementation can take longer than for just one vendor to implement what they think. A number of the experimental implementations might never be fit to reach a standard level either, but is rather mostly there to prototype new features.
Apple and Google don’t remove the prefixes in official released versions, but keep the -webkit prefix
The problem here is that a lot of web sites implemented the features with prefixes, and they don’t want to break those web sites, just as Internet Explorer have kept support for certain features to make sure web sites specifically built for IE will continue to work.
The -webkit CSS features developers use don’t break web sites
I believe this is an important argument. While the CSS features people have used with -webkit prefixes offer a richer use experience, they aren’t features that render a web site completely unusable if they aren’t there. However, no other web browser vendor will want to have their user to have less of an experience if they have the same support.

I do believe that while it’s interesting to know how we ended up here, there are many factors at play. Personally, I’m more for focusing on possible solutions and how we move forward, instead of delving too deep into the past. Or rather, I believe there will never be consensus on why this has happened.

Solutions

The way I see it, we basically have two plausible scenarios on how to handle this:

Evangelizing

Everyone needs to start/continue blogging, tweeting and informing developers to use all web browser vendor prefixes in their code. Tell them to use solutions and technical alternatives to add prefixes for all web browsers that support that certain feature. Have web browser vendors – namely Mozilla, Opera and Microsoft – invest in campaigns to raise awareness.

It is a hard task to reach out to all developers, but in my experience most developers do want to do the right thing, they do want their users to have the best experience available, no matter which web browser they use. And just like we shouldn’t make the web experience better for users on a certain operating system or device just for the sake of it, we shouldn’t do that with web browsers either. It is our job, our duty, as developers to make things as good as possible for our end users. Because that’s what we do.

The argument is that will never work. Some say it’s too late, that it’s a WebKit mobile web and we need other measures to fix it. I hope that’s not the case and there is still time to make this good. Looking back at how Firefox managed to break the 95% market share of Internet Explorer, how we got people to understand the value of semantic code and strictness with XHTML, I believe there is still hope here too.

An example is the implementation of the alt attribute, something that Internet Explorer incorrectly rendered as a tooltip. Lots of users were upset this, thought the Firefox implementation should change, but they stood their ground. And eventually developers understood the distinction between those two, and finally Internet Explorer fixed their implementation as well.

Every web browser implements the -webkit prefix

The other alternative that is being seriously discussed is for Mozilla, Opera and Microsoft to implement support for -webkit prefixes, effectively making the web sites that only use a -webkit prefix for their CSS work in all other web browsers as well. This would not necessarily be for for all features, but rather for the most prominently used ones. This sounds like a bad thing – which it is – and it’s been compared to opening Pandora’s box. I believe that if it’s done we will keep a technical debt for some time to cover up for other implementations, and it will be very unclear to developers what will work where. More practical details about this can be found in Eric Meyer’s interview with Tantek Çelik.

An argument for this case is that part of breaking the Internet Explorer dominance we had a decade ago was to implement support for innerHTML and similar, just to cover up for all the web sites and current code out there.

Moving forward

So, how do we move forward? What will happen? Some people have suggested prefixes like -beta and @-vendor-unlock but one major problem with that is that the experimental implementation or syntax across web browsers isn’t necessarily the same.

I believe we are in a situation where web developers are getting jaded and just go for the simple route with a prefix for a feature they have seen. I think prefixes still play their role for experimenting, but they should not be shipped in official releases of web browsers. Keep them experimental, and if they are implemented in a final release, do so without prefixes; at the same time, this feature is something that has to have been standardized by then.

So, my suggestions are:

  • Make sure vendor prefixes only work in Nightly/alpha/beta releases.
  • Keep on evangelizing to developers.
  • If you build demos or give presentations, make sure to show code for all web browsers, point out differences and make people aware of how things work. If you share anything, that is your responsibility.

I don’t think it’s too late. I believe we have to work hard, but I sincerely hope we can solve this by reasoning.

And to conclude: by having a number of mobile operating systems out there that only allows you to use the pre-installed web browser/rendering engine, namely iOS and Windows Mobile, that is a situation that is much much more worrying to me than the prefix situation. Prefixes can be fixed and developers can be made aware and change. How do we change the above companies to inspire them to give the users choice?

23 Comments

  • Make sure vendor prefixes only work in Nightly/alpha/beta releases.

    Surely that’s not the solution?! Isn’t the point of having vendor pre-fixes that we can target a specific browser, not for support, but primarily because the implementation of the feature of browser specific.

    Removing all vendor prefixes or as a browser supporting prefixes other than your own makes the incredibly dangerous assumption that all implementations are equal! And if that’d be the case, then we could all agree that it is a de-facto standard and we wouldn’t need the prefix after all.

    It’s clear that the W3C is failing. Let’s be honest, nobody truly cares about what the W3C is saying. We only care about what works, what doesn’t and what is experimental. I can’t imagine it being hard for the browser vendors to create their own de-facto standard where they can clearly share information with developers on the features that are equal among the different browsers that support them.

    And if that is not the case, then the only sane option are prefixes. Removing them would mean we need to wait for the W3C to get their act together. Not going to happen any time soon. It would halt the development and adoption of features we’ve been seeing over the past couple of years.

  • David Bruant says:

    More or less the article I wish I would have written on the topic 🙂

    “The impact of this isn’t a guess game either, but based on data collection and analysis for a huge number of mobile web sites out there.”
    => I can’t help asking: how were these data collected? Where are they available?

    “I don’t think it’s too late. I believe we have to work hard, but I sincerely hope we can solve this by reasoning.”
    => Almost same question than above: How will we know when we’re done? How can we know for sure that prefixes can be removed or not implemented?

    About “Make sure vendor prefixes only work in Nightly/alpha/beta releases.”
    => I know you’re expressing your own point of view here, but is there a discussion started at Mozilla (or a bug) regarding this?

  • Robert Nyman says:

    Jeroen,

    I think you, slightly, missed my point there. I don’t want prefixes to go away, but I don’t want them to be removed from final products. They’re there for experimenting, and the implementations are bound to change over time, and between web browser vendors. The way they were always meant to be.

    I want them to be removed in final releases, and by then, there should be a matching standard that have to be equal. So, basically, vendor prefixed versions are for testing, unprefixed ones are ready for production use.

    I agree it could take longer, but looking at the adoption we have now with tons of web browser-specific implementations out there, perhaps halting it just a bit would be good for a uniform web.

  • Dan Jenkins says:

    I agree with points 2 and 3 and generally agree with point 1 but only agree with that if standardisation was far quicker from the vendor. How long did we have to wait for things like the hugely used rounded corners to be standardised? It’s great for experimental features with prefixed rules to only be available when they are still experimental, and not available to full release browsers but this could end up holding back the web; would issues be found as readily if they could only be found in pre-release browsers?

    It’s a very in-depth problem and one that I feel doesn’t have a good solution at all, except for developers to stop being lazy and to actually use other prefixes + the guessed standard/defacto standard in their code right now, there’s nothing stopping us updating code in production to use these new features if still in production/remove prefixed code in production if a standard is now available.

  • Ron Derksen says:

    An argument for this case is that part of breaking the Internet Explorer dominance we had a decade ago was to implement support for innerHTML and similar, just to cover up for all the web sites and current code out there.

    I disagree with this argument. The situation is very different. A decade ago, most websites were built for IE6, so a new browser didn’t have much choice but to implement features of IE6, or it would break 90% of the websites. The vendor prefix issue still only occurs on a small percentage of websites (I’ve read a number of 4%). So adapting other browsers to support -webkit- prefixes is like using a tank to kill a fly.

    I think the lesson we should learn from the IE6 story, is that support should move more quickly. Remove the prefixes as soon as the (de facto) standard has been achieved, even if that breaks some sites. This will force devs to fix these bugs (or giving them a way to convince their bosses to let them fix it).

    Finally, I agree (partly) with Jeroen. The W3C needs to move faster. They take too long to finalize specs (although I’m unsure how they compare to other standards organisation, like ISO).

  • Removing prefixes from the final release is in effect removing them all together. Having support for prefixes in pre-release versions doesn’t allow me to actually use them to my own benefit. I’d need to remove it from the implementation anyway, because I need to ship a working product. None of us does any real life work where we can do that and ship a product that assumes will be only used in pre-release versions of browsers.

    The distinction of prefixed implementations are for testing and non-prefixed is for production use is a bad idea as well. Because like we said, one can only remove the prefix if the implementation of the feature is equal among all browsers supporting it. And then we come to the point of standardization taking too long. For me that’s simply not an option and also unnecessary.

    The point of this discussion is not about having prefixes at all. The problem is the point, namely that there’s a fear that developers will only support one browser where they could have supported all of them with the same code. This would mean that a browser is perceived as less capable than the other one. And I agree that this is a problem, but the only true solution to this is evangelizing to developers as well as browser vendors.

    Browser vendors need to start getting their act together. They have a shared responsibility to their customers, but they also need to compete with each other. It’s natural for them to treat their support as a product and look for new features that would attract developers to use them. Taking that away would greatly slow down evolution in browsers we’ve seen over the past few years.

    So what do they need to do? Like any other company that releases potentially products that are, if supported by their customer, potentially incompatible with competitors, and a company that is not leading the market, they need to get together and do the 1 + 1 = 3 trick.

    That burden should not be placed upon developers. We just want to make great products and will support anyone that will help us do that.

  • Robert Nyman says:

    David,

    Thank you!

    I can’t help asking: how were these data collected? Where are they available?

    From a Mozilla perspective, hopefully this wiki page helps: CSS Compatibility.

    Almost same question than above: How will we know when we’re done? How can we know for sure that prefixes can be removed or not implemented?

    It’s a very difficult question, but my hope is that either it gets standardized and unprefixed, or it’s not meant to be. My hope is just that such a decision is reached much faster.

    I know you’re expressing your own point of view here, but is there a discussion started at Mozilla (or a bug) regarding this?

    Let’s just say that we talk and discuss this a lot. 🙂

    Dan,

    It’s an interesting argument. By people using prefixed features in a more widespread fashion, naturally the testing user base have gotten much bigger. If this have resulted in improved features or not a result of that, I can’t really say.

    But even if it did, it’s a high price to pay, though, looking at the situation we have today.

    Ron,

    I agree that the use of -webkit prefixes is not near the dominance Microsoft had with Internet Explorer. I’m not sure prefixes are removed fast enough, though, and we definitely don’t get things standardized as fast as we want to.

    It’s a difficult situation, with many nuances.

    Jeroen,

    The thing is, though, the prefixed features aren’t necessarily there for your benefit in a project, it’s more for testing. If that works out, it’s supposed to be standardized, become available for everyone and then truly benefit you.

    When it comes to web browsers, isn’t it much better to compete on grounds of web browser features, extensions, developer tools and what have you not, than implementing their own features on top of standards? I mean, I’m all for those experimental implementations, but not as a mean to compete. Rather bring the web forward for everyone.

    I do think part of the burden is on developers, to be aware of what they are using and make sure it works for as many as possible. But at the same time, it’s vital to get all web browser vendors and W3C to work faster together to standardize something.

  • When it comes to web browsers, isn’t it much better to compete on grounds of web browser features, extensions, developer tools and what have you not, than implementing their own features on top of standards? I mean, I’m all for those experimental implementations, but not as a mean to compete. Rather bring the web forward for everyone.

    How exactly? I’d just be waiting longer with the same result.

    I’m all for evangelizing, but that’s it. The vendors need to work harder and do a WHATWG to the W3C and go on their own.

  • Gijs says:

    Actually, something that I don’t see called out enough is that both Apple and MS representatives on the CSS WG have gone on record saying that this:

    “Keep them experimental, and if they are implemented in a final release, do so without prefixes; at the same time, this feature is something that has to have been standardized by then.”

    is not going to happen, because they will ship prefixed features and won’t offer them for standardization until after implementing:

    tantek: I think if you’re working on open standards, you should propose
    your features before you implement them and discuss that here.
    smfr: We can’t do that.
    sylvaing: We can’t do that either.

    They also said they cannot commit to removing support for the prefixed version later:

    Tab: There’s enough legacy content that there are some properties that we
    can’t drop the prefixes.

    alexmog: We will never drop -ms-, or change -ms- behavior.

    So these “high road” solutions of making prefixes a developer-only thing, and standardizing everything faster and before release, simply will not happen because of the commercial interests of some of the companies involved (I’m assuming that competitive advantage is the main reason they don’t want to standardize pre-implementation; it’d give away what they are working on before releasing it, giving time to their competitors to take away ‘their’ edge)

    All this means I consider all the suggestions regarding W3C process moot. Either evangelize, or implement -webkit- support, as Apple and MS have essentially blocked the perhaps “preferred” way to deal with these prefixes.

  • Robert Nyman says:

    Jeroen,

    I’d rather wait longer (not as long as it is now) and have something that’s agreed on based on experimental implementations, rather than having these experimental features be a reason for developers to cater to just one web browser.

    A WHATWG for CSS sounds like an intriguing and provoking thing. 🙂

    Gijs,

    Good point.
    I mean, I could only argue for things the way I think they should be. And as I mentioned in a comment above, I don’t think such features is a ground to compete on – rather compete on everything else making the web browser user experience better.

    If we want something balanced with longevity, all players need to seriously discuss and reach a compromise.

  • I understand that the situation of developers catering to one specific browser when that feature is supported by other browsers just fine, but I don’t think that’s a problem that should be solved by the browser vendors. A solution that likely will hurt the responsible developer whom does know how to use these features in the right way.

    The problem I have is with the use of the word ‘experimental’ though. So many of these ones aren’t really experimental anymore, just proprietary. Perfect for production use, but not standardized.

    Throwing a crazy idea out there, but how about Developer Tools flagging usage of prefixes that are standardized as warnings? Of course, backed up by a central site explaining the different flavors of the same feature, how to fix it, etc.

    Or reignite the craze of validation and focus on CSS validation where we can clearly tell the developer that he’s forgetting to support the other browsers when he perfectly can.

    I just prefer education instead of limiting the toolset and system for vendors. 🙂

  • Robert Nyman says:

    Jeroen,

    Now we’re talking. 🙂

    I understand that the situation of developers catering to one specific browser when that feature is supported by other browsers just fine, but I don’t think that’s a problem that should be solved by the browser vendors. A solution that likely will hurt the responsible developer whom does know how to use these features in the right way.

    I agree, that is very likely.

    The problem I have is with the use of the word ‘experimental’ though. So many of these ones aren’t really experimental anymore, just proprietary. Perfect for production use, but not standardized.

    True, and therefore we do need faster standardization. But we also need all players to be more open about what they work on to be able to speed up that standardization process.

    Throwing a crazy idea out there, but how about Developer Tools flagging usage of prefixes that are standardized as warnings? Of course, backed up by a central site explaining the different flavors of the same feature, how to fix it, etc.

    It’s a good idea, although I’d rather have warnings for prefixes that aren’t standardized. Or when you only have prefixes for one web browser.

    I just prefer education instead of limiting the toolset and system for vendors. 🙂

    Me too!

  • Boris says:

    > The -webkit CSS features developers use don’t break web sites

    See, this claim is false. Just ask Mark Finkle for examples of sites that are actually broken, not just kinda ugly, due to the use of -webkit prefixes. Think basic things like buttons not being clickable because something else covers them up because the layout is different.

    > The vendor prefix issue still only occurs on a small percentage
    > of websites

    Ron, this is true in general, but false for _mobile_ sites. On mobile, the situation is exactly like the IE6 one. Major sites like gmail are broken on mobile if you don’t implement some -webkit stuff.

    In case you missed it, this whole discussion is about mobile, not the web at large. It’s quite likely that Firefox would add support for some -webkit prefixes on mobile but NOT on desktop. That’s something that a lot of people reporting on this seem to have missed.

  • Aldrik says:

    The real problem is that identical implementations use different prefixes. So why not get the vendors to give credit to the group that came up with the feature and use their vendor prefix if implementing it in the same way (rather than always adding their own)?

  • Robert Nyman says:

    Boris,

    In my experience there have only been visual problems/a lesser user experience. However, I’m sure there are web sites that might break as well. But looking at the stats I’ve seen, it seems to be 1% of mobile web sites that use -webkit prefixes only. Which is still bad, but yet far from the IE6 situation.

    Regarding adding -webkit to mobile only yet: it seems likely, but it is not clear yet. Tantek said:

    “As far as implementing particular -webkit- properties, we’re currently weighing the option of supporting them only in mobile, thus limiting exposure, versus providing a consistent Firefox/Gecko platform for web developers that they can depend on.”

  • José says:

    Regarding not having the vendor-prefixes in stable releases, this would not work, since it would take years before a new feature could be used.

    These vendor-prefixes are supposed to be temporary, but I believe that it has already been said that WebKit will not be removing these “temporary” prefixes to avoid breaking websites. Which beats the entire purpose of having them in the first place.

    Why not just get rid of them? Does the spec change often enough that it brakes websites? And if it does, this would force the developer to update the site instead of evangelizing millions of websites.

    The vendor-prefixes should also be removed from the JavaScript API’s, its an awful mess to program the different vendor prefixes.

    Thank god that this did not happen earlier, or we would all have to instantiate the XMLHttpRequest object in 4-5 different ways.

  • Anonymous says:

    Personally, I like the proposal made in a comment on the article about vendor unlocking: have a registry of experimental features (probably maintained by a standards org), and have browser vendors request prefixes for each new property they want to add. For example, if a browser vendor wants to implement the “whizzy” property, they request and receive -exp1-whizzy. (No bureaucracy, no questions asked, so that browser vendors can easily do so during development.) If another browser vendor wants to implement whizzy the same way as the first, they just implement -exp1-whizzy. If a browser vendor wants to implement it differently, they request -exp2-whizzy. At some point, the standards organization can say “OK, let’s define the official whizzy as follows:”, ideally matching one of the experimental versions that browser vendors have agreed on. Iterative refinement at its best, with no stigma attached to creating a compatible implementation of an experimental property (quite the opposite in fact), and a path towards standardization.

  • George Ornbo says:

    A great write up of the issues. The issue is black and white for me. The prefixes allowed browser vendors to experiment before the standards were finished. Because the standards are still not finished eight years later we are now in this position. We must complete these standards. We can only imagine what the web will be in the future and if we don’t complete HTML5 and CSS3 we will have worse problems than the odd dangling browser vendor prefix.

  • Robert O'Callahan says:

    “While the CSS features people have used with -webkit prefixes offer a richer use experience, they aren’t features that render a web site completely unusable if they aren’t there.”

    Adding to what bz said about this not being true … sites that use -webkit-transform are very often unusable in non-Webkit browsers.

    And what you said is true as well, who wants to use a ghetto browser that doesn’t do rounded corners or smooth transitions?

    For people who point out the CSS WG moved too slowly to standardize these properties — the CSS WG members (at least those who do most of the work) are largely browser vendors, and do you know who was signed up to edit those specs and didn’t do it? APPLE. Who for all their wealth, haven’t hired a single full-time spec editor to work on stuff like this.

    Yes, other vendors should have stepped up to fill the gap, and that’s what we’re doing now, but it sucks to have one company shipping new features and dropping standardization on the floor and leaving it to their competitors to clean up the mess.

  • Alex says:

    I still think vendor prefixes are a good idea, the problem is that some people don’t treat them as the experimental properties they are, and instead consider them finalised implementations.

    I know a web developer who only uses -webkit- properties, just because it provides better support and lower maintenance than using standard properties, since WebKit never drops the behaviour or parsing. It doesn’t matter how fast the W3C moves when the initial implementation is a fixed unchanging constant.

  • Robert Nyman says:

    José,

    Personally, I do believe the vendor prefixes serve their place and offers web browser vendors a place to experiment. However, like you say, they are around way too long and it does take away the gain of experimental then.

    Same thing with JavaScript APIs, but I believe the situation is better there at least, in terms of removing them gradually.

    Anonymous,

    That would work in theory, but since Apple and Microsoft have claimed that they can’t be that open about their process, I have a hard time seeing that happen. Also, it’s experimental, so even if -exp1-whizzy might work a certain way to begin with, it constantly evolves and web browser vendors want the same feature to continue to work but with slight changes.

    It’s interesting, though, and something worth to be discussed at least.

    George,

    Thanks.
    And yes, I do hope some of these can be standardized as soon as possible.

    Robert O’Callahan,

    I’m sure there are cases, but I have not seen them yet. And from the statistics I’ve seen so far, only 1% of the mobile web sites out there use -webkit-prefixes only.

    It’s sad to hear that about Apple, and all I can say is that I hope that situation improves. I also do hope in the future for quicker standardization.

    Alex,

    I completely agree, and that’s the situation we’re facing.

  • Eric Eggert says:

    How is 1% a “situation” at all? Firefox should just trow an error in the developer tools/firebug if a webkit prefix is unmatched. (And even webkit should throw an error for unmatched webkit prefixes.) That’s what dev tools are for: Education.

  • Robert Nyman says:

    Eric,

    That’s only from what I’ve seen, though, and it might be another number. It’s a sort of situation and mostly a bad trend, I’d say. But i agree, Developer Tools definitely have their place here too to educate.

Leave a Reply to Eric Eggert Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.