Why O, why? Thoughts on Opera’s Implementation of WebKit’s Prefixes

For those new to the discussion, Opera recently implemented aliases for -webkit- CSS prefixes in its mobile emulator, potentially with plans to follow on the desktop as well. This means that Opera will now treat -webkit- prefixes the same way it treats -o-. Bruce Lawson, an evangelist at Opera, told .Net magazine:

Opera, along with Microsoft and Mozilla, announced at a CSS Working Group meeting that we would support some WebKit prefixes. This is because too many authors of mobile sites only use the WebKit-prefixed version, and not even the standard, unprefixed one, when it is available.

Microsoft actually followed up:

A Microsoft spokesperson has provided a comment to .net on that company’s position: “A passing comment made in a working group meeting has clearly been misinterpreted. Microsoft won’t support –webkit prefixes in Internet Explorer.”

I highly encourage you to read the actual transcript, though. It’s important to note that the conversation is equally led by Tantek Çelik, from Mozilla, and the healthy conversation/debate that follows. It is clear that this move is part of a larger conversation about browser share and mobile usage.

A little context

Here’s my thirty second rundown of the mobile web: iOS and Android are killing it (Note, iPod Touch is a separate line), especially in North America, South America, Europe and Australia. Opera maintains a strong presence in Africa and Asia, most likely thanks to Opera Mini, and even that dominance is starting to come under attack. BlackBerry use continues to generally decline, though locale plays a big role here. WebOS is dead. On the horizon, Microsoft seems to be on a decent path with IE in Windows Phone and similarly Mozilla has got some great stuff in the works — that said, neither has traffic even worth mentioning at the moment.

To get specific, mobile WebKit currently accounts for about 50.58% of worldwide mobile traffic, with Opera in second at 20.93% (May 2012, excluding tablets). So it’s easy to see why developers are using features they find in WebKit: The browser is becoming incredibly popular with consumers and has great features. This also hopefully illustrates why Opera was the first to implement this idea of aliasing WebKit’s prefixes — in a certain light, they are the only browser remaining that poses a threat to Mobile WebKit’s advance.

The stated problem

It’s clear that implementing another browser’s prefixes is a solution — but what problem is it solving, and for whom? The next line from Bruce Lawson’s quote:

This leads to a reduced user experience on Opera, Mobile Firefox and Mobile IE, which don’t receive the same shiny effects, such as transitions, gradients and the like, even if the browser supports those effects.

Let’s break this down. In fact, even if Opera pushes -webkit- support into production, most features will still not be accommodated by Opera Mini, only Opera Mobile. So the web is slightly less “shiny” for some browsers — some browsers are getting flat, square buttons when they could have round, bevelled ones. Certainly, though, this is not a new concept to web developers or browser vendors, nor is it “broken” by most modern web developers’ definition. There is a small exception to this, noted below.

The real problems

So what, then, are the real problems that aliasing WebKit’s properties solves?

• Usability issues that arise from poorly implemented CSS3. Really, the only case in which I see these effects “blocking content” is with gradients: When web developers fail to declare a backwards-capable background-color. I would think this is rare, however it is a very real UX issue hitting users that vendors have an opportunity to fix.
• Non-WebKit mobile browser vendors are losing mindshare, especially among developers. Aside from “the gradient issue”, I don’t believe having a few fancier effects will help vendors here. It would appear that mobile mindshare, for both consumers or developers, is now heavily dictated by hardware, hardware integration with the browser, and platform (operating system).
• Browser vendors are tired of answering support requests for features they know they support. From this specific example, I don’t think Mike and I are on the same page about “regular users.” (I would imagine most don’t even know what border-radius means). Again, this is not a problem for users as much as it is for browser companies, nor is it a new problem in any way.

My problem

So there you go. We have real problems, for both the browser vendors and the users.

If it isn’t already clear, I’m not a fan of this solution, and we’ve finally arrived at the crux of why: It is a short-sighted solution, primarily for the benefit of browser vendors, which contradicts an existing standard.

For the first problem noted above, regarding usability and gradients, it acts as a Band-Aid. Though it will fix the usability for their own latest browsers, it does not educate users, sends the wrong message, and leaves the site broken in older browsers.

This last FAQ from the announcement highlights what I mean:

So I only need to use -webkit- prefixes now? w00t! Absolutely not. We’re doing this now to ensure that there is compatibility with the 13 features we’re aliasing. We hope we never need add any more and that we can drop support for these. It remains vitally important to make sure that you code for all browsers, even if they don’t have support for a certain feature while you’re coding.

This is a bit of a, “Do as I say, not as I do,” type of answer. Performance-minded users will consider dropping -o- prefixed rules in order to save precious bytes in their CSS, especially for stylesheets with a lot of rich gradients. This idea could gain popularity if other browsers follow suite (Mozilla is clearly interested, even if Microsoft is backing out). In essence, Opera is saying, “Code the same best practices that have always been around,” while gently pulling you aside to say, “But if you don’t, no worries, we got you covered… for now.”

Faruk Ates sums it up best:

What this results in, however, is that “lazy web devs” now have even less incentive to do the right thing and test their work in Opera, because the onus has now fallen to Opera entirely to make sure their browser is doing everything right.

The problem leads to a solution that reinforces the problem.

A small technical consideration

Most of my objection thus far has been conceptual. There is also one small issue with the implementation I should note, though it is fairly nuanced:

In order to send a rule with different values to Opera, it must be after the -webkit- rule in the cascade… We discussed having the -o- prefixed version always trump a -webkit- version, but that breaks the cascade mechanism of CSS, which make it much harder for authors to debug sites and could have many unforeseen consequences. Therefore, we ask you to make a once-only check.

Essentially, I do think that -o- should always trump -webkit- in Opera, for what I hope are fairly self evident reasons. Opera cites the “cascade” here, but the CSS cascade has never been applied to separate vendor prefixes like this — in fact, this seems counterintuitive as it runs the chance of “breaking” existing sites. If one is supplying separate versions to WebKit and Opera, they now have to check the order of these declarations across all of their stylesheets.

Again, the aliases solution is a bit of a hack meant to improve UX for these browsers — I don’t believe it should mandate that browsers who implement multiple prefixes necessarily treat them “equally.”

Take a deep breath

I’ve had the pleasure of meeting several Opera employees at various conferences, and pretty much every one has been a good-hearted, uber-talented developer. The engineering team at Opera does an amazing job at implementing and, to some degree, leading web standards. I, personally, do not test on it enough — and subsequently silently carry my shame like most other US-based web devs I know. I’m sure they have done wonderful research leading up to which properties they chose to alias, and I am sure, to their word, they handle those properties just fine. No cities will explode and no kittens will be harmed.

In fact, contrary to popular belief, it is my respect for Opera which has led to this post. For better or worse, the CSS WG, and Opera’s browser development, operate in the public. If this were a silent upgrade — and didn’t disturb current behavior as noted in the technical section above — none of us would know, let alone care. Unfortunately, though, all of this does happen in the public, and so the choices they make send a message.

I simply believe that at best, this solution acts as a Band-Aid, and at worst, it adds new incompatibilities, sends the wrong message to developers, and sets a loose, subjective guideline for other browsers to follow suit.

Some other potential solutions

To avoid being accused of taking the easy road, I have compiled a list of other possible ways Opera could try to improve our situation:

Fix Vendor Prefixes

Revise the purpose and implementation of vendor prefixes. I understand the need for browsers to implement each others’ prefixes, because we’ve made a bit of a mess — I just think we should do it in a more global, thought-out approach, with rules. One example: What if browsers could identify -anything- in addition to the unprefixed rule, once it has been accepted as a Candidate Recommendation? This is slightly similar to what Opera is doing, except they would have to leave out Transitions, as it is still a draft.

Also, let’s drop the “we hope we can one day remove this” from the messaging. Find a backwards compatible, permanent, solution and let’s move on.

Evangelize

Send an email to the CTOs and CMOs at Microsoft and Mozilla and use the subject line, “APPLE N GOOGLE R GOIN DOWN!!!” That’s attention grabbing. Anyway, tell them you want to run a campaign to get web devs using all the CSS prefixes. Pool your money and hire some badass web designers. Create demos that rock our faces — Except, on Mobile WebKit, create an interstitial: “We noticed you’re visiting on a WebKit browser.”

Bam — immediately, this will bring up strong emotions from the dark days in most developers. “While this demo also work in your browser, it looks equally fantastic in Opera Mobile, Firefox for Android, and Internet Explorer. This matters. There are currently XXX,XXX,XXX people who browse the mobile web every day, who don’t have iOS or Android. Learn more.” Then, in your learn more, explain why this matters, and link to resources like Can I Use, Prefix the web, and CSS Prefixer and great tools like Sass/Compass, Less, and Stylus.

In short, continue evangelizing: It’s the most important part of making sure this issue is not just fixed in your latest browser, but across the web.

Realize you can’t win them all

Make a page on the internet that says, “Sorry, not all pages on the web look exactly the same.” Then, when someone emails you saying, “Hey, this button looks more round on my laptop,” you can just reply with the link. Actually, it already exists! (thanks Jay)

If they send a more substantial error, like the gradient example above, say, “Sorry, this is a bug on the website’s part, you should contact them.”

And finally

If you’re a web developer, use CSS prefixes responsibly. They mean “experimental.” If we didn’t screw this stuff up so much, the browsers wouldn’t have to consider this hack. That said, if we are going to do something about it, let’s think it through to its logical conclusion: A global, backwards-compatible, change to the current implementation of vendor prefixes.