Archive for June, 2010

Making iPad app work cross-browser

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).

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 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 Updated on 7 July 2010)

Thankyous for Introducing HTML5

As our book Introducing HTML5 goes to print, closing 6 months of writing, re-writing, re-re-rewriting as the spec changed around us, here are my acknowledgments (so damn many that I sound like some blubbing actress accepting an Oscar):

Mega-thanks to co-author-turned-friend Remy Sharp, and friend turned-ruthless-tech-editor Patrick Lauke: il miglior fabbro. Thanks to the Opera Developer Relations Team, particularly the editor of, Chris Mills, for allowing me to re-use some materials I wrote for him, Daniel Davis for his description of ruby, Shwetank Dixit for checking some drafts and David Storey for being so knowledgeable about Web Standards and generously sharing that knowledge. Big shout to former team member Henny Swan for her support and lemon cake. Elsewhere in Opera, the specification team of James Graham, Lachlan Hunt, Philip Jägenstedt, Anne van Kesteren, and Simon Pieters checked chapters and answered 45,763 daft questions with good humour. Nothing in this book is the opinion of Opera Software ASA.

Ian Hickson has also answered many a question, and my fellow HTML5 doctors ( have provided much insight and support.

Thanks to Gez Lemon and mighty Steve Faulkner for advice on WAI-ARIA. Thanks to Denis Boudreau, Adrian Higginbotham, Pratik Patel, Gregory J Rosmaita, and Léonie Watson for screenreader advice.

Terence Eden took the BlackBerry screenshots in Chapter 3, Ross Bruniges let me use a screenshot of his site in Chapter 1 and Jake Smith provided valuable feedback on early drafts of my chapters.

Thanks to Stuart Langridge for drinkage, immoral support and suggesting the working title “HTML5 Utopia. Mr Last Week’s creative vituperation provided loadsalaffs. Thanks, whoever you are.

Thanks to John Allsopp, Tantek Çelik, John Foliot, Jeremy Keith, Matt May and Eric Meyer for conversations about the future of markup.

Lastly, but most importantly, thanks to thousands of students, conference attendees and Twitter followers for their questions and feedback.

This book is in memory of my grandmother, Marjorie Whitehead, 8 March 191728 April 2010, and dedicated to Nongyaw, Marina and James, without whom life would be monochrome.

(Last Updated on 8 July 2010)

IE and HTML5 testing

In the 18 months I’ve really focussed on HTML5, I’ve seen approximately 238 different HTML5 “testing” sites appear. Most of them wildly pick and mix specs, checking for HTML5, related WHATWG-derived specifications such as Web Workers and then, drunk and giddy with buzzwords, throw in SVG, CORS, CSS Media Queries, and some Apple proprietary CSS extension before hyperventilating and going to bed for a lie down.

(Added 4 June 2010: As a case in point, take Apple’s hilariously disingenous “HTML5” showcases, of which only the video and audio demos have anything to do with HTML5, and which offer “browser upgrade” messages even to other WebKit browsers (screenshot courtesy of Peter Nelson). And don’t get me started on “Standards aren’t add-ons to the web. They are the web” coupled with browser-sniffing and proprietary vendor extensions.)

As an analogy, imagine that HTML5 is the Starship Enterprise to HTML 4’s pogostick. Imagining it? Good.

237 HTML5 testing sites check for

  • Does it do most pogostick functions?
  • Does it do Starship Enterprise things, too?
  • Oh! what about Millenium Falcon functionality?
  • Wow! can it also behave like a spacehopper?
  • OMG!?! And what about CSS 4D Canvas Gradient Transforms™?

Therefore, it’s particularly refreshing to see the new Microsoft IE9 HTML5 Testing Centre bringing some sanity to the party. None of the scope-creep for our friends in Microsoft. It’s purely HTML5, and only selected bits so we can’t even speculate about thinking about considering accusing them of scope-creep.

So they avoid any mention of fripperies like canvas (who uses that?) or native multimedia (who’s even heard of that?). Why would any web developer care about Web Forms?

Instead, we look only at The text selection APIs, parsing foreign content and getElementsByClassName to determine that IE9 has the best HTML5 support.

To return to our analogy, the Microsoft test to detect Starship Enterprises is:

  • Is the colour of the grouting in the shower cubicles exactly Pantone 7401 C?
  • Are the menus in the staff canteen printed on 180 gsm matt card?
  • Is the main power cable to the transporter room secured to the wall with cable grips at precisely 10 centimeter intervals?

Yes to all? Wow! It’s the Starship Enterprise!

Actually, it’s HTML5, Jim, but not as we know it.

(Related: What HTML5 is and isn’t, an IE9 speed comparison.)

Caveat: Yeah, I’m having a chuckle. This does not represent the position of my employer. I wrote it outside company time. On a different computer. With a different personality. So chill out, it’s a sunny day.

Writing cross-browser, future-proof CSS 3

Here’s a quick tutorial (actually, rant) that came out of an aside I mentioned when doing my talk for Future of Web Design two weeks ago.

It came about when I was using the IE9 preview to test some sites. I noticed that a site that boasts rounded corners didn’t appear to have them in IE9, even though IE9 allegedly has border-radius support.

“Silly IE9”, I thought.

Wrong. Silly developer.

The difference between a pro developer and a wannabe is that the pro developer makes sites that are cross-browser and, as far as possible, future-proof. By contrast, the wannabe assumes that everyone is the same as him and therefore if the site works on the browsers he uses, that’s enough.

Our wannabe developer’s code looked like this

-moz-border-radius: 6px;
-webkit-border-radius: 6px;

By using only vendor prefixes, the wannabe developer ensures that this nice part of the design will only work on those browsers.

A pro, however, cares about his client so doesn’t leave them with a site that will need changing later. A pro cares enough about his site’s users to give the design to their browser and let it do with it as it will.


Simply by adding the non-prefixed cross-browser version of the property, he can add border-radius support for IE9 now, Opera now and any new browser that comes along in the future:

-moz-border-radius: 6px;
-webkit-border-radius: 6px;
border-radius: 6px;

In the above example, border-radius is pretty mature, so IE and Opera jumped straight to using the standard prefix-less property, but other fancy CSS 3 properties are implemented only with vendor prefixes at the moment. Note I said “at the moment”; in two years’ time, a new browser may consider that feature stable enough to implement without a vendor prefix and, because you’re a pro rather than a wannabe, you want to ensure your code works in 2 years time as well as today.

For maximum compatibility, I advise adding all vendor prefixes (I do it in alphabetical order to help me remember) plus the non-prefixed version.

So here’s a version that future-proofs and cross-browserifies™ CSS3 transforms:

-moz-transform: scale(1.6);
-ms-transform: scale(1.6);
-o-transform: scale(1.6);
-webkit-transform: scale(1.6);
transform: scale(1.6);

If, for example, IE adds support for the prefixless version, or uses the -webkit- version, you have one line—27 bytes—of redundancy. So what? And now your code works everywhere that has support, today and tomorrow.

And that’s how it should be.

I feel very strongly that using JavaScript to remove all that extra CSS away is a bad idea. Apart from the absurdity of using “20kb minified js to avoid 5kb ‘untidy’ CSS” (as one person commented about eCSStender), it’s ducking responsibility. If you as a developer choose to use experimental, pre-standardised code on a production site, then you need to live with the consequence of that choice. There’s no getting around it: experimental, pre-standardised code is susceptible to change. If the specification changes, you’ll need to change your CSS (which is easier to do if it isn’t being hidden away by some library).

See -o- vendor prefixed CSS supported in Opera 10.50, also Vendor-prefixed CSS Property Overview which compares vendor prefixes across browsers.


(Added Nov 2011)

(Last Updated on 4 November 2011)