The Prefixolypse is upon us.
For the past few years, one of the ways CSS has advanced is through the use of vendor prefixes. According to the minutes from a recent CSS Working Group meeting, that framework may be about to collapse.
Here’s my take on the coming Prefix Armageddon.
Getting people to agree on things is not always easy. That seems even more true for anything to do with the web.
Web standards are essentially about agreement. We all agree that if web developers write this line of code, web browsers will handle that code in this particular way.
But agreement takes time.
There has always been a struggle in the web, between innovation and agreement. Between trying out exciting, new things that make the web better, and coming to an agreement on how the web works.
If we had waited for everybody to agree, there might not be an <img> tag today, or at least not in the same syntax.
In the Dark Times of the web, during the Browser Wars, the web moved forward primarily through browser-driven innovations. Netscape and Internet Explorer each introduced their own tags, and it was a mess, because there was little agreement.
The Web Standards movement helped push browsers to agreement. This was good.
But since then, the web has clamored for more innovation. Let us be frank: the original methods for CSS layout were awful. Creating the web by slicing up images was an enormous pain. Tabs, rounded corners, shadows, gradients, columns, much less layout grids, all pretty much awful.
The trouble was that when browsers were introducing their own tags and rushing into implementing new CSS features before there was agreement, problems swiftly arose. If Browser A implemented feature X using method G and Browser B implemented feature X using method H, what do you do when Browser A and B instead decide to implement feature X using method L?
If there are sites out there that are already using method G, and there are other sites out there using method H, what is to be done? Sure, Browsers A and B might support method L in their new versions. But what about all the existing sites? Should methods G and H still be supported? Should Browser A support Browser B’s old method, and vice versa? If methods G and H are just abandoned, then sites that are not updated will simply not have feature X in newer browsers. Maybe that is ok: after all, it is ok for sites to not look the same in every browser.
However, the method that was developed to get past this problem was vendor prefixes.
Because agreement takes a long time, and because the web needs to keep moving forward, vendor prefixes allowed Browser A to implement a new method by saying -browsera-featurex, and at the same time Browser B could do something slightly different with -browserb-featurex.
Probably the most prominent example of this has been the gradient feature: Webkit and Mozilla implemented two different, incompatible versions of the feature. In the end, Mozilla’s version turned out to be the winner. Huzzah!
What is great about this approach is that it allowed web developers to support a new feature, even if two browsers had different syntax for that feature, without resorting to browser sniffing or CSS hacks. This is a good thing.
The trouble is that one particular browser, Webkit, has been pushing out vendor-prefixed features faster than other browsers. The upside of this is that a lot of great CSS ideas have been put out there for people to try. The bad thing is that when other browsers have been slower to adopt these features, web developers have not necessarily bothered to put out prefixes for other browsers, either because a particular browser might not have implemented that feature yet, or because a demonstration highlighted the Webkit syntax, and the developer simply put that version into code, even if another browser had a vendor-prefix for that feature as well.
This has gone on to the point that a lot of sites that only implement Webkit prefixes are not looking as nice in other browsers, even though they could look much the same if developers used prefixes for other browsers as well.
Does this mean that Webkit is pushing proprietary CSS features? Or does it mean that the W3C is slow at coming to agreement on which browser-initiated CSS features should be implemented for everybody? When developers only use Webkit prefixes, is that Webkit’s fault? Or is the slowness of other browsers in adopting new features part of the problem?
Or is this the fault of developers, who are too lazy to write separate lines for -webkit-, -moz-, -o- and -ie- every time a new CSS3 feature is used? Or for not using a CSS preprocessor, like SASS or LESS, that handles those mechanics for the developer?
I don’t know, and quite frankly, I don’t really care who is to blame.
The reality is that some browsers are talking about processing Webkit-prefixed CSS declarations, even when they are not using the Webkit engine.
If this happens:
- Developers will be even less motivated to write non-webkit feature prefixes, because if other browsers will still work if they just use the webkit version, then they can save lines of code by just writing webkit.
- The entire point of vendor prefixes pretty much goes up in smoke. What is the point of having different versions of a feature for different browsers if there is no difference in how they are handled?
So what is the alternative? Do we just work on educating developers to make sure to use all vendor prefixes when they write code? Should they do so, even if that particular browser does not yet support that feature? If they do, what if that browser adopts a slightly different syntax? What happens when the W3C does come to agreement, and the syntax is different from one or more vendor-prefixed versions? How do we handle all the existing sites, that may or may not be updated to the new syntax?
Personally, I think the focus on browser-specific versioning of features is misguided and lies at the root of this problem.
What I would rather see is that if Browser A wants to implement a new feature for a property that does not exist yet in CSS, they could register their proposed feature with the W3C. The syntax could be -v1-featurex.
Developers could start using this feature as the W3C debates it. If another browser agrees with how that feature is implemented, awesome! Now they can start supporting -v1-featurex, too. And when they do so, developers would not need to go back and amend their code.
What if Browser B wanted to use a different method to implement feature X? Ok, then they register -v2-featurex with the W3C. Developers can then start to also implement -v2-featurex, either instead of or alongside -v1-featurex.
If Browser A decides that version 2 is better, great! Then they can start supporting that version of the syntax as well. Whichever version is last in the code could win.
When the W3C forges an agreement on featurex, then Browser A and B can support the non-prefixed versions, and developers can start using the non-prefixed version, too.
Now here’s the key: Browser A can still continue to support -v1-featurex or -v2-featurex or whatever if there is no non-prefixed versions.
Does this lead to browser bloat, by supporting multiple versions of the feature? Yes.
However, the upside would be that sites would not break. If sites have not been upgraded to drop the version prefix, or to use a newer version prefix, they could still work just fine, in whatever browsers decided to support that version of the feature.
The web would break less: this would be good.
The other upside? If another browser engine comes along, no worries. Developers don’t need to go update their code to add in a -newbrowserengine-featurex in dozens if not hundreds of lines of code. The new browser engine could simply decide what version of a feature to support, and voila!
I am not saying we need new browser engines, but this would reduce a significant barrier to entry to additional competition.
Maybe this is crazy, and there are a dozen reasons why this wouldn’t work. I am not involved in the W3C.
This is just one idea on a better way to handle the vendor-prefixing problem.