As the over-heated CSS vendor prefix debate rages, I can’t help but note the mounting pile of logical fallacies and downright poor reasoning being deployed. Some context is in order.
Your Moment Of Zen
The backdrop to this debate is that CSS is absolutely the worst, least productive part of the web platform. Apps teams at Google are fond of citing the meme that “CSS is good for documents, but not for apps”. I push back on this, noting the myriad ways in which CSS is abysmal for documents. That isn’t to minimize the pain it causes when building apps, it’s just that the common wisdom is that CSS surely must be fantastic for somebody else. Once we find that person, I’ll be sure to let you know. In the mean time we should contemplate how very, very far behind the web platform is in making it delightful to build the sorts of things that are work-a-day in native environments.
But it’s worse than simply being under-powered: CSS has the weakest escape hatches to imperative code and demands the most world-view contortion to understand its various layout modes and their interactions. Imagining a more congruent system isn’t hard — there are many in the literature, might I humbly suggest that now might be a good time to read Badros & Borning? — and even CSS could be repaired were we able to iterate quickly enough. Things have been moving faster lately, but fast enough to catch up with the yawning gap in platform capabilities? We’ll come back to the speed/scale of change later.
For now, consider that the debate (as captured by Nate Vaughn) is about the retrospective implications of the few things that have already gotten better for some set of developers in some situations. That this sort of meaningful progress (corners, gradients, animations, transitions, flexing boxes, etc.) is rare makes the debate all the more bone-chilling to me. We finally got a few of the long list of things we’ve been needing for a decade or more, and now because the future is unevenly distributed, we’re about to blow up the process that enabled even that modicum of progress? How is it we’re extrapolating causality about engine usage from this unevenness, anyhow? None of this is obvious to me. The credible possibility of losing prefixes as a way to launch-and-iterate is mind-exploding when you realize that the salient competition isn’t other browsers, it’s other platforms. Either the proponents of squatting other vendor’s prefixes haven’t thought this through very hard or they’re bad strategists on behalf of the web as a platform…not to mention their own products. The analysis that we’re being asked to accept rests on an entire series of poor arguments. Lets start with the…
In an interview out yesterday with Eric Meyer, Tantek Çelik of Mozilla tried to present this debate as a question of barriers to the adoption of non-WebKit based browsers, specifically Firefox Mobile. Opera has made a similar case. What they ommit is that the only platforms where they can credibly ship such browsers are Android and S60 (a dead end). That’s a large (and growing) chunk of the world’s handsets — good news for me, as I now work on Chrome for Android here in London — but for whatever reason it appears that iOS users surf a whole lot more.
Let that sink in: on the devices that are the source of most mobile web traffic today, it’s not even possible to install a browser based on a different engine, at least not without a proxy architecture like the one used in the excellent Opera Mini or Amazon’s Silk. iOS and Windows Phone are both locked-down platforms that come with only one choice of engine (if not browser shell). When folks from the vendors who want to appropriate others’ prefixes talk about “not being able to compete”, remember that competition isn’t even an option for the most active users of mobile browsers. And it’s prefixes that are keeping us down? We must go deeper.
The tension comes into focus when we talk in terms of conversion, retention, and attrition. Conversions are users who, if able, switch to a new product from an old one. Retention is a measure of how many of those users continue to use the product after some period of time. Today (and since Windows first included a browser), the single largest factor in the conversion of users to new browsers is distribution with an OS. This is the entire rationale behind the EU’s browser choice UI, mandated on first start of new Windows installs. Attrition is the rate at which users stop choosing to use your product day after day, and for most desktop installed software, attrition is shockingly high after 3 to 6 months. The attrition rate is usually measured by cohorts over time; users who installed on the same day/week/month to measure what % of that group continue to use the product over increasingly long periods of time. The rate of decay falls, but the overall attrition invariably continues to rise. You might not get un-installed, but that doesn’t mean you’ll still be the go-to icon on the user’s home screen or desktop. Eventually every device is recycled, wiped, or left for history in a drafty warehouse and along with it, your software. A key factor in getting attrition under control for Chrome has been evangelism to improve site compatibility, e.g. “I’m not using your browser because my bank website doesn’t work with it”. That argument — that site compatibility is key to ensuring a competitive landscape for what otherwise are substitutes — puts the entire thing in some perspective. Attrition isn’t the same thing as conversion, and conversion is driven primarily by integrations and advertising. Implicit in the arguments by Tantek and others is a sub-argument of the form:
Our product would have measurably more users if sites were more compatible.
Thanks to what we know about what drives conversions, in the short run this is simply false. Long term, what invariably gives you more users is starting with more users. The set of things that are most effective at convincing users to swap browsers, even for a day, include: advertising, word-of-mouth, a superior product, distribution/bundling, and developer advocacy. Depressingly, only one of those involves actually being a better product, and the prerequisite for all of them is the ability to switch (thanks, Android team!). There’s a similar dynamic at work when doing advocacy to web developers: if you’re nowhere in their browser stats, they’re adding support for a standard or worse a second prefix in order to do service to a cause, not because it’s measurably good for them. Clearly, that’s going to be somewhat less effective. Where, then, is the multi-million dollar advertising campaign for Fennec? The carrier and OEM rev-share deals for bundling on new Android phones? Hmm. To hear Tantek et. al. tell it, non-WebKit-based browsers would be prevalent on mobile if only it weren’t for those damned browser prefixes causing users of other browsers to receive different experiences! Also, those kids and that damned dog.
Over the long haul compatibility can have a dramatic effect on the rate of attrition by changing the slope of the curve — which, remember, is a rate with decay and not a single % — but it begs the next uncomfortable question: what do we mean by “compatibility” here? What sorts of incompatibility cause attrition? Is it content that looks slightly worse but still essentially works (think grey PNG backgrounds on IE6) or does it simply turn you away, not allow you to play in any way, and generally fails (think the ActiveX dependencies of yore)?
Inaccessible or Ugly?
Eric was good enough to call out what I view as a key point in this debate: what sort of “broken” are we talking about? Tantek responded with a link to side-by-side screenshots of various properties rendered on Chrome for Android’s Beta and current Fennec. In some of these cases we may be looking at Fennec bugs. WordPress.com serves the same content to Fennec which seems to bork what
float: left; means. That, or some media query is preventing the main blocks from being floated; it’s hard to tell which from a quick
view-source:. For the versions of google.* included in the list, the front end is simply serving the desktop version to Fennec which makes the wonky button rendering even stranger. Is there room to improve what gets sent to Fennec? You bet, but that’s not what’s being argued in the main. Ask yourself this: is what you see on that page worth destroying the prefix system for? ‘Cause that’s what the advocates of prefix-squatting would have you believe. In effect, they’re suggesting that nothing will cause developers to test on non-pervasive engines, a deeply fascinating assertion. Even if we accept it, it doesn’t point clearly to a single tactic to resolve the tension. It certainly doesn’t argue most strongly for prefix-squatting.
An important point Eric failed to follow up on was Tantek’s assertion that Mozilla will be cloaking user-agent strings. Does he imagine that the only thing that might be cause someone to send different content is CSS support? API support for things like touch events differs, the performance characteristics of device classes and browsers vary wildly, and application developers are keen to deliver known-good, focused experiences. The endless saga of
position: fixed; as plumbed by Google teams and others is a story of competing constraints: browser vendors optimize for content, content fights back. Repeat. What does Mozilla imagine is going to happen here? Maintained content will react to the browser usage of end-users (and as we’ve covered, compat != conversions). Unmaintained content, well, that’s what fallback is all about. And bad things deserve to lose. Assuming that your browser is 100% compatible with developer expectations and testing if you only switch the UA and implement a few prefixes is NPAPI-level crazy all over again, and it’s entirely avoidable. Tantek and Brendan, of all people, should be able to reason that far. I guess they’ll find out soon enough — although we will have all been made poorer for it.
Now, what about the related argument that Mozilla & Co. are only going to be doing this for properties which are “stable” (nevermind their actual standardization status)? The argument says that because something hasn’t changed in another vendor’s prefixed version in a while, it must be safe to squat on. Not only is this (again) incredibly short-sighted, it says that instead of forcing a standard over the line and clobbering both developers and other vendors with the dreaded label of “proprietary” (the usual and effective tactic in this situation), they’re instead willing to claim ownership and therefore blame for the spread of this soon-to-be-proprietary stuff, all the while punting on having an independent opinion about how the features should be structured and giving up on the standards process…and all for what?
Product vs. Platform
Perhaps there wasn’t space in Tantek’s interview with Eric, but both of them chose not to be introspective about the causes of WebKits use in so many mobile browsers, with Tantek merely flagging the use of a single engine by multiple products as “a warning sign.” But a warning of what, exactly? Eric didn’t challenge him on this point, but I sorely wish he had. Why did Safari, the Android Browser, Chrome, Silk, Black Berry, and many others all pick WebKit as the basis for their mobile browsers?
WebKit isn’t a browser. It’s just not. To make a browser based on WebKit, one might bring along at least the following bits of infrastructure which WebKit treats as bits to be plugged in:
- Caches of some sort
- Graphics rendering
- A build system
- POSIX or other platform plumbing
What we’re witnessing isn’t open vs. closed, it’s differences in initial cost of adoption. In JS terms, it’s jQuery (focused core, plugins for everything else) vs. Sencha or Dojo (kitchen sink). Entirely different target users, and both will find their place. Nobody should be shocked to see smaller, more focused bits of code with good plugin characteristics spreading as the basis for new projects. The Mozilla Foundation wants to help prevent monoculture? In addition to making the Firefox product a success, there are concrete engineering things they can do to make Gecko more attractive to the next embedder, Firefox-branded or not. I haven’t heard of progress or prioritization along those lines, but I’m out of the loop. Perhaps such an effort is underway, if so, I applaud it. Whatever the future for Gecko, Product success isn’t related to platform success as a first approximation. Having a good, portable, pluggable core increases the odds of success in evolutionary terms, but it’s absolutely not determinant; see MSIE.
Speaking of IE…I respect those guys a lot, but the logical leap they’re asking us to swallow is that the reason people return Windows Mobile phones is that some CSS doesn’t work. That’s what attrition means on a platform where they’re the only native runtime. Data would change my mind, but it’s a hell of a lot to accept without proof.
The Time Component
Lets take a step back and consider Tantek’s claim that Mozilla has gotten very little traction in evangelizing multi-prefix or prefix-free development for the past year: Firefox for Android has been available since Oct. 2010 and stable for just 6 months. Opera Mobile on Android has been stable for just over a year. IE 9 (the only IE for mobile you could ever seriously consider not serving fallback experiences to) only appeared with Windows Phone 7.5 (aka “Mango”), shipped to users an entire 6 months ago.
And we expect webdevs to have updated all their (maintained) content? Never mind the tenuous correlation between the sorts of soft incompatibilities we’re seeing at the hands of CSS and user attrition; the argument that even this lesser form of harm hasn’t been blunted by evangelism appears suspect. Taking the incompatibilities seriously, I can quickly think of several other measures which are preferable to destroying the positive incentives towards standardization the prefix system creates (from least to most drastic):
- Continued evangelism to web developers with particular focus on major sites
- Political pressure on browser vendors to start dropping prefixes (i.e., we’d all be equally disadvantaged until users pick up the standard version)
- UA spoofing without prefix squatting
- Blacklists to trigger alternative identity (UA/prefixes) on a subset of sites
All of these are less blow-up-the-world than what MSFT, Mozilla, and Opera are proposing. It’s not even an exhaustive list. I’m sure you can think of more. Why these have either been not considered or dismissed remains a mystery.
It’s More Complicated Than That
In all of this, we’re faced with an existential question: what right do web developers have to shoot themselves in the foot? Is there a limit to that right? What sort of damage do we allow when some aspect of the system fails or falls out of kilter for some period of time? It’s a question with interesting parallels in other walks of life (for a flavor, substitute “web developers” with “banks”).
Can we show active harm to other browsers from the use of prefixes? The data is at best unclear. Arguing that any harm rises to a level that would justifies destroying the prefixes system entirely is rash. I argued many of the reasons for this in my last post, but lets assume in our mental model that developers respond to incentives in some measure. If, concurrently with achieving as-yet un-managed distribution, Mozilla et. al. implement others’ prefixes, what should we expect developers to do in response? After all, they will have reduced whatever tension might have been created by content that “looked wonky” and, where standards exist, will have reduced the incentive to switch to the standard version.
Now lets play the model one more turn of the wheel forward too: assume that Chrome or Safari (or both!) act in good faith and contemplate removing the
-webkit-* prefix support for standardized features at a quick clip…and Mozilla doesn’t. You see how this quickly leads to a Mexican standoff: web developers won’t stop using prefixed versions because those are the way you get 100% support (thanks to Mozilla’s support for them); vendors won’t un-prefix things because others who squat their prefixes will then have a compatibility advantage; and nobody will be keen to add new things behind prefixes because they can no longer be assumed to be experiments that can change. Lose, lose, lose.
Some on the other side of the debate are keen to cite game theory as a support for their course of action, but the only conclusion I can draw is that their analysis must be predicated on a set of user and developer motivations that are entirely unlike the observable world we inhabit.
A Call To Reason, Not Arms
Based on a better understanding of the landscape, what should the various parties do to make the world better for themselves now and in the long run and for the web as a platform?
- Web Devs: first, do no harm; test in multiple runtimes, pointedly including a “fallback”. Then enhance with prefixes. Do not apologize for giving some (or even many) of your users a better experience. That, after all, is your job. But know this: prefixed properties are not supported, will go away, and when something you didn’t test the fallback for falls over, it’s your fault.
- Browser Vendors: invest in advocacy and distribution enhancing moves for your product before threatening to blow up effective standards policies. If you’re going to implement a prefixed version, please have a different opinion or push to ram a standard through to Recommendation ASAP. Incompatible right-hand-sides help developers understand that things are still evolving. DO NOT squat on prefixes. It’s both relative ineffective and will make developer’s lives harder when they want to legitimately move to standard or support your prefixes.
- Vendor CSS WG Reps: get it through your heads, you’re behind. It’s not quaint and it’s not excusable. The platform needs more powerful CSS features, and stat. It’s long past time to start stealing good ideas from the pre-processors. Appeals to a lack of manpower to implement must never block others and shouldn’t block standardization, so please stop making them. If you care about the platform’s success, let those who are able and willing to take risks do so.
- The CSS WG (as a whole): get the lead out. It’s not exclusively the W3C’s fault that things are slow, but the current MTTR (Mean Time To Recommendation) is still glacial. It is unreasonable to expect vendors to drop prefix support immediately upon standardization, but the W3C has a role here to advocate for quick sunsetting. Daniel Glazman is, as ever, right on most of this, but more can be done to streamline the process post CR.
- The WebKit Project: Add build flags to allow WebKit-based products to enable/disable vendor prefix support independently.
- Chrome/Safari/Other-prefix-supporting-browsers: Sunset prefixes as soon as is practicable post-standardization. Similarly, don’t ship prefixed features you’re not willing to be on the hook for via your reps to the CSS WG. Disabling them may be painful, but it’s the only good-faith thing to do.
I’ve left a lot out of this post, but it’s too long already. I do truly hope it’s the last I write on prefixes because, as I said up front, we have much bigger fish to fry. Stat. Prefixes do work, they’re essential to delivering a future platform that can compete, and yes, they should be torn down at the same pace they’re erected.
A few things that folks have asked about as tangents to this debate:
- It’s never a good thing for there to be homogeneity in the experimentation phase. The explicit goal of the prefixes system is to enable diversity of early opinion and fast coalescing around the best answer, thereby enabling the writing of a standard which is likely to need less revising and iteration. Diversity provides some value, the market tests the alternatives, and we deliver the most value we can over time through the standard version. It has always been thus, but prefixes make it less risky…assuming we don’t start stepping on everyone else’s toes.
- If the reasoning behind prefixes is to set up and tear down large-scale experiments, iterate, and collect feedback then Lea’s -prefix-free approach and PPK’s
-beta-*proposals are equally counter-productive and should be avoided at all costs. Making prefixes less painful to use reduces the natural incentives for migrating to a standard while blindly assuming the same right-hand for a future standard version as we have for some prefixed versions is plainly idiotic. What were they thinking?
@-vendor-unlockis only slightly smarter, but in every possible way inferior to CSS Mixins. Would that the WG spent as much time on Mixins as they have on this prefix kerfuffle.
- Yes, I was in Paris when the CSS WG F2F was happening. No, I wasn’t at the meetings. Duty (Chrome for Android) called.
- If you’ve read this far, congrats. You may be the only one. I’ve been assured by CSS WG delegates that nobody cares what I think, which statistically seems to just be rounding down by a tiny bit. Fair enough.
Update: Michael Mullany of Sencha adds epicly good, epicly long context about what causes developers to target UAs and what the incentives that’ll change their minds about supporting a given browser really are.
Thanks to Frances Berriman, Jake Archibald, Tony Gentilcore, and Tab Atkins for reviewing earlier versions of this post. Errors of fact and form are all mine, however. Updated occasionally for clarity and to remove typos.