Opera confirms WebKit prefix usage
Open web under fire as Opera argues author errors forced its hand
In February, we reported on a meeting of the W3C CSS working group, stating vendors were considering implementing WebKit prefixes, in order to combat a perceived WebKit monoculture that’s particularly noticeable in mobile.
At the time, developers and industry figures rallied against the plans, arguing it would negatively impact on the open web and interoperability. An industry source today told .net Opera will imminently implement WebKit prefixes, largely due to being “terrified of being outdone in the mobile marketplace” and the “large number of [mobile] websites designed exclusively for WebKit”.
The changes will first appear as an experimental build of the Opera Mobile Emulator, and the source stated Opera isn’t happy about the turn of events but said it “cannot reasonably choose to remain incompatible with a significant part of the web, when it's technically simple to enable the features that these websites are using”.
A new browser war
Technical details will soon be outlined in a blog post, but Opera stated it has essentially aliased properties and values that are frequently used with WebKit prefixes but without fall-backs and that Opera already supports them in some form. An experimental build of the Opera Mobile Emulator will soon be released on dev.opera.com that includes these changes. The prefixes will then be implemented in Opera Core, meaning they will affect both mobile and desktop versions of the browser.
Our source sympathised with Opera’s plight, but nonetheless told us of concern for the open web: “[Opera’s decision] sets an incredibly poor precedent, allowing any vendor to implement any vendor prefix any way that vendor wants. That's incredible fragmentation of the web.” However, we were told that blame should largely lie with WebKit, which “isn’t playing fairly in the collaborative and interoperability space”.
In terms of the perception of a WebKit monoculture, experts such as Peter-Paul Koch have in the past argued that the figures suggest otherwise: Opera usage is higher than WebKit on mobile, and developers are largely to blame for only testing mobile sites on iOS devices. However, although such usage stats are accurate on a worldwide basis, our source argued that “the proliferation of iOS, particularly in the US, UK, Australia and Canada, is a threat”, and with Firefox and Google also improving their mobile experiences, Opera is “threatened in the place it has never been threatened before – mobile near-ubiquity”. The net result could be a “new era of browser wars,” thought our source.
Opera blames author error
Opera web evangelist Bruce Lawson provided .net with the following statement, outlining the company’s reasoning:
"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. 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.
"One of the HTML5 design principles is: 'Error handling should be defined so that interoperable implementations can be achieved. Prefer graceful error recovery to hard failure, so that users are not exposed to authoring errors.'
"CSS is not HTML, of course, but the principle still holds. Using single-vendor code on the World Wide Web that results in non-interoperability is an authoring error. In the same way that the HTML5 parsing algorithm ‘rewrites’ HTML to make tags close correctly in the DOM, in order to ensure interoperability, Opera will react to certain WebKit-prefixed CSS properties as though they were -o- prefixes, in order that our users are not exposed to authoring errors.
"Note that we're only supporting those that are most widely used, and we will publish a full list soon. We do not plan to alias every WebKit prefix and, as far as we know, neither will Microsoft and Mozilla, and so it remains as important as ever to use all vendor prefixes and the unprefixed property to ensure interoperability."
UPDATE: 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."
UPDATE: Opera has now revealed its list of affected prefixes.
What are your thoughts on Opera's plans? Are you in favour of other vendors implementing WebKit prefixes, or do you foresee problems ahead? Let us know in the comments.
16 comments
Comment: 1
When a responsible developer uses the official property and all prefixes, will Opera render the Opera or Webkit prefixed property?
Do they choose to render whatever property comes last and cause potential issues with existing implementations because developers didn't know they'd have to consider the arrangement of prefixed properties, or do they render Opera regardless of it's position within a rule set, disrespecting the fact that a CSS property placed below another should have precedence?
It's not a problem if browsers perfectly implemented CSS3 the same, but that's not always the case: http://www.ianlunn.co.uk/blog/articles/vendor-prefixing-standing-up-for-...
Comment: 2
The failure of authors to implement prefixes properly isn't breaking the web — in general it means a less elegant experience for users of non-webkit browsers.
I'd like to see some examples of sites where this problem is "breaking the web" for Opera users, rather than all this theoretical posturing. At the moment it feels like an act of vanity on Opera's part.
And it seems unfair to blame web authors for their failure to implement prefixes properly —blame the transient nature of the CSS3 spec which makes it incredibly difficult for vendors and authors alike to implement CSS3 features reliably and consistently.
Comment: 3
Comment: 4
Comment: 5
Comment: 6
@IanLunn
great question. I'm preparing a longer post when we actually have a release (contrary to Craig's "source" for his article, this isn't live yet).
Some of us (me included) wanted that the -o- prefix, if present, would always trump the -webkit- prefix. But that would be breaking the cascade, which would be very problematic (and a nightmare for developers to debug). So we'll respect the cascade; if there is both an -o- and a -webkit- prefix, and the values differ, the last one will win.
@philp I have no intention of pointing at individual URLs for a name-and-shame. The most common complaint we got was about sites that had, say, white text on a graient background. The gradient had only -webkit- prefixing and there was no fallback background-color. This meant many buttons etc were white text on a white background. You might call that a "less elegant experience for users of non-webkit browsers"; our customers called it "a broken website in Opera".
@rlucia you said "please don't". Many have said that, but no-one explains why. If you have a site that only uses -webkit- prefixes, all that happens is that now you get Opera support for free. Your site doesn't grind to a halt in your beloved iPhone. If you have a site that used all the prefixes, it continues working as before. Unfortunately, if you have a site that sent different values for Opera and webkit, you may need to change the order of your declarations (see my answer to @IanLunn above). I regret this, but agree that breaking the cascade is far worse.
@edge07 ""nobody" uses Opera" - did you really call 250 million people "Nobody"? What a solipsistic worldview.
"The better the spread of advanced properties is and the easier the implementation, the better for us developers".
So now you write -webkit-transition and it also works in Opera. That's easier for you to implement, and spreading advanced properties to a quarter of a billion extra people. Oops. I mean to "nobody".
Comment: 7
Yes, what you're describing there — the failure to provide a fallback — is a perfect example of bad authorship. But, I don't see that as a problem which is exclusive to the prefix debate, it's just bad practice and a failure to apply the principles of progressive enhancement, much as the failure to provide a background-color as a fallback for a background-image can cause the same problem in *any* browser.
And I think this is my fundamental problem with the stance of Opera and the other vendors: they're not fixing anything by supporting -webkit — instead, they're advocating even *more* bad practice in authorship.
What would fix all of this? In my view: the abolition of vendor prefixes completely. They were intended as experimental hooks, and now they've become common-use properties. So I question why we need them at all now. What we need to see is the phasing out of -webkit by Webkit vendors, and have those properties replaced with the solid, reliable, non-prefix, real ones. But that's not going to happen now, is it? We're stuck with -webkit for a long, long time...
Comment: 8
By adding this change, the control is taken away from web developers. There may be an issue, for example, where a gradient is causing a problem is Opera. With this new update, even if the -o prefix is removed, the webkit one will be taken into consideration even if there is a fallback colour defined (which is the intended view for Opera). Web Developers would then possibly need to check the UAString to figure out which browser is viewing the page and remove the webkit gradient for Opera users, even more messy!
With regards to the above (fallback colour). Surely it would make sense to reach out to these webkit prefix sites and urge them to either a) provide fallback colours when gradients are ignored or b) add Opera prefix support. Either way the CSS should be changed and not the way the browser interperates CSS.
Comment: 9
I disagree with your objection: "By adding this change, the control is taken away from web developers." simply because those developers have exercised control in a way which harms users, damages interoperability and therefore harms the web.
I agee with you here: "Surely it would make sense to reach out to these webkit prefix sites and urge them to either a) provide fallback colours when gradients are ignored or b) add Opera prefix support. " and my colleagues and I do this all the time. But there are some you can't reach, and others who don't care - they're too fixated on their iPads.
Comment: 10
Appreciate your comments, so are you saying that if a site was designed to have gradients in Chrome and not in Opera this wouldn't be possible?
Comment: 11
If Opera is using the webkit layout engine in their browser (which they are not - they use Presto) then it makes no sense to adopt the webkit prefix. End of story. Why this argument? Because by Opera taking that direction, no impetus is given for coders to write the proper code in the first place and coding standards will become fuzzier. I mean, why not just change your name entirely to Chrome or Safari while you're at it because that's not much different than what Opera is proposing.
Pretending to be webkit when they are not is the last direction I expected to hear from Opera - a browser already known for its leadership in web standards. It's difficult to take this news seriously but it does nothing for Opera's good reputation.
Comment: 12
Not at all. If there is a -webkit- prefix *and* an Opera one, the later wins.
div {color:white; background-color:black;height:100px;
background: -webkit-linear-gradient(top, rgba(30,87,153,1) 0%,rgba(125,185,232,0) 100%);
background: -o-linear-gradient(black, black);
}
shows a linear gradient on webkit, and a black bg in Opera, so you can read the white text.
However
div {color:white; background-color:black;height:100px;
background: -webkit-linear-gradient(top, rgba(30,87,153,1) 0%,rgba(125,185,232,0) 100%);
}
shows the linear gradient in Opera and webkit, as it's assumed that the author has forgotten a line of CSS.
Comment: 13
This surely won’t encourage the Greyhound drivers to stick to the rules and obey the speed limit. Sure it will give the passengers a “better” experience (after all, they end up in LA before the passengers in any other bus), but at what cost? The end result is that the drivers will continue to break the law, simply because they (or anyone else for that matter) won’t be punished for taking those liberties.
That can’t be right.
It’s the same with this situation — Opera is telling authors that it’s OK to write “lazy” code, because their browser will render it properly anyway and it will give Opera users a better experience.
This whole thing is great for Opera users. But creates a disadvantage in many other areas.
Comment: 14
-webkit-backface-visibility: hidden;
-moz-backface-visibility: hidden;
-ms-backface-visibility: hidden;
-o-backface-visibility: hidden;
backface-visibility: hidden;
I understand these are experimental features, and that the W3C standardization needs to go through, but it's just slow. By the time everyone implements the prefixless version, the web has moved on, and developers are playing with the next shiny toy.
How about the DRY principle? If Opera wants to achieve the same result as webkit browsers, they need to implement css 3d transformations. It doesn't. So in order to do that, Opera needs to write the code. Code that webkit has already written. Reuse?
Comment: 15
The point is that Opera wants to provide its users with the best possible browsing experience. That doesn't mean putting two fingers up to bad authorship, it means trying to work around it. Just like browsers try to recover malformed HTML rather than just throw up an error message, they want to try to give users the experience that authors are intending.
Why? If lots of sites have -webkit features that don't work in Opera, those websites aren't going to look as good in Opera (assuming they are readable at all). That isn't a good advertisement for Opera. People aren't going to stick around with Opera forever if Safari and Chrome are giving a much better experience. Just like with the browser wars of the 1990s, when sites worked fine on IE but failed miserably on Netscape, people abandoned Netscape. They couldn't care less which manufacturer is technically in the right, they just want a browser that displays all sites properly.
This sounds like a sensible and pragmatic solution to the problem of Webkit-obsessed deezyners who have forgotten there are other browsers out there supporting funky CSS3 effects (or even who have forgotten there are other browsers out there, full stop).
Comment: 16