Vendor Prefix Melodrama
Today’s A List Apart is taking a look into this whole browser prefix debacle. The crux of the issue is that WebKit has a monopoly in mobile browsing, and as a result, standards based development is being pushed aside for WebKit only experiences. Now Mozilla is considering implementing the
-webkit prefix for certain properties, and changing their user-agent to appear to be WebKit. IE and Opera may choose to follow suit. Chris Coyier has a really nice overview over on CSS-Tricks.
Mozilla are Missing the Point
Developers aren’t developing WebKit only because they’re lazy. They’re doing it because they’re competing with native apps, and right now that means iOS and Android. If you want a web based experience that has a chance of competing with native, you target WebKit because it’s what people have on their phones, and you need the prefixed properties to create a comparable experience. It’s not a knock against standardization, it’s a practical reflection of reality. Developers can build a WebKit only solution and hit their entire target market, so why wouldn’t they?
Mozilla aren’t necessarily being excluded because their implementation is lacking, it’s because they’re completely non-present. If a company makes an iOS app, and an Android app, but ignores Windows Phone and Blackberry, is anyone surprised? So why should we expect anything different on the mobile web? At least with WebKit specific sites, it’s rare that the developers aren’t providing a reasonable fallback for non-WebKit browsers. Apparently, this isn’t good enough for Tantek Çelik:
They’re often broken. These downlevel mobile sites are different and significantly less functional. When users see a substantially worse experience in a different browser on the site on the same device, they blame the browser, not the site, nor the device.
Looking at those example, I find almost all of them completely acceptable (Google needs a few tweaks). Since when is it not okay to degrade the experience for obscure browsers? Have we forgotten how strongly we latched on to progressive enhancement when explaining to clients why things look different in IE6? So few people are using mobile Firefox it’s not even broken out of “Other” in Wikipedia’s browser usage chart. I would not be surprised if you had more visitors hitting your sites in IE6 than mobile Firefox.
This Isn’t Like IE
A common comparison for the current situation is to IE6, but the argument fails to understand WebKit. ActiveX, filters, XMLHttpRequest, etc. were completely proprietary, and their functionality and implementation were proprietary. WebKit is open source. Discussions involving new features are publicly available. The code can be downloaded and viewed at any time, by anyone. You can even download a nightly build to see what’s coming in the pipeline. The spec, the intent, the implementation, and the browser itself are all freely available to anyone on almost any platform. This is decidedly different that Microsoft’s implementation and objective with IE. If Mozilla were to choose to do so, they could freely switch from Gecko to WebKit and not need to fake support for the prefixes. They could submit changes to the code base, and they could be involved in the conversation to help steer the future of the renderer.
Further, I feel we’re doing IE6 a disservice if we don’t mention how many of its innovations ended up as standards: XMLHttpRequest, drag and drop (regrettably), contentEditable, and web fonts. Was IE6 terrible? For the most part. Did it do a great deal to accelerate the advancement of the web? Well, it would be difficult to ague otherwise. The true problem with IE6 was that the upgrade path to IE7 (and 8, and 9, and 10) was so painful, that many chose not to bother. The browser itself was really pretty great from a development standpoint.
It Won’t Work
Mozilla have sat on their hands for the last five years, and have been forgotten in the mobile space. Mobile Firefox is still a “test pilot” five years after the announcement of the iPhone, and four years after Android started releasing modern smart phones. It’s not available on iOS. On the desktop, Firefox’s marketshare has steadily eroded as faster, and more innovative browsers have pushed to the forefront. If Mozilla wants to fix this problem, the path to success isn’t complaining about standards, it’s creating a better browser. Firefox needs to be available, and it needs to kick ass. If Mozilla wants people to care about the
-moz prefix, they need to create mobile Firefox users. Developers didn’t shift en masse to standards based development until people started using Firefox. “We’re basically as good as the browser you’re already using, but we’re not on your platform yet” isn’t a great sales pitch. When I switched from IE6 to Firefox it wasn’t just because Firefox was better. It was because Firefox was insanely better. Google just released Chrome for Android, and it is insanely better than Browser. Mozilla has had five years, why haven’t they done the same?
I understand Mozilla’s motivations. They need people to see mobile Firefox as a viable alternative, and if people aren’t using the
-moz prefix, sites will look worse in Firefox. The solution is education and evangelism, not obfuscation. Their actions here are just going to make web based development more painful. If they implement
-webkit and it varies even slightly from the WebKit implementation, we’re back to browser sniffing to react. Mozilla is talking about standards while actively working to ruin vendor prefixes, an important part of the standardization process. They’re solving a problem they have (irrelevance) by creating one for me (fracturing). That isn’t a path to success.
Developers are going to flock to any environment that saves them time and pain. If anything, actions like this are going to push developers away from the web and towards native solutions.
It’s Okay to Break the Web
If prefixes change, and sites break, so be it. Let them break. It’s a developer’s choice whether or not they use prefixes, and it’s their responsibility to repair broken sites if browsers change the implementation. These “broken web” arguments are an appeal to antiquity. We need to allow the web to move fast and break things. It’s still in its infancy — especially the mobile web — and we’re still figuring out how it needs to work. I’ve built over 40 sites, and few of them still exist in their original form. The web moves fast. Three year old sites are ancient. If a browser drops prefix support in favor of a standardized implementation, most sites will be fine, and the few that do break will just be casualties of progress. It’s not a real problem if a site loses progressive enhancements. That’s kind of the point.
Standardization moves at a glacial pace, and mobile browsers are pacing themselves to create capable alternatives to native apps. The features may well be “experimental”, but they work, and typically, they work pretty well. I have no interest in being standards compliant if standards bodies aren’t capable of keeping pace with browser development. My concern is for my users, and creating the best possible experience. They do not care how I accomplish the things that I do, only that they work.
WebKit is open-source. It has its own committees, and its own development processes, and it’s moving fast. The standards community feels that we should continue to develop to the lowest common denominator until these new properties can be standardized, for the good of the web. For the good of the web, I’d counter that if the W3 wants to remain relevant, they need to keep up. No one is willing to wait months, let alone years, to start developing at the very edge of what’s possible.