It’s for web designers used to making desktop sites, rather than for people designing iThing apps.

The article was originally called “The ultimate guide to mobile optimisation” but the boss rightly said no (you could write a book about the subject, but all the main points are introduced in the article).

So now it’s called Mobile-friendly: The mobile web optimization guide. Enjoy.

The accompanying blog post Making an iPad HTML5 App & making it really fast said “desktop browsers work, too!” but it didn’t work in Opera.

David Storey, Patrick Lauke and I set about exploring why. The answer was simple: browser-sniffing. The app was only looking for browsers with the strings “webkit” or “Gecko” in the user agent string, and only feeding those browsers the necessary code. So we copied the code and, as a proof of concept, added “opera” to the list of strings being sniffed, and made trivial amends to the JavaScript to send -o- prefixed styles.

Additionally, the main CSS was only using -webkit-border-radius and -moz-border-radius, while Opera and IE9 use the naked property name border-radius. (See my Writing cross-browser, future-proof CSS 3 for more on this.)

Adding this to our proof of concept made the application work in Opera. There are differences; Opera doesn’t support CSS Gradients so those don’t show (although an SVG gradient as a CSS background-image would work perfectly well) and a bug means it doesn’t pick up the Futura font. But visual differences are to be expected on the Web; it’s the content that’s king (or, in the case of an application, the functionality).

We sent this to Thomas, and very sportingly he made the code live, so now everytimezone.com works in Opera too. The moral is that it’s pretty easy to make your sites work across all modern browsers and, while you might expect the user to be coming from one specific device, if your app is on the Web (rather than a W3C Widget or some proprietary format like Apple app store) you can expect visitors using other devices, browsers and operating systems.

Of course, it won’t work in IE9, even though it was announced yesterday that IE9 will support canvas, as the browser-sniffing locks out all versions of IE, past and future. That’s the downside to browser-sniffing: it’s completely non-futureproof. If you make a deliberate policy to block a browser, and a future version of that browser is capable of supporting your code, you have to go back and amend your blocking code. If you have hundreds of sites in your portfolio, that’s a massive commitment.

So congratulations s to Thomas and Amy for a lovely little app; I can now dial into conference calls with confidence and punctuality!

Some people have asked for a chapter list. Here it is:

1. Introduction (why HTML5 exists)
2. Structuring a page (header, footer, nav, aside etc)
3. Marking up a blog (the outlining algorithm, other new elements, what’s removed, what’s changed, WAI-ARIA, case-study of HTML5ifying The Guardian homepage. This chapter is a monster so we may split it into two.)
4. Forms
5. multimedia (video, audio) markup and APIs
6. canvas
7. storage
8. Working offline
9. Drag and Drop
10. Geolocation
11. messages, web workers, web sockets

From the introduction:

Who’s this book for?

No knowledge of HTML5 is assumed, but we expect you’re an experienced (X)HTML author, familiar with the concepts of semantic markup. It doesn’t matter whether you’re more familiar with HTML or XHTML doctypes, but you should be happy coding in any kind of strict markup. While you don’t need to be a JavaScript ninja, you should have an understanding of the increasingly important role it plays in modern web development, and terms like DOM and API won’t make you drop this book in terror and run away.

What this book isn’t

This book is not a reference book. We don’t go through each element or API in a linear fashion, discussing each fully and then moving on. The specification does that job in mind-numbing, tear-jerking, but absolutely essential detail. What the specification doesn’t try to do is teach how to use each element or API or how they work in the context of each other. We’ll build up examples, discussing new topics as we go, and return to them later when there are new things to note.

You’ll also realise, from the title and the fact that you’re comfortably holding this book without requiring a forklift, that this book is not comprehensive. Explaining a specification that needs 900 pages to print (by comparison, the first HTML spec was three pages long) in a medium-sized book would require Tardis-like technology—which would be cool—or microscopic fonts—which wouldn’t.

The publishers are intransigent about page-count, so there’s lots that we can’t put in (but we cover the important things that are being implemented today). There also wasn’t room for “sexy photos of the authors looking dreamy lying on fluffy shag pile animal pelts, 70s style” that one HTML5 Doctor requested, although we may have a contest in which the lucky winner gets 2 hours in which to take such photographs.

I very much liked Austin - or "Steve" as I like to call it - and it's become my new favourite American city; I used to like San Francisco but against Steve, it feels a bit like Brighton - too self-consciously cool to be relaxing.

I didn't see many talks as I had to be a boothbunny, but (to be brutally honest) I wasn't terribly impressed with those I did make it to. The panel format seemed a bit like paying to watch at a circlejerk, with everyone agreeing and congratulating each other, although I was impressed with some. The parties were not my thing either; I'm decades past queuing for an hour for a chance to shout at people you want to talk to (bah humbug get off my lawn). The free drinks in the lobby of my hotel every evening was far more conducive to chatting, sharing a laptop and doing the things I like to do with interesting people.

Fortunately, the "interactive workshop" I presented (which was actually a traditional presentation; there's no workshop potential with 400+ people in a room) was on Sunday so I had a couple of days to relax afterwards. (Slides are available for your downloading pleasure). It was a full house, with some great feedback ("Bruce Lawson is like an open-source Steve Jobs") - thanks all! Special thanks to Martin Kliehm for inviting me to take part in the 3 hour extravaganza he curated.

One of the highlights was talking to real customers on the booth. Many challenged our "fastest browser" claim, and went away pleasantly surprised when they found their own sites rendering so speedily. It was also great to blow the "Opera has a bad UI" bullshit out of the water.

The other highlight was meeting so many people that I know on the Web, but rarely meet in real life—people like the unrepentant hardliner, John Foliot, baby-eating Matt May and lovely people who I'd never actually met before, like Allan Kent (on-line friend since 2003), Jared Smith of WebAim and the best-dressed lady in Web, Nimbupani.

That nice Dan Oliver from .net magazine did an interview with me:

I got to eat a burger (Whataburger!) for breakfast, hang in the Media Temple VIP room, wear a Mexican wrestling mask and a glittery camisole. There are a few photos, fewer memories and, apart from liver made of paté and terminal jetlag, I survived my first South By SouthWest.

The first is the news that Google will start indexing content marked up using microdata. No browser does anything with data it finds in pages, but the voodoo magicians that do SEO will presumably find the chance of extra googlejuice compelling.

You can have a play using @foolip‘s JavaScript microdata implementation (work in progress; the lad has other things on his mind). I was chatting to Tantek Çelik last night, and he said he’s looking to add some microdata support in microformats.

I’m a lurking member of two W3C subgroups that work on the accessibility of video and canvas. We recently had two internal votes. The first was on what type of captioning format should be supported, and asked us to choose between the .srt format (a plain text file with time markers and text) or the W3C standard DXFP which, although minging, allows markup. (.srt seems to me to be as limited alt text on an image; it can’t contain markup or styling information). I voted for DFXP because, at its most basic it doesn’t need to be more complex than plain .srt, but has the potential for extensibility when browser implementations become more sophisticated. (My vote was a personal opinion and not an official Opera vote, by the way.)

The second vote that’s taking place is about extensions to canvas. There are two main proposals, one is for a new attribute called adom (for “accessibility DOM”) that constructs a “shadow DOM” for assistive technologies can hook into – and which the author must ensure is in sync with the visual rendering. I’m uncomfortable with this proposal for reasons that I’m not quite able to articulate at the moment (but its author is at South By Southwest so I hope to be able to catch up with him for a chat).

The proposal that I like is to extend canvas is “Improve image maps, don’t use @adom” which I favour because it uses familiar markup and reuses ideas from (and browser implementations of) HTML4. (Disclosure: the proposal was made by Chaals, Head of Standards at Opera, but that’s not why I prefer it.)

The Mighty Steve Faulkner also has a proposal Provide accessibility implementation for focus rectangle and caret, which I haven’t read yet. But it’s Steve, and his shit is solid.

Anyway, gotta go and shower my pits before booth-bunnying the Opera South By Southwest booth. It’s in row 300 of exhibition room 4. Why not stop by a chat, especially if you’re a gorgeous Web Standards babe, or have a black coffee for me? Alternatively, I’m first speaker at an HTML5 extravaganza on Sunday from 2 to 6 pm.

Anyway, if you’re headed over to South By Southwest next week, and fancy learning about HTML5 on Sunday afternoon, please pop along for a three hour workshop with me and some lovely friends from the world of accessibility, Mozilla and Microsoft in Ballroom F (this is a rom change to one double the capacity of the origianal venue – gulp!).

The running order is

1. HTML5: Tales from the Development Trenches

   2:00 PM – 3:00 PM

   Me ‘n’ Martin Kliehm. An overview of how HTML5 came to be, why we need it, what it can do: new structural elements, intelligent forms, scriptable images with <canvas> and a brief introduction to <video>.

2. Wow, That’s Cool… Fun With HTML5 Video

   3:30 PM – 4:30 PM

   Chris Blizzard (Mozilla), Michael Dale

3. HTML5 Accessibility

   5:00 PM – 5.30 PM

   John Foliot (Unrepentant hardliner and lovely bloke), Cynthia Shelley (Microsoft)

4. Panel Q&A

   5:30 PM – 6:00 PM

   Ensemble

Why not add them to your schedule?

I ain’t never been to South By Southwest but everyone done told me that it’s awesome to the max (I’m a-larnin’ to speak American – yee har!). I don’t know much about Texas; is it the law that you must wear a JR Ewing stetson?

If you can’t make the talks, hopefully I’ll see you at the Opera booth and get a chance to love you up like the gorgeous canoodlebot that everyone tells me you are.

See you there?