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.

The first is the easiest: use appropriate HTML5 input elements. It’s quite frustrating typing an email address into a text input field when the @ symbol is on a different interface view to the _ symbol, or when predictive text is enabled, and there’s really no need for it when HTML5 input types are well supported and — crucially — fully backwards compatible. So if you’re asking the user to input an email address, use:

<input type="email">

The same goes for other form fields.

The second area for improvement is slightly more complex: stop browser sniffing if you can, or stop making presumptions if you can’t. On a number of sites I get redirected to a mobile-optimised view, as I’m guessing that the browser detection script finds ‘Android’ in the UA string and presumes it’s a phone.

By far the worst culprit is Yahoo, whose UA sniffing either misidentifies or fails to identify the browser on my tablet, and serves me the most basic mobile interface. I’m using a brand new tablet with a very capable browser over a solid Wifi connection, and I’m served what is essentially a WAP site.

To add to the frustration, no link to an alternative or full site is provided, so I have no choice at all. If use about:debug and change my browser’s UA string to ‘iPad’, there’s a tablet-optimised version of Yahoo Mail that works (almost) perfectly with my device; but otherwise the UA sniffing is actively working against me.

Capability detection should always be preferable to browser UA sniffing, but if you must use UA sniffing at least keep it updated, don’t make presumptions, and provide an opt-out link to the desktop site as a basic option.

That’s it: two changes, making a much nicer experience for everyone.

In the short term I’m going take a few weeks off, and then start writing my second book (I haven’t actually signed the contract for it yet, but it’s been given the go-ahead by my publisher). I’m also working as technical editor for Chris Mills’ book, so the plan is for the money from this and other writing to support me for a bit. I’m talking at more events this year, and the extra time I get will allow me to focus on getting better at that.

Longer term I’m in very early stage planning to put together a co-operative with some friends where we can put our considerable experience to use making interesting and exciting things. That’s about as defined as we are at the moment.

Depending on how long the co-op takes to get off the ground I may be doing some freelance work later in the year, and I’m always open to hearing offers about talks, writing and consultancy, so feel free to get in touch with me about that or any other opportunity you think I might be interested in. Or just get in touch for a chat, as it’s going to be pretty lonely working by myself for the next few months!

I wish the best of luck to everyone at Top10.com, and I’m very excited and apprehensive about being unemployed for the first time since I left school!

This invention will produce forgetfulness in the minds of those who learn to use it, because they will not practice their memory. Their trust in writing, produced by external characters which are no part of themselves, will discourage the use of their own memory within them. You have invented an elixir not of memory, but of reminding; and you offer your pupils the appearance of wisdom, not true wisdom.

And misunderstanding the capabilities of computers is not a recent invention either; in the mid-19th Century the mathematician Charles Babbage, theoretical inventor of the first mechanical computer, complained:

On two occasions I have been asked,—“Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?” I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

I found both of these quotes in James Gleick’s The Information, which despite my being only four chapters in, and the fact that it’s only March, is a candidate for book of the year.

* According to Plato.

Each Fragment type is known as a Dimension, and the Temporal Dimension sets a start and end point on media which is playable, such as audio and video. For example, if you had an audio file which you wanted to play just a small piece of, you would use something like this:

<audio src="/audio.ogg#t=4,12">

The t represents time, and the two figures are values in seconds to play from and to — in this case, the section between 4 and 12 seconds. Firefox 9.0+, Safari 5.2 and Chrome have implemented this already, so if you have one of those browsers here’s a demo of the Temporal Dimension on a video file. When the page has loaded the play button starts the video at the 4s mark and ends it on 12s. Note that the user can move the timeline control around to play any portion of the video they wish.

Another use for Media Fragments is on the Spatial Dimension — that is, only displaying a portion of a media file on screen. As an example, this is how you could extend an image:

<img src="/image.png#xywh=10,10,100,40">

The xywh stands for (respectively) the x and y co-ordinates, plus height and width; in this case the portion of the image that would be displayed would be 100px wide by 40px high, starting at a point 10px from the left and 10px from the top. As I’m sure you can imagine, this could be immensely useful for image sprites. Note that by default those values are in pixels, but you can use percentages if you prefer:

<img src="/image.png#xywh=percent:10,10,20,20">

Of the other two dimensions, the first is for pulling tracks from media containers (such as the audio track of a video file) — this is the Track Dimension:

<audio src="/video.webm#track=audio">

And if the source file contains named temporal fragments you can pull those using their ID value — this is the ID Dimension:

<img src="/video.webm#id=section1">

If you’re keen to start playing around with Media Fragments, Google developer Thomas Steiner has written the mediafragments.js library which parses URLs for known Dimensions and outputs the result as JSON.

Using CSS Fonts for Adaptive Icons is the lead article, and there are two shorter tips: Making Better Print Stylesheets, and Faking Randomisation With nth-child.

What a state we’re in.

This morning Daniel Glazman, chair of the CSSWG, issued an open call for urgent action by developers to stop this situation from deteriorating any further, and hopefully to improve it: Call for Action: The open web needs you *now*. I urge you to read this, and to act on it to the best of your abilities. If browsers support other browsers’ prefixes, the whole thing collapses. As Daniel Glazman says:

Vendor prefixes have not failed. They are a bit suboptimal but they also very clearly preserved Web Authors from chaos. We can certainly make vendor prefixes work better but we can only do that if vendor prefixes remain VENDOR prefixes.

Please read his post in full, and do what you can to turn this situation around. We made the mess, we need to clean it up.

My idealistic view is that the web should work for everyone, regardless of their method of access. Idealism always takes second place to pragmatism, however; I know that we have to work within our limits, we can’t provide a first-class experience for everyone all of the time. So where do we draw the line for browser support?

The answer is the same as always: it depends.

When making the decision, you should use a Cost-Benefit Analysis (CBA). The cost includes your resources: how much time you have, how much money, the staff you have available. All of these are finite. The benefit (or lack of) is mostly to your users: not only the ones who may be excluded, but also the others who could get a reduced service if you have to divert resources to legacy support.

In 37Signals case they know their users well, they’ve done this before and obviously feel the benefits are greatly in favour of their current user base. If someone can’t get access to their website it’s not the end of the world, there are alternatives available.

But your market may be different. You may not even know your market. Telling people that they must update their browser is making a lot of presumptions about them:

• That they are aware of what a browser is. A lot of people aren’t. It’s why Google are spending millions on a global campaign (not entirely selflessly, of course).
• That they have the ability to update it — and I don’t just mean technical ability, but cognitive and physical ability too.
• That the technology they use supports updating or using alternative browsers. Many (most?) of the devices I know do, but I’m not aware of the technology markets across Africa and Asia, for example.

Most importantly, you must assess the benefit of the content — or the lack of access thereof — to the user. You could be building a site about healthcare which contains content that could save lives — literally vital information. Christian Heilmann recently posted browser stats from a healthcare site which showed that ~50% of visitors were using a browser which wouldn’t meet 37Signals’ criteria.

With all that in mind, after we’ve done the CBA I would say that the very least consideration of ours should be how easy it is to do something. I said in the discussion that “we play the cards we’re dealt” — that wasn’t intended to be a statement of passivity, but rather one of acceptance that we don’t control our users. If they use IE6, we build for them. We can educate and encourage, but only up to a point. Beyond that point we start to become arrogant.

So that’s my opinion, I look forward to hearing yours.