The Open Web Needs You Now

I agree with helping Mozilla and Opera, because they are good citizens of the open web community. But I disagree with helping Microsoft. We should make sure the IE-nazism episode never happens again by forcing them to implement one of -webkit- -moz- -o-.

Either the web is open for everyone (including Microsoft), or it's closed. There is no middle ground here.

Long experience of contacting sites suggests that it is, at best, of limited effectiveness. At Opera we have a not-insubstantial team dedicated to developer outreach who frequently contact sites that are broken in Opera and give them help to get stuff working again. But the approach doesn't scale; we can only contact so many broken sites and we can only get so much traction being proactive and asking people not to depend on new, shiny, but single browser, stuff.

I think it is instructive to examine how the incentives line up for various players here.

* For high-marketshare browser engines:

Prefixes are great. It allows them to release whatever new stuff they like whilst avoiding the bad rap that Microsoft got for releasing proprietary things like XMLHttpRequest. This makes them look innovative, which gets them lots of press. It also makes it impossible (thorugh the "you won't implement other people's prefixed stuff" social contract) for their competitors to implement the new things and, even once the others do implement, the existing content won't work, helping protect their marketshare. Of course you can't ever drop the prefixed property, but there is no social stigma for this, so it isn't a big deal.

* For leading-edge web designers:

Using prefixed properties in demos is a no-brainer. They allow you to create novel effects which you can then discuss in your blog, so improving your reputation and social standing in a competitive market. The fact that the sites won't work in multiple browsers is irrelevant to you because you are mainly targeting other designers who will have a full set of browsers installed.

* For web designers working on client projects

Using prefixed properties is attractive, particularly on platforms where there is an unhealthy balance of rendering engines. It allows you to make designs that look like the leading edge demos — indeed your clients may be demanding this. You can rely on vendors never dropping prefixes and by the time the next major shift in browser marketshare occurs you probably won't have to maintian the site anyway.

* For the CSS WG:

Well obviously this is composed mainly of people from the other groups. But the main argument they use in favour of prefixing is that it allows them an unbounded amount of time to tinker with new proposals whilst providing a convenient excuse to ignore the legacy content that has built up in the meantime. This means that in the future there might be fewer people who have WTF-why-is-it-like-this moments when using CSS and decide to blame the working group. Therefore they think that prefixes are good.

* For non-dominant-marketshare engines:

Prefixes suck. You put a huge effort into implementing some new feature that someone else released under a prefix, release it, and it probably doesn't cause a single site to work better. You have to hope that authors start to include your prefix (even though there are probably legacy tutorials that don't mention it) or already included it by adopting the scattergun "add all the prefixes I can think of and hope the syntax doesn't change" methodology. This affects your ability to attract new users.

* For new entrants to the market:

This is an extreme case of the above. Prefixes are an enormous barrier to entry.

* For end users:

Prefixes suck. They increase the difficulty of changing browsers because they increase the chance that sites will break. This makes it harder to choose your browser on the basis of features like UI, privacy controls, security performance, etc.

So we have a solution that is good for vendors with dominant market positions and bad for users. That seems pretty anti-open-web to me. In the long term, I think the solution is to get over the idea that it is OK to keep fiddling with features once there is content that depends on the existing implementation; i.e. you have two options: "don't ship" or "ship and accept the legacy you create". That means no prefixes in CSS, just like we don't have them in HTML.

In the short term, the situation for non-WebKit browsers on mobile has become critical. If a decade ago browsers hadn't decided to implement the Microsoft-proprietary features in a way that was compatible with the legacy, we might all be stuck with IE6 today. If Safari hadn't added "like Gecko" to their UA string they might found it much harder to gain traction. History suggests that when browsers feel the need to take some action to improve competition, it is good for the long term health of the web. So it is here.

Mozilla have a 6 weekly update cycle.

Just yesterday I had similar comment(s) here on HN[1]. And blogging probably won't help. Just don't do it on your production sites and apps. If you don't have the capacity to support other than major two browsers then just don't. But blocking them is not a solution. And blocking features even though they work when you change user agent (hello google[2]) is complete nonsense.

1. https://news.ycombinator.com/item?id=3566329

2. search by image, search background, google plus notifications, ...