Misdirection

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…

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:

Networking

Caches of some sort

Graphics rendering

A build system

POSIX or other platform plumbing

And that’s a minimum. Competitive ports tend to include WebSQL, LocalStorage, and Indexed DB back-ends, video codecs, 3D infrastructure (deeply non-trivial), perhaps an alternative JavaScript engine (V8 or other), and alternative/additional image decoders (e.g., WebP). All of that is in addition to needing to create your own UI for bookmarking, navigation, etc. WebKit is an engine, not a fully-functioning vehicle. Therein may lay some of the difference in the relative success of the WebKit and Gecko on mobile to date. Want to build a Gecko-based browser? Great, first clone the entire Firefox codebase from Mercurial, then layer your stuff on top/around. Oh, wait, things might not cleanly be factored to allow you to plug in your own X, Y, or Z? Your builds take forever? Welcome to life in the Mozilla universe where your product is always second fiddle to Firefox. Now, that’s not by way of criticism, mind you. It is entirely reasonable for a product like Firefox not to pay coordination costs with other vendors/users of their code. God knows the overhead over here in WebKit land of trying to keep the menagerie of ports building against all changes is downright daunting. Mozilla (the organization) has made choices that prioritized the success of their product (Firefox) over their codebase (Gecko). WebKit was structured as platform only (no product), both forcing enormous costs onto every port while also freeing them from swimming upstream against a single product’s imperatives in the codebase.

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.

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.

Endnotes

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 -alpha-*/-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-unlock is 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.

“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.”

I think you’re spot-on. My only wish (as a webdev) is that “fast coalescing” would go faster :)

If webdevs are hurting other browsers by relying on non-standardized CSS. I think they are to blame, not the browser vendors who just want to quickly enhance and standardize a new feature.

Prefixed CSS features are like the tag for HTML. Both should not be used in ways which, if not supported, would make your website un-viewable. At least the new CSS features have the decency to explicitly tell me they are not standardized, by being prefixed. If they weren’t, wouldn’t it just make it harder for a webdev to create high-usability websites?

Of course, just like blink, if it is not getting standardized, it should be removed.

PS: “If you’ve read this far, congrats. You may be the only one.” Thanks! ^^

As you guessed, there were space restrictions—too long a piece would have lost readers—but also time restrictions, as we had only a couple of days to conduct the interview and then I had a day to edit it before passing it over to production.

Of course, even given two weeks and twice the length, I couldn’t have done all sides of the situation justice. You covered more ground than I could, and even at that left a lot out of a quite lengthy post!

(Also: *cough*misspelledmyname*cough*.)

My primary goal was to get the discussion started, clear up some misconceptions (some of which I held at the interview’s outset), and allow Tantek room to make at least the basic case while injecting some of the most obvious objections. From there, it was and is up to the community to expand things further.

Personally, I love how far you’ve gone with it here! Though I disagree with a few of your points, the conclusions are all very well argued and that’s what we need now: articulate discussion. Thanks for putting your shoulder to the blogging wheel on this.

I loved every word that I just read. I agree that Mozilla even considering adopting (squatting) the -webkit- prefix is both crazy and indicative of a greater problem. The fact that experimental and non-standards features get shipped with webkit is the real problem. As a front-end dev, I love playing with all the very futuristic features that are included with the -webkit- prefix, but it’s scary to me that they can be used in a production environment.

Also, I think that members of my industry are to blame just as much as everyone else. It’s not hard to add the corresponding -ms- and -moz- prefixes to our CSS, but we choose not to based solely on efficiency (read: laziness). We have to be more forward thinking than that. Who would’ve imagined two years ago that the single biggest browser in the world would be Chrome and the most prevalent mobile OS would be Android? If we are unwilling to take the extra steps needed to make our sites both present and future-proof, we are the problem when we could be the solution.

Thank you so much four writing this down. It’s being tweeted, Facebooked, and G+’d as we speak.

Maybe Google Teams could start a big campaign toward Web developers on how to code the right way. It seems from your post that you care about an healthy diverse Web environment. Promoting that ecosystem would do a lot of good.

I’m also curious to see when Chrome, Safari and Co. will not shiped the unprefixed properties.

My major difference of opinions with your post is that I think that vendor prefixes should be available only in beta builds and not in final release builds.

It’s not an assumption, it’s a thing I’m explicitly advocating for and believe I can make happen for Chrome. Not all of WebKit need move for us to use build flags to independently change the behavior of *our* port.

Your post seems to suggest that the problem is prefixed properties proceeding too slowly to standardisation. In fact, the most problematic property, -webkit-text-size-adjust, has been implemented by Apple in Webkit but never specced or submitted for standardisation.

Apple’s participation, or lack thereof, in the open web, is the real problem here. The prefix debate, and other browser vendors response, is simply a symptom of the underlying disease. Apple are the most wealthy company in the world, but they don’t pay a single employee working full-time on web standardisation. Their participation in the mailing lists, speccing efforts, etc is small and decreasing. They add proprietary features that help them lock down market share on mobile.

What’s needed is a radical change to the Webkit project itself, one that ties specific open web commitments into the project’s governance and its licensing. The Webkit code license should explicitly preclude the addition of any proprietary features and require that any features which are added are fully specified and submitted to the appropriate standards bodies.

Google are the only contributor to Webkit who have a chance of pushing this through. If necessary, you should fork it to a new project, bringing all the other non-Apple contributors with you. Otherwise, you are letting Apple free-ride on your contributions, which they can upstream to their iOS fork alongside their proprietary extensions.

I think this is a special form of the “Chrome should sunset prefix versions of standardized properties” point I’ve argued, and I can only say it makes sense to me along the same lines. That said, it’s unclear what other WebKit ports should do/evangelize. There’s pretty clearly diminishing returns, highly correlated to distribution (as always).

I think you’re clearly correct that CSS development is moving far slower than it should, and slower than other parts of the web platform. I also think that prefixes have done nothing to help here.

Consider the part of the web platform that has made huge progress in the last five or so years: HTML. Every single high-profile feature addition in HTML (like canvas, video, audio) was unprefixed from the start. If browsers ever prefixed any of the JS APIs, it was without any request by the spec or its editor, and only until they felt they were stable enough to unprefix — not until some arbitrary spec stability milestone. Canvas was actually a WebKit proprietary feature that was always unprefixed in WebKit, but was reverse-engineered and standardized in something close to its original unprefixed form. This by itself proves that prefixes are not necessary to iterate a successful feature. You can just stick with the original implementation, flaws and all, making only slight changes so that compat is basically preserved.

The difference is in the editorial process. HTML development has been overseen solely by Hixie since 2004 or so (although the W3C only admitted it in 2007). If there’s any dispute, he resolves it by fiat. Once something is implemented, he makes sure the spec stays stable so that implementers don’t have to change, unless the flaws turn out to be so bad that implementers are willing to change.

CSS development is balkanized and bureaucratic by contrast. Development is in the form of dozens of tiny specs edited by different people, many of whom have little time to spend on standards and are unable to keep up with feedback. They don’t coordinate as much as they should, so we wind up with effort being wasted on multiple solutions to the same problem. Disputes sometimes occur in lengthy mailing-list discussions with no clear resolution.

CSS issues can be left open for many months with no resolution — not because no one’s looked at the issue, but because no one is willing or able to make a final decision. For instance, has been open since October 2011 with no resolution (it’s marked a duplicate of a still-open bug). This despite the fact that browsers that implement transforms all do the same thing.

The recurring debate about prefixes, with similar arguments being presented every few months for years, is another example of the same problem. Resources are being wasted on permanent discussions like this that are constantly being reopened, because there’s no finality. There’s too much effort spent on trying to reach consensus on individual minor issues and not nearly enough effort spent on just making a decision and stabilizing things.

Prefixes are bad because they fuel this propensity toward indecision. Yes, maybe the initial draft will be flawed. Too bad. The web platform is flawed. Take your best shot at the initial draft, respond rapidly to early feedback while you can still iterate, and set it in stone once there’s widespread implementation. The first priority needs to be to get the functionality out there, stable and interoperable.

Authors can work around flaws — heaven knows they’re used to it. If all browsers implement the same flaws, they can deal with it. What’s a much greater pain to deal with is if the design keeps iterating and they don’t get interoperable support for any version of the feature at all for an extra couple of years.

What the CSSWG needs is one person, or a few like-minded people who cooperate closely, who can invest the time necessary to take over CSS development by themselves. HTML and DOM specification is in a drastically better place than CSS because it’s largely run by Hixie together with a small handful of people who are on the same page as he is. Things get done with no bickering, and more pragmatism than perfectionism. Unfortunately, there’s no one who has the time and ability to take over CSS right now. And if there were, it would be politically tricky, because all the implementers are heavily involved in the CSSWG (unlike the late and unlamented XHTMLWG). But that’s what needs to happen. Prefixes are a distraction.

(I say all this as someone who was paid by Google to work on HTML/DOM-related specifications and tests for 2011, and am now working on CSS specifications and tests for Mozilla. The difference is striking.)

> I think this is a special form of the “Chrome should sunset
> prefix versions of standardized properties” point I’ve
> argued, and I can only say it makes sense to me along the same
> lines. That said, it’s unclear what other WebKit ports should
> do/evangelize. There’s pretty clearly diminishing returns,
> highly correlated to distribution (as always).

I’m talking about doing it for all prefixed properties, standardized or otherwise, and not sunset – sudden.
s/-webkit-/-goog-/g

Your chance to do this is short-lived. Doing it in a years time will take sites that worked for a user and break them. I can see you not wanting to do that.

My assumption is that Chrome for Android currently has a number of users which is basically a rounding error, but in 2 years time it will have a massive % of users. Other webkit ports don’t have the same low initial cost to prefix-change and high future leverage. Both are key to this thought experiment.

If doing this was going to save vendor prefixes from otherwise certain demise, would you do it?

I think you’re missing a key point about how CSS and HTML differ: you can’t (practically) prefix HTML elements in the same way you can CSS. To prefix thing, you’d be adding nesting which might influence styling and will certainly cause incompatibilities down the road. CSS is different in that you have “last wins” combined with graceful failure, where HTML will retain the effects of vestigial but un-recognized elements.

Perhaps this has some of the follow-on effects you cite, but it’s clearly no apples/apples.

What astonishes me most about this debate is how little the fact gets mentioned that Apple is using the prefix mechanism essentially as an escape hatch from the WG. Prefixes exist to make room for experimentation in proposed future standard properties, not to allow vendor-specific proprietary features. But that is exactly what Apple is using them for – an escape hatch from the W3 process for features they at least evidently they never intend to standardize.

In that position, it is hard to see how Mozilla can avoid implementing these properties with their -webkit- prefix. Of course that’s crazy, because it breaks the purpose of the prefix system in exactly the way you described. Mozilla is damned if they do and damned if they don’t.

The real problem is Apple obstructionism, and apparently it is also the elephant in the room.

As for Lea’s and PPK’s approaches to prefixes, those are the same damned-if-they-do-and-damned-if-they-don’t kind of reaction to the problem from the webdev perspective: dealing with lots of prefixes is a huge pain for webdevs. But the reason they have to is because the -webkit- prefix has become something other than what the prefixes in CSS were supposed to be.

And Apple is the culprit.

Apple are now what Microsoft used to be – even if maybe with less calculated intent. Is that enough to divert everybody from jumping on their case to get in line? Why are people going for these absolutely crazy coping approaches that fail to recognize the core problem – why attack the prefix system instead of indicting its (ab)use as a ruse for vendor fragmentation of the web platform?

alex, you can do it just fine if you use attributes instead of elements. E.g., you could have or such. The way to be compatible across all UAs would then be

(hope that doesn’t get eaten). Sure, it’s ugly, but workable. It’s been suggested. I think the HTML spec at one point had language encouraging implementers to introduce attributes, not elements, as extension points if they wanted to extend anything.

Besides, it illustrates the point that no prefixing mechanism is necessary at all. Whether or not prefixing was possible, it didn’t happen, and it was still a success. Thus prefixes are not necessary for successful experimentation by vendors.

Since both sides of this debate make claims to “what developers think/act”, we thought we’d lay out the Sencha opinion on -webkit prefixed effects: why we use them, and why we don’t want other vendors squatting on them. And incidentally, we’re fans of CSS as a technology.

But first a little background.

Here at Sencha, our frameworks haven’t focused on progressive enhancement: in our opinion, it’s not very appropriate for apps. A grid that degrades to a poorly laid out table is not generally useful, not for developers, not for users. Our community’s users expect their web apps to look and behave exactly the same, whether they’re in IE6 or Chrome 17. This has not been easy to achieve. It’s not just a matter of adjusting to the well known problems such as IE6’s broken box model, but also working around a multitude of other browser quirks (such as the extensive bugs in IE’s VML implementation for our web charting.) Suffice to say, as a cross-platform framework company, we put a lot of time behind abstracting browser inconsistencies.

When it came to developing Sencha Touch in late 2009, we took a slightly different tack. Our primary goal was to create a web framework that could provide a native-quality application experience.

Quite quickly, we figured two things out. First, most smartphone hardware on the market simply didn’t have the power to run high quality experiences in their browser. Second, many mobile browsers (Blackberry OS 5, Windows Mobile 6 CE etc.) lacked the JavaScript engine or the CSS support that we needed to create compelling user experiences. With these two constraints, we decided that our initial version of Sencha Touch 1 would target just the built-in browsers for both Android and iOS. Luckily, at the time, those two browsers were responsible for the vast majority (90%+) of all mobile web traffic in the U.S. (as measured by ad requests http://www.slideshare.net/admobmobile/ad-mob-mobilemetricsapr10). Our interpretation was that other platforms were delivering such a bad experience that few people were using them for regular web browsing.

The biggest benefit of targeting just these two browsers was that we could take full advantage of the huge set of `-webkit` visual effects – which were then mostly available *only* on webkit based browsers. Gradients, transforms, transitions, border-radius, and CSS masks were indispensable in creating the richest experience possible. Even though they were technically experimental, most of them had standards track documents that meant that we could rely on some form of the capability being a standard at some stage for other browsers, if and when they arrived on volume mobile platforms.

Using WebKit effects reduced the size of our download package (far fewer images), allowed for easily themed applications, and drastically increased the performance and smoothness of our animations. In particular, CSS 3D transforms were hardware accelerated on iOS, which delivered noticeably better frames per second when compared to JavaScript-based animations. Without WebKit effects, we simply wouldn’t have been able to deliver the quality of product that we needed.

Subsequent to our release of Touch 1.0, there have been a bunch of new mobile browsers from RIM, Mozilla, Opera and Microsoft. We’ve added support for RIM and announced our intention to add support for Windows Phone. As a leading implementor of “WebKit” only mobile frameworks, we’re often asked when we’ll add support for these browsers. Here’s how we think about this.

For us, “supporting a browser” is not just a matter of adding multiple vendor prefixes or doing feature detection. Every single browser we support – even the supposedly generic WebKit ones — have had *major* differences in the correctness and performance of features, which makes the “use feature detection” approach advocated by many fairly useless. We have browser specific code for Android 2.2, 2.3, and 4. We have code just for the Kindle Fire and code just for the Blackberry Torch. Our list scroller implementation for Android Gingerbread is based on scroll position animation and our list scroller for Android 4 is based on CSS transforms. This attention to detail, and our browser-specific code, is needed to create the most compelling experience possible. It’s why people use frameworks rather than try to code to the naked browser.

In addition, we’re a developer’s developer, so we care about supporting the browsers that our developers care about developing to. Today, that means Android, iOS and Blackberry. Soon it will be Windows phone. This means that a lot of `-ms` is going to start showing up in our CSS files, and it also means that we’ll be replacing webkit-specific effects that do not look like they are headed to standards track. The two major effects that are only are truly useful but have no standards track document yet are `background-clip: text` and CSS masks. (There is an aspiration to move these effects in to a general FX spec at some point in the future, but we would have *much* preferred that Apple or Google submit standards track documents for these much, much sooner.) These are now supported in both Firefox after a fashion as well as Webkit. These effects are useful for theming icons and other small graphics that can be delivered as custom fonts. For Windows Phones, we’re looking at the prospect of using image based theming, fonts or SVG masks. But we hope IE implements CSS masks soon too.

On the other hand, we see only minor demand from our developers that Sencha Touch work on Firefox Mobile or Opera Mobile because each of these has much lower levels of usage on smartphones. But this isn’t the only reason that we don’t support them, it’s because in our opinion, the quality of the implementation of the effects that we need to use is often much poorer in these browsers (although we’d also cast stones – big ones – at the Android 3 browser). If Mozilla decides it’s going to expropriate `-webkit` prefixes and masquerade as an iOS browser, we can see a requirement for us to figure out a different way to detect that it’s Firefox and disable those effects.

At a higher level, we agree that it’s very odd behavior for Mozilla to cry wolf about a webkit-only monoculture when their implementations of the effects that we and other developers are most excited by have been dilatory and underwhelming. And, we’re not worried about a WebKit-only monoculture, it’s clear that IE10 has a pretty good shot at overturning WebKit as the best browser on Windows. At the very worst we’re looking at a duo-culture.

So afterall that context, here’s what we’d like to see.

First, no prefix squatting. It’s a terrible idea and will make developers go through contortions to route around it. Daniel Glazou’s proposal that it’s ok to squat only in the smallest possible way, may not be a terrible stop gap, but we’d still prefer “no squatting period”

Second, a much stronger effort from the browser makers to move experimental effects into standards track. At most, there should be a 6 month delay between first ship and an Editor’s draft at the very least. Even now there are a ton of effects that remain outside standards track. Just two more examples, Webkit text decoration effects should be integrated into CSS Text. And CSS Masks – which arrived in Webkit in April 2008!! – should have long since been put into a track document.

Third, more aggressive pruning of non-viable standards track features or even whole standards track documents. For the longest time, the CSS Text spec was a peculiar species of speculative fiction. I can point to other living dead spec documents. It’s not very helpful when we have to read transcripts of meetings and long discussion threads just to figure out what we can count on and what we can’t. And waiting for something to hit Candidate Recommendation status is not realistic.

Fourth, more aggressive pruning of experimental features that have been rejected as ‘a bad idea’ by the CSS Working Group. There needs to be a “negative standards doc” listing things that “ain’t going to happen”. It’s been very clarifying for us for WebSQL to be declared a dead end (although we personally liked its functionality quite a bit.) Once a feature hits the negative standards track, browser makers should have 6 months to remove it from their edge versions.

In any case, this is the take on the prefix kerfuffle from the perspective of a mobile framework developer. Enjoy.

“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!”

Of course Tantek claims no such thing.

“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.”

Of course Microsoft says no such thing.

“Appeals to a lack of manpower to implement must never block others and shouldn’t block standardization, so please stop making them.”

No-one is making them, as far as I know. (Although Apple is making a lack-of-manpower argument for why they haven’t standardized their new -webkit features.)

Please try to abstain from straw-man attacks.

Your point that Webkit-prefix-dependent mobile sites are not the biggest problem faced by non-Webkit mobile browsers is both immediately obvious and not relevant.

Your plea to give evangelism a chance ignores Opera’s efforts in this area, which have been going on for years, supported by a significant staff.

You may be unaware that Apple’s Webkit people have declared that they will never drop support for -webkix-prefixes. I applaud your efforts to make that happen in Chrome; that would be excellent.

You know I respect you greatly, but I’m simply laying out the implied arguments in the (disconnected) appeals that the various parties are making. If the claim of the squatters isn’t that webkit prefixes are making it difficult to prevent attrition, what is it? I haven’t hear that clearly enunciated. Or is the goal of preventing attrition — from the perspective of a product — something other than keeping users to the exclusion of other browsers which they might pick? What bit did I get wrong?

As for manpower, certain CSS WG representatives make these appeals on a regular basis.

And on the point of evangelism, I’m not claiming that web developers will do anything other than what they see is in their own interests. Evangelism has the ability to accelerate that; i.e. if a browser is becoming more popular, evangelism can have an impact on developer behavior. It has for us on Chrome for the desktop and I know full well that it did for FF too. I’m not making the (unsupportable) claim that evangelism alone can solve things.

As for what Apple’s WebKit people have said, that’s the entire reason why I’m trying to distinguish products from engines. I know that Gecko doesn’t really have this split, but Safari and Chrome already ship with different flags. That means that non-Safari ports can absolutely go their own way and add diversity to the ecosystem. Please don’t claim that what Apple says about Safari must necessarily affect other WebKit-based browsers. It just ain’t so.

To summarize: you are calling my arguments straw men on the basis of misinformation and mischaracterization. At least you’re not alone in that. There is evidently some fault to me for not writing more clearly.

i wanted to write a long post, but @Michael Mullany just nailed it. Completely agree with every word there.

>> If Mozilla decides it’s going to expropriate `-webkit` prefixes and masquerade as an iOS browser, we can see a requirement for us to figure out a different way to detect that it’s Firefox and disable those effects.

+1. Firefox looses customers because it (was) not innovating fast enough, and many “supported” under moz prefix features were extremely buggy (and transitions still are, for example).

To be clear, Mozilla isn’t frustrated because they aren’t receiving some sites cool 3d-css transition effect in mobile firefox. I’m more frustrated that we receive win-mo sites from 2000 instead (i.e. they are neutering the already neutered mobile sites). We’re only just now turning on hardware accelerated layers/transforms on mobile, because… well frankly its been a lot of work to get them running correctly on the slew of different android hardware/software combos out there. Same reasons Chrome has opted to not even try to run there. We’re close to having nice fast transitions and webgl (canvas is a different beast as well) on at least some subset of phones.

I’m frustrated to see prominent webdevs advocating UA sniffing as a method of doing feature detection though. Once hw accelerated layers are on in FF mobile, there will likely still be hardware white/blacklists. Turning off the feature because the UA contains “firefox” will likely leave out users on newer, higher end phones where performance would be great. i.e. UA sniffing as a method of disabling effects is not generally a good idea. Feature detection (and feature performance detection if we need it) are better and more surefire ways to fix things and won’t require you to go through by hand and update them with each release.

More importantly, completely ignoring Gecko or Webkit or anything else out right now, it will help ensure that when Engine X comes out, built by Joe-Schmo in his basement, and it performs 10,000,000 times better than anything else on the market, it actually has a chance to compete as well without first having to advocate to 10,000 sites so they recognize his engine, or (more likely) resort to spoofing someone else’s UA as well as spoofing their proprietary css.

First, some data: we accelerate layers just fine on Chrome for Android. Yes, it was a lot of work, yes it required huge effort. But it performs well; as does fast scrolling. What FF does in these cases is a question of investment for the Mozilla organization to speak to.

To suggest that Mozilla isn’t interested in fixing these visual issues as an issue related to market penetration requires an extraordinary step away from the plain meaning of these statements (and Tantek’s in the referenced interview). Perhaps there are additive motives too, but they have not dominated the discussion so far.

As for the idea of someone creating a new system; I think you’re vastly under-estimating the number of people and amount of time it takes to create a successful web renderer. I didn’t say “good”, I said “successful”. As I try to point out in the post, product and platform are different. A big-bang event may happen for some new code-based, but nobody sneaks up on the web and converts billions of users overnight to new browsers. It just doesn’t happen.

dbt: I didn’t scoff at it. I work on a browser derived from KHTML…and yes, I remember KHTML (and its codebase) back in the days when it was a tiny little bit of the KDE project…the plucky little engine that could. I remember being excited by the work that George and Co. were doing and eagerly trying out the 2.x Konqueror era browsers. Back in ’00-03 I kept checkouts of KTHML around so I could support it with my DHTML projects and so I could dig in and understand what worked (and didn’t) and why. It was the engine I loved but which nobody used.

Lets play the intervening time forward: to get to where it is today took something on the order of a hudred million dollars in aggregate direct investment (probably more), integration with dozens of OSes and embeddings, and more man-hours of some of the smartest browser engineers in the world than I care to consider.

You can trace a similar history for Mosaic (the codebase that turned into MSHTML). Far from scoffing, I’m suggesting that there’s a huge difference between development and success as measured by distribution. Part of that process is the work of compatibility engineering (a key part of the difference between today’s WebKit and the KHTML of yore).

To imagine that there’s some other path to broad distribution is to go all-in on the “build it and they will come” fallacy that is so common in Open Source (and I’ve spent nearly my entire career — such as it is — in Open Source). They might come, but probably not. Our mental models of the world need to accommodate how un and under-informed users acquire technology too.