Browser Wars II

There’s been a storm of commotion around Opera’s announcement a few days ago that they plan to alias the -webkit- vendor prefix for CSS properties. I wrote about my take on the matter, albeit hurriedly, and it caused a lot of debate around the issue. Most people reacted very negatively to the news; some, with joy. I myself experienced mixed feelings on the matter, but yesterday, during my talk at Converge SE in Columbia, I vocalized those feelings more clearly than I had written them down in my article. I’d like to clarify a couple of things and address the questions that many people asked online.

What is the situation on the web that caused Opera (and Mozilla and Microsoft?) to decide this?

As mentioned in my previous post, too many websites out there today are built to use a feature first made available in WebKit, and have not been built or updated to support other browsers for those same features. In many cases, particularly on mobile devices, the result was a truly broken website for users of non-WebKit browsers.

Vendor prefixes in CSS were introduced to provide browser vendors the ability to implement new features without using a completely proprietary and CSS-incompatible syntax, thereby allowing web developers to experiment with said features in the knowledge (or so it was hoped) that it was an experimental feature, meaning: not meant for production use.

Conceptually it was a good idea, but the past five years have shown us that it was not a particularly realistic idea, in that it did not align with the realities of developers’ workflows. Vendor prefixes just cause more harm by their inherent increase in development complexity, than they ever managed to solve.

In Opera’s Developer article on the matter, Bruce Lawson succinctly explains why this system did not work:

The vendor prefix system is hard to use. It’s easy to miss out a vendor prefix when copying and pasting multiple lines, or because a vendor doesn’t support a certain feature while you’re developing. Some specifications seem to take forever to get to the Candidate Recommendation stage at the W3C, after which vendors are supposed to unprefix their implementations. Some developers erroneously assume that mobile development equals iOS devices, so only use -webkit- prefixes because they don’t know or don’t care about other browsers. There are many reasons for missing out some prefixes – but the user is always the loser.

Two key points in that paragraph. First, the CSS standardization process is too slow to keep up with the pace of new features being implemented, thereby failing to convince web authors to play by those rules. Second, when a browser doesn’t support even a prefixed version of a property for a really long time—see Opera’s CSS Animations implementation—it runs the risk of being ignored by developers because they can’t test in it. And browser vendors have very legitimate reasons not to hastily support just any and all features that some other vendor implements and writes up a spec proposal document for.

Who’s to blame?

This problematic situation is an organic one, caused by a multitude of factors. The influences come from developers failing to write CSS in proper, accessible ways (i.e. creating usable fallback situations), browser vendors not keeping up with one another on the coolest features that developers are playing around with, the CSS Working Group being very slow on moving spec proposals through to Candidate Recommendation stage, and, what I extensively explained in my Converge talk, the fact that too few parties—from wherever they may have come—stepped forward to create better tools for web authors to use. Tools that wouldn’t just help developers get the job done, but that would make it easier for them to get the job done right.

The disgruntled tone in my previous piece stems from how Opera and Mozilla were placing the blame seemingly squarely in the hands of developers for failing to write proper-enough CSS. This problem, however, is not their problem. Developers don’t really care much whether Opera has a 2% market share or a 10% market share, Firefox a 30% or a 15% share. What they care about is whether the browsers with the largest market shares offer the cool features they want to build their sites and applications with.

This is why the incentive has been comparatively low with the web developers, while it has been much higher for the browser vendors that aren’t using WebKit. It is in their business interests to facilitate web developers as best they can with tools that help them get the job done the right way. Opera spends a lot of time and money (through its team of evangelists) on reaching out and educating people about web standards and proper development techniques; this effort, on its own, has long proven to be insufficient to persuade enough developers to care.

Developers are simple beings—speaking as one myself—who, for the most part, care about doing things the right way only to a point. Beyond that, we need incentives. Strong incentives. In the first Browser Wars, the evangelism message from the Web Standards Projects and likeminded individuals—again, like myself—was that developing and testing would be “significantly easier if you build with standards” (and, earlier on, if the browser vendors would build their browsers according to those same standards). And it was true: building with standards when browsers were implementing those standards was significantly easier.

This time around, however, we already are using standards, so the fine line between “using standards” and “using standards and vendor prefixes exactly the right way” is not convincing enough. “What’s in it for us?”, we wonder. Developers need stronger incentives than that—and no, unfortunately, “being accessible to all users” is not something that all of them care strongly enough about, even though they should. Stronger incentives which probably don’t exist, leaving just the one alternative: they need these things taken care of for them by way of better tools. And that’s exactly what didn’t happen.

Is Opera’s decision good or bad?

The answer depends on who you are. Are you a daily Opera user? If so, then Opera’s move will improve your web surfing experience. Their decision is the right decision for their customers, and ultimately Opera remains a business who aims to serve their customers well.

If you’re a web designer or developer who frequently uses CSS3 features—however it is you do so—then their decision is of little concern to you. Assuming Opera doesn’t introduce some incredibly weird and egregious bugs in their aliasing implementation, your work process will not be affected. You should still do your job as best as possible and use vendor prefixes cautiously and precisely; beyond that, Opera’s decision doesn’t affect you.

Now, if you’re a standards advocate or enthusiast, or the creator of tools for web developers, your job might well become a good deal more complicated again. Members of this group are likely also members of the second group, and some will even be a member of the first, but it should be noted that only standards-advocacy and tool-creation related aspects of their work will be negatively affected by this decision.

Is it just Opera, or also Mozilla and Microsoft?

While I don’t believe Mozilla and Microsoft have officially announced anything yet, it is believed that they will follow in Opera’s footsteps shortly. Opera is probably the browser that is most affected by the situation of the web today, but Firefox and IE have much larger audiences and so even a smaller impact to them makes it well worth taking the same course of action. Mozilla is fully expected to make this same decision, as they have previously gone on record arguing for this move.

UPDATE: Microsoft has taken the official position that they will not implement the -webkit- prefix in IE.

I hope this lengthy post clears up what unanswered questions you may have had.

If you liked this, you should follow me on Twitter!