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).
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!
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 dev.opera.com, 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 (www.html5doctor.com) 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 http://www.thecssdiv.co.uk/ 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 1917–28 April 2010, and dedicated to Nongyaw, Marina and James, without whom life would be monochrome.
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.
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?
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.
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.
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:
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:
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.