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.
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.
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.
The way I see it, we basically have two plausible scenarios on how to handle this:
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.
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?