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.
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
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.
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 (
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:
<place latitude="52.548" longitude="-1.932">Great Barr</place>
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
<name given-name="Bruce" middle-name="Agamemnon" family-name="Lawson">Bruce Agamemnon Lawson</name>
<name given-name="Bruce" patronym="Brucemov" family-name="Lawsonski">Bruce Brucemov Lawsonski</name>
<name given-name="Bruce" family-name="Van der Growl">Bruce Van der Growl</name>
<name given-name="Bruce Il" family-name="Kim">Kim Bruce Il</name>
<name given-name="Bruce" nickname="Awesome" family-name="Lawson">Bruce "Awesome" Lawson</name>
It’ll never happen, but it’s what I’d like.
The spec used to say
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
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”.
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.
longdesc too, as no-one ever uses it and browsers don’t support it.
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
canvas must 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.