As part of .Net magazine’s Responsive Week, I’ve updated an article by Denise Jacobs to now bring you 50 fantastic tools for responsive web design.
On Opera’s Implementation of WebKit Aliases
As I’m sure you’re aware, Opera recently released a preview build of their browser Mobile Emulator which is notable largely because they’ve aliased a group of –webkit– prefixed properties, effectively supporting another vendors supposedly proprietary code in their own.
Let me state upfront that I understand why this decision has been made. I don’t agree with it, but I understand it. Opera have a large worldwide audience in the mobile space — to understand how large, take a look at this graphic showing top mobile browsers worldwide last month (if you’ve ever said ‘no-one uses Opera anyway’, put on a dunce cap; if you’ve recently said ‘Opera are breaking the web, but no-one uses it anyway’, pull your head out of your arse before putting on the dunce cap).
With the rise of iOS and Android and mobile WebKit, a lot of developers who can’t see outside their wealthy Western tech bubble are building sites that are optimised for WebKit and don’t degrade properly or, even worse, use –webkit– prefixed properties to actively exclude other browsers. This has also been raised as an issue by Microsoft and Mozilla, who are trying to make headway in the mobile space, but it’s Opera with their huge worldwide userbase who are bearing the brunt; their millions of users are seeing websites that don’t work, and blaming Opera for the problem.
So my issue is not so much with the fact that Opera have done this, but with the properties they’ve chosen. The properties in question are:
–webkit-border-radius–webkit-box-shadow–webkit-linear-gradient–webkit-transform–webkit-transition
Of these, –webkit-transition is obvious; some people have written scripts which use the webkitTransitionEnd event as a dependency, so if Opera want these scripts to work, they have to support it. –webkit-transform is straightforward too; if it’s being used for page animations (like sliding between panels), it also has to be supported. –webkit-linear-gradient I can understand although it’s less convincing; the example they’ve used is where a gradient has been used without provision of a fallback background-color, which is no doubt a problem but one which must affect IE users too, and I can’t say I’ve heard of any widespread reporting of that.
I can’t justify their use of –webkit-box-shadow and –webkit-border-radius. For a start, both have been unprefixed by WebKit for a little while now — nine months in the case of box-shadow, 21 in the case of border-radius — but even presuming a lot of legacy use, neither of these properties introduces critical dependencies; seeing squared corners or no drop shadow can hardly be classed as ‘broken’. I know Christian Heilmann has highlighted a case where –webkit-box-shadow has been used as criteria for testing CSS3 support in browsers, but that can’t be a common case, and would be better served by getting in touch with the site owner and explaining the problem.
Apparently the decisions about which properties to alias were based on frequency of misuse along with some judgement, but I think that not all of these properties have been properly justified for inclusion by the Opera team — certainly in the cases of box-shadow and border-radius. These to me smack of opportunism: ‘we’re going to have to support some properties, so while we’re at it let’s also add a couple of more visibly blingy ones’. If that’s not correct, I’d love to see more examples of lack of rounded corners and shadows being flagged as an issue.
Microsoft have said that they don’t intend to follow Opera’s lead, and Mozilla are yet to declare their intentions (last update was that it’s ‘very likely’ they’ll do the same) but don’t seem to view the problem on the same scale as Opera — remember, though, that the former two are in a very different situation to the latter. I hope that, as has been indicated, this is an event that Opera won’t be repeating in the future, that it’s a one-off solution to a problem that would be better off resolved in a different way.
My position is still that this is a problem largely caused by developers and one that should be resolved by them; it’s as easy as testing your websites in Opera Mobile Emulator or Firefox Mobile for Desktop before releasing them. And if you’re someone who’s criticised Opera for making this move but you haven’t taken the time to update your own websites to make sure they work in Opera, you’re part of the problem.