I’ve written an article on making sure your websites have a fighting chance of working across devices (mobiles, consoles etc).
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).
As someone who is timezone-maths challenged and forever dialling into international conference calls an hour early or an hour late, I greatly appreciated the intuitiveness of the everytimezone iPad app by Amy Hoy (idea & design) and Thomas Fuchs (development).
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!
Last Friday was our deadline and, with the spec changing all around us, Remy and I got all the chapters in for Introducing HTML5. There’s still much to do; we have to address comments made by our editor Jeff Riley, a copyeditor and our two technical editors Patrick Lauke and Robert Nyman, as well as add information about the brand-new track element.
Some people have asked for a chapter list. Here it is:
Introduction (why HTML5 exists)
Structuring a page (header, footer, nav, aside etc)
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.)
Forms
multimedia (video, audio) markup and APIs
canvas
storage
Working offline
Drag and Drop
Geolocation
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.
Other people have expressed surprise that I had never been to SxSW before (last year I had the chance to go to India so went there instead) and it was with some trepidation that I went to bring the good news about Opera, HTML5 and give the Texas ladies the chance of some hot lovin'.
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.
As I sit here in Austin, Texas munching a breakfast of bafflingly-termed foodstuffs like “eggs medium over-easy”, “white omlette” and incorrectly-pronounced tomatoes, I thought I’d update you on a few HTML5 tidbits.
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.
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.)
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.
Yikes. I remember when I used to blog at least once a week. I blame twitter. And the boss, for making me do some work.
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
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>.
Wow, That’s Cool… Fun With HTML5 Video
3:30 PM – 4:30 PM
Chris Blizzard (Mozilla), Michael Dale
HTML5 Accessibility
5:00 PM – 5.30 PM
John Foliot (Unrepentant hardliner and lovely bloke), Cynthia Shelley (Microsoft)
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.
Many developers have assumed that only Gecko and Webkit browsers will ever render CSS rounded corners or transitions, so have only specified their CSS with -moz- or -webkit- prefixes—sometimes while simultaneously berating other browsers for not supporting these properties yet. Note that Microsoft has announced that IE9 will support border-radius but if you only specify Firefox and Safari in your code, your future IE9 users won’t see those wonderful rounded corners anyway.
So, to widen the reach of your super-sexy designs, please take a minute to add the -o- prefix to your CSS transitions and transform declarations, and to add border-radius and box-shadow without vendor prefixes.
The miserable bloody English weather has conspired to give me two colds more or less back to back, so it was with only minimal trepidation that I spent 24 hours travelling by plane to Indonesia, to spend my second birthday on the trot jetlagged in Jakarta where I’m embarking on a frenzied schedule of university visits to persuade Indonesian students of the value of Web Standards.
The kindly Indonesians laid on a huge rain storm just as I landed (so the 30 celcius sun they’d been enjoying didn’t make me too culture-shocked). Cue flooding and gridlock. The 30 minute drive from the airport took two and half hours of buttock-clenching frustration—but at least it didn’t end up like that other Friday 13th.