Judgment Day Arrives: Opera Implements the CSS3 Webkit Prefix

Contributing Editor

In February 2012, we reported the minutes of W3C meeting where Mozilla, Opera and Microsoft discussed implementing -webkit prefixes in non-webkit browsers. The reason: some developers use only webkit prefixes — their sites look good in some browsers, but broken in others even when they offer the same level of CSS3 support. The issue is especially prevalent on mobile browsers and many developers fail to look beyond their high-end Apple or Android devices.

Opera has now announced support for 14 CSS3 webkit properties in their Mobile Emulator. The implementation will eventually reach all editions of their desktop and mobile browsers. If you’re thinking “Opera has a tiny market share”, think again: it’s the world’s most-used mobile browser.

Perhaps I’m being overly dramatic, but Charlton Heston’s famous line comes to mind: “They finally, really did it. You manics. You blew it up!”

Opera -webkit Aliasing

Opera analyzed stylesheets from 10,000 popular websites to determine which CSS values/properties would receive -webkit aliases:

-o- prefix -webkit- alias
-o-linear-gradient -webkit-linear-gradient
box-shadow -webkit-box-shadow
-o-transform -webkit-transform
-o-transform-origin -webkit-transform-origin
border-radius -webkit-border-radius
border-top-left-radius -webkit-border-top-left-radius
border-top-right-radius -webkit-border-top-right-radius
border-bottom-left-radius -webkit-border-bottom-left-radius
border-bottom-right-radius -webkit-border-bottom-right-radius
-o-transition -webkit-transition
-o-transition-delay -webkit-transition-delay
-o-transition-duration -webkit-transition-duration
-o-transition-property -webkit-transition-property
-o-transition-timing-function -webkit-transition-timing-function

If the browser encounters a property such as -webkit-border-radius, it will apply that effect. If you’ve defined -webkit-border-radius, -o-border-radius and border-radius, normal CSS cascading rules apply and the last defined rule or most appropriate selector will be applied, e.g.


#myelement
{
	-o-border-radius: 3px;
	border-radius: 6px;
	-webkit-border-radius: 9px;
}

All properties are considered to have equal priority so Opera applies a border radius of 9px.

With regard to differences in behavior, Opera state:

As far as we can tell, the behavior the properties that we have aliased is identical in WebKit and Opera, or at least close enough that the differences will not matter in practice. If it turns out that there are differences big enough to cause breakage, we will consider our options, one of which is to align the behavior of our -webkit- prefixed variant to what WebKit actually does.

Opera make a reasonable case to justify their decision. While they understand the complaints, their primary goal is to create a browser which works well for users — who outnumber developers by many thousands to one.

The Backlash

Most developers understand the problem but disagree with the solution. It’s crude and has the potential to break the web. Taking the decision to it’s logical extreme, all vendors would support every prefix but any implementation differences would render the CSS property useless.

The solution rewards bad development practices. While Opera advises you use all vendor prefixes, they will exacerbate the problem:

  • Less conscientious developers will see this as justification for only targeting webkit browsers.
  • If your site uses differing -webkit and -o values, it will now be affected by CSS cascade rules. Is it easier to analyze and retest your code or simply remove the Opera properties?
  • It will become easier to accidentally omit the -o prefix since sites will work as expected.

Several problems have already been reported. For example, Modernizr evaluates prefixes in turn until it finds one the browser supports. Therefore:


Modernizr.prefixed("transition");

now returns WebkitTransition in Opera. Transitions are new to Opera and the browser doesn’t support every webkit CSS and JavaScript property. If you want to adjust or disable effects in Opera, you can’t rely on Modernizr-like detection code. You may even need to implement nasty browser sniffing.

However, my biggest issue is this: where are all these problem sites? Has user experience suffered from the lack of rounded corner, gradient, shadow, transition and transform effects? Are those sites genuinely broken or has Opera taken a (marketing) opportunity to make their browser look better?

Since Opera has analyzed 10,000 websites they can contact the owners directly. At the very least, they could publish a “hall of shame” which provides examples and highlights the technical issues. Many developers would happily contact companies on Opera’s behalf. Some would be prepared to fix sites for free since it could lead to future contracts.

There are no easy solutions to the vendor prefix crisis. I understand Opera’s reasons but, regardless of how this is implemented, it’s inevitable that something will end up broken.

Some good news: Microsoft has announced they will not support webkit prefixes in Internet Explorer (although there’s nothing to prevent them reversing that decision). Mozilla is yet to reveal their intentions — they will be watching Opera’s situation closely.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Alessandro Calleri

    I hate vendor css prefix. Css, like every others W3C specs, should be a standard that every browser vendor implements in his own rendering engine.

    • http://brozra.com Russ

      Agreed. W3C should put its proverbial foot down and say enough is enough. But they won’t and us developers are still going to be stuck with muddling through all these vendor prefixes to ensure cross-browser compatibility for the sites we build.

  • Patrick

    Oh dear. What a horrible, short-sighted decision. I guess we’ll see how it pans out, but I expect this to cause significant issues for us all at some point down the line. It’s not hard to see this eventually leading to the abolition of every non-webkit prefix, which could render all prefixes useless. All it would take is one bad browser implementation, and then you’re stuck between dropping the feature entirely or writing browser-specific code (just when I was starting to think we’d moved on from that).

    I suppose in a way it was inevitable that something like this would happen eventually – the web’s greatest strength is also its biggest weakness. Anyone can learn to code and produce a simple website fairly easily. There is absolutely no quality control. Bad developers are free to produce nightmarish atrocities of code, and although there are “best practices” which could reduce or eliminate problems like this, they are very often ignored. Browser vendors and search engines have been struggling for the last decade to find a way of managing the inconsistent, badly written mess of code that makes up the Internet. Eventually something had to give.

    • http://www.webhipster.com Vincent Young

      This pertains to pretty much any programming language and development environment.

  • James Bozman

    Opera doesn’t apply border-radius to the img tag. It does apply the border-radius to any box-shadow applied to the img tag. So if you apply both styles to img, in Opera you get a rectangular image with a radiused shadow. To fix this I have been leaving out the plain border-radius property when applied to images. So my code looks like this:

    img {
    -webkit-border-radius: 1em;
    -moz-border-radius: 1em;
    -webkit-box-shadow: 5px 5px 5px #000;
    -moz-box-shadow: 5px 5px 5px #000;
    -o-box-shadow: 5px 5px 5px #000;
    box-shadow: 5px 5px 5px #000;
    }

    And in Opera and IE I get a rectangular img with a rectangular box-shadow. That’s fine by me. But this will no longer work because Opera will now apply the -webkit-border-radius property which I was specifically not serving to Opera.

    I know I can create a div, apply the properties to it and make it overflow:hidden; and place the image within the div, but sometimes that won’t work for the particular application.

    • http://pepelsbey.net Vadim Makeev

      Mentioned -o-box-shadow property have never existed in Opera.

  • Gennaro Vietri

    Regard to your statement
    “Since Opera has analyzed 10,000 websites they can contact the owners directly”
    there is an interesting post of Karl Dubost, member of Opera’s Open The Web Team:

    http://my.opera.com/karlcow/blog/2012/04/26/open-the-web-browser-reality

    • http://www.optimalworks.net/ Craig Buckler

      Interesting, although I’m not surprised he didn’t get a response from a large bank. Would the situation be different if 1,000 Opera users wrote in and complained, though?

  • Nightmare

    Dumb programmer just dont consider other browser than own one.

    Anyway, i dont understand vendor prefix when there is a standard one to use.

    • http://www.optimalworks.net/ Craig Buckler

      Yes – border-radius and box-shadow are available in all recent browsers without a prefix.

  • http://www.turboranks.com/ Adrian DeGus

    I used to do a lot of developing for Opera a few years back, I always enjoyed working with it. It was always very fast and stable. Honestly though, I’ve since moved away from it since the vast majority of users rely on IE and FF, and even more are using Chrome than Opera. It’s fun thinking back at my dev days with this though.

    Also, I’m with Alessandro, there should be a standard, it would make all developers lives much, much easier.

  • http://www.shaunrashid.com Shaun Rashid

    Does anyone know of a list of sites that Opera has determined as “broken”. In their press release they mention they analyzed sites in the Alexa Top 10,000 but I would love to see a list of broken sites to see if they are really broken (i.e. content not displayed to users due to WebKit prefixes) or if they just don’t look the same as they do in WebKit.

    In the list of WebKit properties that Opera has decided to receive, I don’t see any that strikes me as a property that would break a site and block users from viewing content.

  • http://Www.omiod.com Andrea doimo

    Looks like most commenters have no idea why prefixes do exists.
    I suggest to add two lines to the article to make it clear.

    • http:lingadzi.net Xesive

      Agreed

    • jfgen

      I was just thinking about that..

  • Chris Emerson

    Wow. For all the moaning that Opera have done in the past to MS about standards, they have just gone and done this. Unbelievable. I hope they get a similar amount of backlash directed at them as they are all too ready to give to others themselves.

  • http://www.ew-resource.co.uk Ian Haynes

    Am I missing something? Why don’t they all use the CSS3 standard properties?

  • jim

    Maybe M$ is paying Opera under the table to take on the “stupidhead when it comes to standards” title that IE has so richly deserved all these years. It is rather curious that an entity so preachy about standards does an about-face and stabs everyone in the back this way. But then Craig does point out that although Opera may be a footnote in PC browsing, it does have quite a following amongst the mobile crowd … so maybe we should be vectoring a little angst at the teens and 20-somethings programming all that “broken” mobile site code, eh?

  • Fred de Sanctis

    Well, I really need a complete example. Learn by doing, you know.

    Hugs.

    Fred

  • http://www.petersencreative.com Pete Jones

    If they are fixing 10,000 sites now, how many will be broken in the future?

    Lack of planning on the developers part shouldn’t constitute an emergency from the browser manufacturers.

  • http://www.brucelawson.co.uk bruce

    Hi

    Bruce here from Opera.

    Some points from Craig’s article: contacting 10,000 sites isn’t trivial. Many of them are no longer actively maintained – they were made by freelancers who have moved on from the project, so asking people to make the change may not be possible as there is no-one available to make a change.

    And the ones we analysed are not the only ones, just the most-visited ones. It makes more sense to correct these authoring mistakes in the browser, in an automatic, predictable way.

    We haven’t published the list of sites; naming and shaming isn’t valuable for sites that aren’t under continuous development.

    Craig says ” If you want to adjust or disable effects in Opera, you can’t rely on Modernizr-like detection code. ” But you can over-ride anything for Opera – just use the -o- prefix *after* the -webkit- prefix and it will over-ride it. (The two are treated as aliases and the cascade is respected).

    James Bozman had a worry about this breaking his layout, and says “Opera doesn’t apply border-radius to the img tag”. I tested this; we do support border-radius on img (and video).

    There are several comments that are very negative but without giving a reason. For example, Jim says ” It is rather curious that an entity so preachy about standards does an about-face and stabs everyone in the back this way.”

    How have we stabbed everyone in the back?

    No-one benefits from standards that don’t work. That’s why we at Opera began the work that we now call HTML5, which was clearly against the XHTML 2.0 “standard” at the time. XHTML 2 required browsers to stop rendering if the page had broken markup or an unencoded ampersand. HTML5 silently corrects errors, because users should not be inconvenienced by authoring errors.

    We’ve also made a proposal to the Working Group to amend the vendor prefix system so that it actually works. Our rep, Florian Rivoal, wrote

    When a browser vendor implements a new css feature, it should support it, from day 1, both prefixed and unprefixed, the two being aliased. If a style sheet contains both prefixed and unprefixed, the last one wins, according to the cascade.

    Authors should write their style sheets using the unprefixed property, and only add a prefixed version of the property (below the unprefixed one) if they discover a bug or inconsistency that they need to work around in a particular browser.

    If a large amount of content accumulates using the a particular vendor prefix to work around an issue with the early implementation in that browser, the vendor could decide to freeze the behavior of the prefixed property while continuing to improve the unprefixed one.

    http://lists.w3.org/Archives/Public/www-style/2012May/0125.html

    • http://www.optimalworks.net/ Craig Buckler

      Thanks Bruce.

      The problem for Modernizr is largely related to JavaScript rather than CSS (although the class names applied by that JavaScript may have an impact on CSS). Opera looks like a webkit browser to Modernizr detection code; I’d hope it didn’t cause issues, but developers will need to retest their sites if they’ve forked code in any way.

      I’m a little uncomfortable with naming and shaming, but many of us are yet to see sites which work in webkit browsers but are broken elsewhere owing to a lack of border radii, box shadows etc. It’s been suggested that the percentage of sites applying webkit-only styles runs into double figures — a couple of dozen examples would be great.

      I’ll be writing about Florian’s great suggestion shortly.

    • Chris Emerson

      Ah, the “we’re breaking standards for the benefit of the whole web community” argument. Opera has become the IE5/6 of the future. Although given how low Opera’s market share is, it may well just kill it off entirely when this ends up causing problems.

  • Pieere

    This may seem dumb to experienced developers but I actually don’t understand what the problem is. Not that I am saying there is no problem, simply that my grasp of this issue seems outdated so I don’t understand the problem. Anyone cares to re-phrase the issue, maybe with some concrete examples?

    I thought vendor prefixes came along before standards had “been finalized” as a way of e.g. supporting drop shadows before the CSS3 spec was finalized. Now it has been finalized, why don’t designers just stop using vendor prefixes altogether and rely on standards?

    What is the value-added that vendor prefixes bring today?

    • http://www.optimalworks.net/ Craig Buckler

      The problem is that some designers only use the -webkit prefix even when the non-prefixed property is available. The result: Chrome and Safari look good but IE, Firefox and Opera look bad. The developers are at fault but users blame the browser.

  • http://www.howtomake.com.ua Vladimir

    Now I’m doing a redesign of his blog and in the styles of writing all the prefixes of suppliers and I think it is correct.
    Mixing styles for different browsers to mine garbage)

    Opera Mobile is good for, well, the rest of the shit

  • http://liverpool.gov.uk Dominic Jones

    >>ahem<<

    Less. Mixins. Compile. Fullstop.

  • http://www.electricmayhemsolutions.net Adrian Robertson

    Not sure if I’m getting this right … so if I hadn’t specified o-something and only specified webkit-something, then non webkit browsers such as Opera (my browser of choice) will read and use the webkit property. No big issue there from what I can tell (though James would obviously disagree)

    And if I have specified o-something, then Opera will attempt to use this property, presuming it appears beneath the webit-something property in the cascade. Which makes sense.

    So the problem here is if I have specified the o-something property above webkit-something, Opera will in this case use webkit-something, AND I have set them to different values

    Why on earth would I set them to different values if I want to produce the same result, browser wide?

    It might be a little OTT, but I’ll happily keep specifying o-something, webkit-something and moz-something (as well as simply, “something”, if it is supported) and specify the same values across all vendors. That should then work fine, shouldn’t it?

    • http://www.optimalworks.net/ Craig Buckler

      You might need different values to produce the same effect in different browsers. For example, webkit’s first linear gradient implementation was wildly different to everyone else. However, if there was a difference, it can be solved in Opera’s implementation by defining -o properties after -webkit.

      The problem is not so much Opera’s current proposal but where this could lead. If you’re supporting a handful of webkit properties, why not support them all? Then throw in -moz, -ms and -o for good measure. The best outcome is that some properties will simply become unusable owing to implementation differences. The worst outcome is that webkit ultimately determines standards, the W3C becomes irrelevant and we end up with a single dominant browser engine. It’ll be IE6 all over again.