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.
Craig BucklerCraig is a freelance UK web consultant who built his first page for IE2.0 in 1995. Since that time he's been advocating standards, accessibility, and best-practice HTML5 techniques. He's created enterprise specifications, websites and online applications for companies and organisations including the UK Parliament, the European Parliament, the Department of Energy & Climate Change, Microsoft, and more. He's written more than 1,000 articles for SitePoint and you can find him @craigbuckler.
