I did a bit of a preamble at Saturday’s multipack presentation to explain my relationship with HTML 5 which isn’t in the slides, so I’m documenting it here.
I work for Opera, who are heavily involved in the specification process (along with Google, Apple, Mozilla, Microsoft, Adobe and many others). But I’m not part of the spec team in Opera, and writing or analysing specs is not part of my job or skill-set—I’m no spechead (or should that be smeghead?)
My interest is as a standards-lovin’ web developer who until recently was technical lead for a large legal website. Therefore, it’s interesting to me to try to use HTML 5 and see where it helps me and where the pitfalls are, and feed those pitfalls back to the working group before the spec is finalised.
When speaking about it at conferences, I always urge others to get involved: try it out and give feedback. If you don’t vote, you have no right to complain about the government.
But people do ask me my opinion on the politics surrounding the development of the language, so here you are.
Caveats
These are my personal opinions, not my employer’s.
I haven’t spoken about these matters on the mailing list, as I’m not nearly knowledgeable enough in these matters, so I reserve the right to change my mind in a second if someone argues convincingly. Probably repeatedly.
HTML 5 vs XHTML 2
XHTML 2 seems like a beautifully thought-out spec. But no-one has any interest in implementing it. It’s also unclear to me how it would deal with web applications.
HTML 5 is a kludge. It has to be; it tries to be backwards-compatible while hugely extending the language. Many, many aspects of it annoy me: the small element being in-line only; the revolting use of dt and dd for dialogues (see why it’s bad) and the lack of headings inside lists. But, for better or for worse, it’s the spec that has the traction and implementors behind it, so for pragmatic reasons it’s the one that I’m betting on.
Also, and most importantly, I believe that we need it fast. We need an open standard for simplifying building web apps before proprietary frameworks become the default.
Namespaces
I don’t understand the question. Way over my head. Next!
RDFa and microformats
The RDFa debate about has kicked off again on Sam Ruby’s site.
Making sure that your data is available to machine parsers so they can do something useful with it seems to me a noble goal, as long as it’s easy to do.
I had a look at the (presumably) simplest document about RDFa out there—the RDFa primer and I can’t say I came away any the wiser. The barrier to entry looks too high from where I stand. (But then I am only 5 foot 6 tall).
On the other hand, RDFa is a w3c standard, and microformats aren’t. Microformats seem to me to be easier to use but I still think that one reason they aren’t much adopted by “real people” is because they’re still too hard to code.
Perhaps a WordPress blog editor plug-in would help, and Drew McLellan wrote a nice Dreamweaver extension but, for me, if I can’t remember the syntax then it’s too hard.
I’m not in favour of bloating the HTML 5 spec and having an element for every conceivable occasion (var, kbd and samp, I’m looking at you) but I think we could usefully add a couple more microformatty elements to the language.
It seems to me that the useful microformats are based on a trinity of “who, where, when”. So I’m glad that HTML 5 has the time element (although I see no reason why authors shouldn’t be able to mark up BCE dates or dates like “July 2008” or “1935” which are currently disallowed by the spec).
I’d also like to see a place element. (Andy Mabbett proposes a location element, but I quite fancy having a geeky t-shirt reading “I’ve got the <time> if you’ve got the <place>”). It would look like this:
To complete the trinity, a name element could be used. If no attributes are present, that the name is assumed to be a single given name and single family name, so <name>Bruce Lawson</name> would be all you need, but if you want middle names, multi-part family names, nicknames, Russian patronyms etc you’d have to use attributes such as
User agents should support Ogg Theora video and Ogg Vorbis audio, as well as the Ogg container format
so browsers could display video without plug-ins and without using a patented codec (Ogg is opensource).
Nokia and Apple objected, and there is worry about “submarine patents”, so we’re very unlikely to see every browser agreeing on a patent-free codec to use in the near future, and so we’ll need horrors like nesting embed inside object inside video. Or just continue using Flash, of course (here’s a valid way to embed Flash video in HTML 5).
Sun Microsystems are developing a new patent-free codec called OMS video precisely to fill this hole.
Whether some companies with financial interests in their proprietary media formats will be willing to adopt it is unknown.
Accessibility and HTML 5
alt text
There was a lot of debate last year when HTML 5 proposed to make the alt attribute optional for some images. It was resolved by adding reams of explanatory notes to the spec, but it’s not this spec’s job to define accessibility.
I prefer the approach that Patrick Lauke suggested: the spec should say “Alt text is mandatory, but may be blank. See WCAG for guidance on writing alternate text”.
The summary attribute on tables
In HTML 4, the summary attribute “provides a summary of the table’s purpose and structure for user agents rendering to non-visual media such as speech and Braille”.
I’m not a fan of the summary attribute, having seen it misused hundreds of times in the wild in code like summary="this is a layout table".
But much more importantly, I don’t like invisible elements and think that if a table is sufficiently complex that it needs its structure explaining to a blind person, it needs its structure explaining to people using screen magnifiers, for whom part of the table may be off-screen at any given time, or for people like me who find complex tables difficult to understand.
So, unless there are useful studies that show that only blind people benefit from this kind of explanatory data and that no other users do, I have no problem with its removal from the HTML 5 spec. It would, of course, still be valid in existing sites which are (I feel safe in assuming) using the HTML 4 or XHTML 1.x DOCTYPEs.
Same with longdesc too, as no-one ever uses it and browsers don’t support it.
WAI-ARIA
ARIA should validate as HTML 5. I believe it will happen: Henri Sivonen is working on mapping the two specs.
Other accessibility worries have been resolved; Gez Lemon’s research into nested headers succeeded in adding it to the spec, and canvasmust have accurate fallback content, especially if it is mis-used to display text (the spec used to say “should”).
What’s your favourite political argument? We could talk about spec splitting, but that’s for another day.
Or, how I stopped worrying and learned to love the DOCTYPE.
I was honoured to be invited by the Multipack, a group of Birmingham-based web professionals, to the first Multipack Presents, to talk about HTML 5 as part of an afternoon of discussion of emerging standards.
Rather than another “what is HTML 5?” talk, I decided to give a talk which I wish I’d been able to hear before I began my HTML 5 redesign. I talked through the process of the redesign, the decisions I made, the blind alleys I went up and where I got confused because the spec is ambiguous or opaque.
I’d like to thank and congratulate the Multipack for organising a free Birmingham event to start building a Midlands-community that will show those Southern ponces in Brighton that you don’t need a few pebbles on a beach to have a vibrant scene. Thanks also to Birmingham web design agency One Black Bear who opened up their beautiful offices to a group of strangers and found it much fuller than anyone anticipated. Cheers to Campaign Monitor for pizza.
As is usual when a group of geeks meet up, there was beer and lewdness but also idea-swapping and inspirations.
One of my aims was to get people involved in trying HTML 5 spec and participating in its specification, as I believe if you don’t vote you have no right to complain about the government you get. A few attendees have told me that they’re going to do just that, so mission accomplished for me. For example, Andy Mabbett has been thinking about HTML 5 and microformats and has mailed the HTML 5 working group.
Next meetup is in March, but I’ll be in India. Assuming I’m back I hope to see every Midlands-based web professional at the April meetup.
I use the Web 9 to 10 hours a day, for work and for pleasure and I get highly irked by crap websites. As catharsis, this post starts an occasional series in which I document usability atrocities.
The first culprit is Waterstone’s books. I went to their website to buy Lois Lowery’s “Gathering Blue” for my daughter. I usually use Amazon for buying books, CDs and the like but this book was out of stock so I tried another retailer and Waterstones said “Availability : Usually despatched within 7-10 days”.
First usability hurdle: I had to register before I could purchase. Why any site owner would put any hurdle in the way of someone wanting to give their money to them us beyond me. Jared Spool has a brilliant post on how removing the pre-purchase registration requirement increased a site’s annual revenues by $300 Million. Any ecommerce developer or marketeer who has not read this short article should be fired.
The second usability annoyance (after the three-part registration process that wanted phone number and date of birth!) was the email from Waterstone’s telling me the super-duper advantages of being a registered user (after my enforced registration) with no unsubscribe link or unsubscription mechanism documented.
The final usability annoyance was the email from Waterstone’s thirty minutes later telling me that my book was out of stock. Why didn’t they tell me that before I made the purchase?
I hate to see book companies go to the wall, but Waterstones have a deathwish.
As you’d expect, Norway dropped a few points in the International Cool Clothing Index when I got on a plane to return to England last week, but the beautiful people of Oslo have reason again to smile.
My wife’s neice, Mary Hasavari from Trondheim and her chum Viktorija Valsø caused a sensation at the Oslo Fashion Week (Mary’s the tall girl in blue, on the left) with their Flinga Clothing collection. Congratulations to all involved.
I’ve known Molly since 2001. She was a journalist covering a Wrox XML conference I was helping run in Las Vegas. A colleague of mine, Karli Watson had a quickie, tacky Vegas wedding and Molly and I attended.
Two years later, I was searching for someone to co-author a book with me about usability, and found Molly. We were both unaware that we’d met before until halfway through our collaboration. Usability: the site speaks for itself sold poorly (and taught me some vital lessons about web developers and how they differ from programmers) but it cemented my friendship with Molly. She’s been to my house, eaten my evil chicken, charmed my children (“a real American!”) and helped me drink a bottle of vodka.
It’s great to work with old friends like Molly, Millsy and Jon Hicks, and new friends like “Zip Pin” Zi Bin, Shwetank, David-not-Dave, Andreas “Frisky” Bovens and Henny “Henry” Swan. One of the comments on Molly’s blog is “That’s some team Opera are building.” Fuck, yeah. And I’m delighted to be a part of it.
Mike “Isofarro” Davis noticed that Microsoft have quietly gone back to their original position, requiring developers to use a meta tag to opt-in to having their sites render in IE 8 standards mode, with an extra twist. There will now be a blacklist of sites that will by default be rendered in IE 7 “compatibility mode” (that is, not taking advantage of the extra standards support in IE 8.
The gist of it is if you want to be sure your site renders in standards compliant mode in IE, you have to explicitly opt into it. Otherwise you risk being blacklisted and thrown into IE7 Compatibility mode.
I fought this before I became an employee of Opera, a Microsoft competitor, and speak as a standards advocate and web developer: this is an atrocious state of affairs. Coupled with the resurrection of IE 6 as the new mobile Internet Explorer, it makes Microsoft’s claims to a Damascene conversion to standards seem very empty and insulting.
My mate David was found abandoned in a stairwell 48 years ago. He was just hours old, and was nicknamed the “Rainbow Baby” in the press because he was dressed in a white candlewick shawl, lined with green, with a yellow bear embroidered on it, and a pink cardigan with a blue Fair Isle pattern. Over him had been laid a blue flannelette blanket decorated with a pink and black lamb.
Despite police enquiries and extensive media coverage, his birth parents were never traced.
Now they’ll be getting old, and David’s hoping to trace his birth mother before it’s too late. Read his full story.
Firstly, apologies for the much-delayed second round of my HTML 5 redesign. Two things delay it:
Understanding the precise relationship between the article, section, header, nav and footer elements. What each element is for is relatively easy; how each element interacts is another. Fortunately, I work with Lachy and Anne who were able to help me.
Styling the stuff cross-browser. CSS is always a slow process for me, especially with “new” elements.
This description of headings was originally part of a post unveiling the part two redesign, but I’m splitting it out because there has been a lot of talk lately about headings in HTML 4 and 5. The redesign will be unveiled after my trip to Oslo next week.
Headings in HTML4
We all know these; there are six layers, h1 to h6. If you want more levels, you’re stuffed. There are arguments that more than six levels is somehow confusing; I think that’s an empty argument. Badly structured content is confusing, even if it has only two levels of heading. Conversely, some well-structured content might legitimately more levels and the language doesn’t allow for that.
Headings are very useful for search engines; it helps them “understand” content. They are also vital for screenreader users who can navigate via headings. In JAWS, for example, a user can hit H to go to the next heading, 1 to go to the next h1, 2 to go to the next h2 and so on. I thoroughly recommend watching Importance of HTML Headings for Accessibility, a video by a blind web developer who shows how screenreader users navigate using headings.
Opinions are divided about whether accessibility is better served by never having more than one h1 per page, whether “skipping” a level (from h2 to h4 with no intervening h3, for example) for consistency’s sake helps or hinders are all arguments that Henny Swan excellently summarises, so please comment there on those questions.
The problem with “hardcoded” headings is that they are hardcoded and can’t change according to context. The title of this whole blog post is presented by WordPress as a h2 on the home page, but as an h3 on a category page (as there is an h2 there saying “all posts in the HTML 5 category"). But the internal headings aren’t controlled by WordPress; I’m hardcoding them as h3. Unfortunately, they therefore remain at that level on the category pages, thereby destroying the hierarchy of headings.
Headings in XHTML 2
XHTML 2 has an elegant solution to this problem, and proposes an all-purpose h element as a general purpose heading. It gets its position in the hierarchy from how many levels of section elements wrap it.
Structured headings use the single h element, in combination with the section element to indicate the structure of the document, and the nesting of the sections indicates the importance of the heading. The heading for the section is the one that is a child of the section element.
So <body><section><h>Heading</h></section> is the same as an h1, and styleable with a CSS rule like section h {color:red;}.
<body><section><section><h>Heading</h></section></section> is the same as an h2, and styleable with a CSS rule like section section h {color:green;}.
Content Management systems can therefore take a lump of content (like this article) and wrap it in a section element and change the level of all the headings.
Headings in HTML 5
HTML 5 attempts to be backwards compatible, so it uses XHTML 2’s section element with the numbered headings from HTML 4 so that legacy content still works. That means that determining the “level” of any header is dependant on its explicit number (is it h1 or h-something else?) and how many levels of section surround it.
The algorithm is complex but tightly defined. My section demo page gives an idea of how this works, as well as styling examples. James Graham has written an outlining tool and I expect that tools such as Opera Dragonfly and Firebug will provide methods to work out "computed" levels of heading.
So in my redesign, I’m wrapping each article in a section element on a "category" page so that the hard-coded h3s ‘turn into’ h4s, which is a fine and dandy way to deal with this legacy content.
Accessibility
Current browsers don’t magically rejig the levels of headings, of course, as they have no knowledge of the section element, so just read that heading as the hard-coded h3. Those using screenreaders are not worse off and I’m future-proofing the document.
Sections may contain headers of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section’s nesting level.
Authors are also encouraged to explicitly wrap sections in elements of sectioning content, instead of relying on the implicit sections generated by having multiple heading in one element of sectioning content.
(This “discouraging” in a spec seems to me a disingenuous way of indicating that there is a kind of “HTML 5 transitional” spec wrapped up in the main spec. The code structures that are "discouraged" are very useful for transitioning legacy content, and the spec should say so in my opinion rather than daintily "discouraging".)
This says that authors of new content should really only use h1 for headings, and when they want sub-headings should do so by making another section. That’s all well and good, but what about screenreaders?
Current screenreaders would just see every heading on the page as a hard-coded h1, which destroys the ability to get a conceptual framework of the page or navigate it. In order to take advantage of the new HTML 5 way of computing the relative level of headings, screenreaders would need to incorporate the outlining algorithm. This isn’t too much to ask; they are user agents that consume and transform web content; the algorithm is open and published.
Let me put my cards on the table: if you correctly use a W3C specification, like this one, and obey WCAG, then I believe that your responsibility as a web author is done. I won’t delay using a technique because a user agent can’t deal with it (although I will try to give extra help where I can). Call me evil, but that’s how I feel today.
I’ve been worried enough to ask the HTML 5 top nobs to explicitly invite the main screenreader vendors to participate in the the development of the HTML 5 spec. Unfortunately, to my knowledge, we’ve seen no interest from them. Perhaps they don’t think their customers are interested; after all, they don’t even alert their users to HTML 4 elements like strong, em, b, i or del.