Eric Meyer of A List Apart, CSS wizard and fan of vendor prefixes, interviews Tantek Çelik, Mozilla’s web standards lead, on Mozilla’s controversial plan to support -webkit- prefixed properties.
Article Continues Below
Tantek precipitated the current crisis in Web Standards Land during a public meeting of the W3C CSS Working Group, in which he noted the predominance of WebKit-only mobile sites, thereby creating a browser monoculture. Tantek discussed Mozilla’s solution — having Firefox Mobile pretend to be like Webkit and support a few -webkit- CSS properties — which inflamed many in the standards community, especially when representatives from Opera and Microsoft immediately agreed about the problem and announced similar plans to Mozilla’s. The following discussion was conducted via EtherPad, instant messaging, e-mail, and telephone calls.
Let’s start with the basics. What exactly are the Mozilla, Opera, and Internet Explorer teams planning to do?
I can’t speak for the Opera and Internet Explorer teams. Mozilla is currently analyzing mobile web sites for a couple of problematic behaviors—sites that are sniffing for a WebKit user agent string, and only sending high-fidelity mobile content accordingly; and sites that are using only or primarily -webkit- prefixed properties.
Based on that analysis, we are planning on implementing a UA string for Firefox Mobile that passes such UA-sniffing—ironically, this is similar to how WebKit added “like Gecko” to its UA string when Safari launched—and implementing specific -webkit- prefixed properties on a case-by-case basis, when justified by the data collected.
You’re not going to just universally map -webkit- to -moz- ? The plan is to only support a limited subset of all -webkit- properties?
Right. Our goal here is to minimize the number of other vendor-prefixed properties that we have to support to only those that are justified by the data, and that will make a difference to Firefox Mobile web users. The data we have so far does not justify blanket support of all -webkit- properties.
In addition, we are considering only supporting the -webkit- prefixed version of a property if and/or when we also support the unprefixed version. That will provide web developers with a standards-based option instead of using prefixed properties.
But as of now, we don’t know which properties that will be. Or do we?
We don’t have a specific list as of now. We’re being very deliberate about this, and scrutinizing our data accordingly to make sure that we have data-driven justification—that we only support what the data justifies supporting—and efficacy, which means making sure that adding such support does make a difference to Firefox Mobile users.
I assume that list will change over time. This seems like it’s going to generate even more confusion for developers, since you’ll be supporting the -webkit- prefix on some properties and not others. How do you expect developers will keep up with who’s supporting whose prefixes on which properties?
Vendor prefixed properties were never supposed to be something developers could depend on. They were, and are, for experimental implementations and technologies in progress from iterations of CSS working drafts in the process of standardization. I expect developers to keep up with unprefixed properties and the implementations that support them. That’s what developers can depend on.
That doesn’t seem realistic, though. If developers stuck to what they can depend on—the unprefixed properties—we wouldn’t be in this situation.
In fact, developers sticking to what they thought they could depend on is why we are in this situation—some prefixed properties were pitched as dependable and then supported as such without advancing the standards accordingly.
Will Mozilla maintain a list of which prefixes are supported on which properties?
Mozilla will continue documentation of what properties Firefox supports, with any recognized prefixes, on developer.mozilla.org.
Okay, so that’s what you plan to do, but how about why you plan to do it? What’s the goal of your plan?
Mozilla’s goal is to open up the WebKit-specific part of the web to other vendors in the same way that, years ago, Mozilla and Opera had to be practical about what IE-proprietary or IE-only technologies to support. We’ve raised the problem of both a WebKit mobile web monoculture; and also the insufficiency of evangelism to fight it, despite numerous evangelists at Mozilla, Opera, and Microsoft working with web developers to publish standards-based cross-browser content.
With so many evangelizing the right thing, why has it been insufficient?
In the past 10+ years, web standards evangelism has been quite effective, raising awareness and adoption of valid HTML+CSS, progressive enhancement, unobtrusive scripting, microformats, et cetera. However, despite Mozilla’s and others’ evangelism efforts over the past year, the WebKit-specific mobile web is growing faster than we can evangelize, especially in contrast to WebKit-specific evangelism, both implicit and explicit.
I think it is a fair question to ask: what went wrong here, how did we end up with a WebKit mobile web monoculture despite at least some standards evangelism to the contrary? I’m not sure it was any one thing, I think there were several contributing factors that together created the conditions for the emergence and reinforcement of this particular monoculture.
First, the innovations in WebKit helped raise expectations of what was possible on the web platform—which, to be clear, was and still is a very good thing, as advancing the potential of the open web platform is a goal that we all share.
Second, the widespread WebKit adoption in iPhone, Android, and BlackBerry. This should have been a warning sign; that is, when multiple vendors all use a single implementation, there is a high likelihood of a monoculture emerging.
Third, we’ve seen strong evangelism of -webkit- features by Apple and Google, most notably as part of “HTML5” presentations and demo sites. Some of those “HTML5” sites have subsequently been updated with multiple vendor-specific prefixes for experimental CSS features (for more cross-browser demonstrations and coding). However, the implied message of early WebKit-only versions still echoes today.
Fourth, there have also been years of talks in nearly every web design/development conference where speakers, excited to discuss and demonstrate the latest cutting edge, showed sites and code built with -webkit- prefixed properties. This provided implicit, if not explicit, encouragement to target and code primarily or only for WebKit, especially on mobile sites.
Lastly, all of the above has been exacerbated by how long it has taken the CSS working group to standardize some of these innovative -webkit- prefixed properties, so that all browser engines could support them without prefixes, including WebKit, and provide web developers a standards-based option they can depend on.
You said you’re doing this for Firefox Mobile users. So this plan is only in your mobile product, and not in the desktop browser?
The UA string for Firefox Mobile is already different than Firefox Desktop, so yes, that part mentioned earlier is specific to the mobile product. As far as implementing particular -webkit- properties, we’re currently weighing the option of supporting them only in mobile, thus limiting exposure, versus providing a consistent Firefox/Gecko platform for web developers that they can depend on.
Since the goal here is to provide a consistent experience for all mobile users, it seems pretty likely you’d eventually decide to provide a consistent experience for all Firefox users, doesn’t it? Thus causing this strategy to spread from mobile to desktop.
The problem we’ve found is specifically with mobile web sites that have been coded for WebKit-only. Since there’s much more browser diversity on the desktop, there’s a lot less WebKit-only coding happening there. This is where the efficacy requirement comes in—if something doesn’t actually help the user, there’s no reason to implement it. So we could implement this across the Firefox platform, but there’s much less of a point to it if doing so doesn’t make the desktop experience better for users. We still have to consider the impact on developers, though, and that might be enough. We may try things in beta builds to get feedback.
Along the same lines, this doesn’t seem like something that will stay limited to a few properties here and there. It seems more like once the door is open, eventually you’ll get to the point of just treating -webkit- as if it were your own prefix. Or even if Mozilla doesn’t, then Opera or Microsoft will do it at some point and subsequently you’ll be forced to follow suit. True, or no?
I think that’s dependent on whether we can open up the WebKit mobile web monoculture or not. History has shown that Mozilla and others succeeded with opening up the IE web monoculture with limited implementation of a few IE-only features such as innerHTML and XMLHttpRequest, both of which have been subsequently standardized with the W3C. There was no blanket implementation of IE-only features in Firefox. Mozilla has a solid track record here of very deliberate and case-by-case pragmatic implementation of features for web compatibility.
But suppose, say, Opera goes ahead and universally supports -webkit- for reasons similar to those when they had their UA string default to Internet Explorer for a while. Wouldn’t that force Mozilla onto the same path? And if not, why not?
If another mobile browser supports -webkit- universally, I don’t see how that impacts the situation, because the dominant mobile browser engine, WebKit, already supports -webkit- universally.
Peter-Paul Koch has said quite forcefully that “there is no WebKit.” You see it differently, obviously.
It doesn’t matter that Peter-Paul Koch says “there is no WebKit”—what matters is that web developers believe and act as if there is a WebKit. They are coding and shipping mobile sites accordingly, by sniffing for WebKit UA strings, and by using only -webkit- properties. That effect is measurable. Denying it doesn’t make it not so.
And by developers doing so, they’re giving a reduced or, in the worst case, broken experience to users of non-WebKit browsers like Mozilla, Opera, and Explorer.
Right. We’re seeing downlevel or “feature-phone” ultra-minimal and reduced functionality experiences being sent by mobile web sites to non-WebKit mobile browsers.
In at least some of those cases, you fully support what they’re doing, except they’ve hidden it behind -webkit- prefixes?
Yes. Current versions of Firefox support -moz- prefixed versions of CSS3 gradients, transforms, animations, et cetera. We’re working actively with the CSS Working Group to rapidly advance the respective specifications and drop vendor prefixes on such stable features. That way we can all help the web platform move forward with standards, rather than handfuls of vendor prefixes.
How often is a site truly broken, though? If a site is different but still functional, that’s kind of what we expect on the web already. It seems like your real objection is that your browser’s rendering is less spiffy, not that users are being locked out. Is this really a threat to the adoption and use of non-WebKit browsers?
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.
The promise of vendor prefixes was that implementations could be tested in the wild and problems corrected before behavior was formalized. That paid off handsomely with gradient syntax, for example, where totally incompatible syntaxes were tried out, and eventually a unified syntax was found. This plan seems like it imperils that ability—that, once vendors start supporting each others’ prefixes, we may as well drop prefixes altogether. Is that a reasonable conclusion?
Sometimes there’s an expectation in technologies that they’ll be perfect, without any flaws or bumps. Of course, such expectations have no bases in experience so it’s not clear where they come from. CSS vendor prefixes are no different in this regard. They’ve actually been quite successful—many browsers experimented with iterations on various features for years, eventually standardizing what works.
Mozilla, in particular, has an excellent track record of trying things early with a -moz- prefix, and when standardized, shipping a standard, unprefixed property as well as dropping the experimental -moz- prefixed version. There has been pain along the way sometimes, too: for example, how long it took border-radius to get standardized, which it is now. However, the WebKit mobile web monoculture is probably the first time we’ve seen a serious problem with vendor prefixes. Should we give up on vendor prefixes now, despite their imperfect but impressive track record?
There have been calls to replace vendor prefixes with “universal” prefixes, such as -x- or -beta-. What’s your take on that idea?
Experience has shown in other standards efforts that when there is a beta or experimental prefix, like -x-, that everyone does end up supporting them forever in addition to the unprefixed version. For example, check your email headers—you’ll see lots of X-* headers. Or the fact that browsers have to support image/x-png in addition to image/png for PNG images.
On the contrary, with CSS vendor prefixes, Mozilla has shown it is possible to drop -moz- prefixed properties and move the web forward. I believe at least one other browser vendor has been able to eventually drop their vendor prefixed properties after they’ve shipped the standard unprefixed versions.
Why couldn’t “universal” prefixes be dropped the same way vendor prefixes have been? What’s the difference?
Universal prefixes become seen as dependable across browsers, and thus the network effects reinforcing their use and support are stronger—perhaps strong enough to require supporting them indefinitely for compatibility, like the aforementioned X-* mail headers and content types.
There is a similar risk when multiple browsers support -webkit- prefixed properties. This risk could be mitigated and perhaps even overcome if multiple browsers support the equivalent unprefixed properties, and we encourage web developers to instead use those moving forward. However, that won’t fix the WebKit-specific mobile sites that have already shipped.
So this is focused on fixing the problem now, at risk of creating a similar problem in the future. Aren’t you just deferring the pain?
It’s certainly a complex problem with many variables and many actors. The combination of patching past problems and enabling a dependable path for future development provides a good balance of helping users and developers. We’re basing our approach on study and collecting data, and expect to evolve and iterate it as such.
No approach is without risk, but doing nothing at all, or pretending there is no problem, is riskiest of all because it merely lets the WebKit mobile web monoculture worsen. The last time we had a web monoculture, it set the open web back for years.
Daniel Glazman, co-chair of the CSS Working Group, put out a call for action in response to your plan. Do you have any suggestions for what we can do to improve the situation?
As web developers, there are few key things we can do.
First, stop doing “WebKit”-specific UA-sniffing and content-serving, especially on mobile.
Second, stop only using -webkit- prefixed properties, and either use the unprefixed property where it’s standardized or “stable” per the Working Group; or, if it isn’t stable, use every vendor’s prefixed property where they’ve announced or shipped support.
Third, help evangelize corrections for any sites you see which are doing WebKit-specific UA-sniffing and/or only using -webkit- prefixed properties. Similarly, help evangelize corrections for any webdev sites which are promoting, even implicitly, the use of WebKit UA-sniffing and/or use of only -webkit- prefixed properties.
Most importantly, set a good example. Use web standards first and foremost in your sites, articles, and talks. When discussing or demoing experimental features or standards-in-progress, whether in one browser or many, be up front with warnings, and make it clear what’s shiny today may break tomorrow.
