Trying out my new Ranting Hat, a present from Japan from Nedjma. Please note that rants are just that, and not necessarily eloquent or factual. (And I know that Eric Meyer and Jeffrey Zeldman are not the only two social liberals in the USA; I’ve actually met the other three.)
Oh, and do I have to say that this is a joke, is personal and nothing to do with my lovely employers at Opera? Unfortunately, I probably do.
(I’ll transcribe it when I’m not so tired)
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).
So now it’s called Mobile-friendly: The mobile web optimization guide. Enjoy.
There seems to be confusion about the minimal set of elements that make a valid HTML5 page.
(Amended on prompting from Tab Atkins and Mathias Bynens in comments below.)
The simplest valid document is
<!doctype html>
The title element is required in most situations, but when a higher-level protocol provides title information, e.g. in the Subject line of an e-mail when HTML is used as an e-mail authoring format, the title element can be omitted.
Assuming you’re writing a web page rather than an HTML email, you need the title element, although technically it can be blank.
<!doctype html>
<title></title>
However, you shouldn’t do that. Failure to specify a character encoding which can introduce an obscure but real security vulnerability. So, the simplest valid and secure document looks like this:
<!doctype html>
<meta charset=utf-8>
<title>blah</title>
<p>I'm the content
(You don’t actually need the content, of course, but it’s a pretty rubbish web page without it, and an empty title isn’t much good.)
However, for accessibility reasons, you should declare the natural language of the document (English/ French/ Swahili) on the html element, which therefore means you need that element (note that you don’t need to close it, though):
<!doctype html>
<html lang=en>
<meta charset=utf-8>
<title>blah</title>
<p>I'm the content
If you’re planning to use AppCache to enable offline applications, you’ll need the html element as the manifest attribute goes there.
Internet Explorer 9 Developer Preview 3 and its antecedents can’t apply CSS to new HTML5 elements without a body element. (Try it without body and with body.)
So if you’re attempting to do that, the smallest valid, secure, screenreader-accessible and stylable-in-IE HTML5 page you can have is
<!doctype html>
<html lang=en>
<meta charset=utf-8>
<title>blah</title>
<body>
<p>I'm the content
Just because you can do this doesn’t mean you should, of course. Depending on your colleagues, it could be confusing and thus a maintainability nightmare.
I use the head element, and close those tags that need closing (although I don’t bother with trailing slashes on self-closing elements).
So the minimal valid, secure, screenreader-accessible and stylable-in-IE HTML5 page (not email) that it easily readable and maintainable (subjective, of course) is probably
<!doctype html>
<html lang=en>
<head>
<meta charset=utf-8>
<title>blah</title>
</head>
<body>
<p>I'm the content</p>
</body>
</html>
Enjoy.
(PS, I co-wrote a book!)
I got home to find my author copies of Introducing HTML5 had arrived, straight from the printer in the US. They’ll be on the shelves in a week or so.
Rather than engaging in weird “unboxing” photosets on Flickr, I decided to celebrate this joyous occasion in a different way.
(Images may be NSFW if you work a very prudish environment or are a nun.)
In the pub after presenting on HTML5 at London Geek Night last week, a bloke (Andy?) gave the best description I’ve heard yet of HTML <article>.
Don’t think of article as a newpaper article. Think of it like article of clothing: any discrete item.
It’s not just about newspapers or blogs. So, on amazon, a single product on a product listing page would be an <article>. An individual email in a web-based email app would be an <article> Individual tweets on a twitter client would be <article>.
Last night, Remy Sharp and I did our first ever co-presentation about HTML5 for London Geek Night (and thanks to the organisers: we had a blast. Beer in the fridge for all—that rocks!). For the second time this week, I heard the misconception that the Flash Player will support unencumbered WebM video.
Adobe has announced that it will support the VP8 video codec. WebM, however, is an umbrella term that means VP8 video, with Vorbis audio (the one that Spotify uses, and which is supported by Opera, Firefox and Chrome) packaged up in a profile of the Matroska container format (MKV).
As far as I can tell, from Adobe’s Matt Rozen’s blogpost Flash Player Will Support VP8, there is not yet planned support for Vorbis or MKV:
Can Flash play .ogg audio like it plays .mp3 now?
We carefully consider the technologies we add to the Flash Player runtime based on customer needs. We haven’t announced support for other codecs at this time.
It’s great that Adobe will support VP8. But we shouldn’t yet assume that we can let browsers that don’t natively support unencumbered WebM fall back to the Flash Player.
I’d love it if an Adobean would comment and clarify the situation, as that blogpost is from May 24 so there might be newer information that I haven’t seen.
(There’s a similar situation with IE9. IE9 will support VP8 if the codec is previously installed on the machine—that is, it’s not inside IE9 out-of-the-box. But note this is VP8, with no mention of WebM. However, as Microsoft already uses Vorbis for the audio in Microsoft Halo, we can assume that they have no ideological problem with the audio format).
Opera 10.60 is the first shipping browser with WebM support; Firefox and Chrome have committed to support and have it built into nightlies.
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 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!
Don’t tell the publisher, but I’ve posted PDFs of Introducing HTML5‘s contents (34K) and Index (84K) so you can see what’s in it. (It’s £13 for preorder from amazon, hint hint.)
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.
(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
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:
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.
