OK, so it’s not quite a millenium but the flame wars, bitch fests on the mailing list make it feel that way.
According to the W3C‘s RDFa primer, it is “a few simple XHTML attributes … [to] mark up human-readable data with machine-readable indicators for browsers and other programs to interpret. A web page can include markup for items as simple as the title of an article, or as complex as a user’s complete social network.”
HTML 5 had the temerity not to care about the RDFa for three reasons (as far as I can tell):
- It’s too hard for most markup monkeys to code
- It requires XML namespaces and HTML 5 doesn’t do namespaces
- If you copy and paste RDFa annotations, it won’t work in the destination page unless you also copy the RDFa definitions, which can be separated in the code.
So instead, HTML 5 introduces microdata which does the same thing in a different way. To some, this has caused grave anguish. Shelley Powers is anguished because it competes with RDFa, Ian Hickson wrote it on his own, the HTML 5 spec is too big already and microdata isn’t as “good” as RDFa.
Jeni Tennison seems unanguished. While microdata isn’t as good as RDFa, she acknowledges, it’s easier to use.
Meanwhile, Philip Jägenstedt (who implements
- Microformats, you’re a class attribute kludge
- RDFa, HTML is not your triplestore
- Microdata, I like you but you need more review
Anyway, this crazy mindset of Philip’s in which things are tested and the best one wins regardless of ideology seems to have infected others. Ian Hickson writes
I am going to try some tweaks to the Microdata syntax. Google has kindly offered to provide usability testing resources so that we can try a variety of different syntaxes and see which one is easiest for authors to understand.
As someone only tangentally concerned with machine-parsable data (I’ve used one microformat in my life, once) I’d love to see the three options compared by someone like Tantek, Jeremy Keith or Ben Ward. (Wish granted in Ben’s comment.)
Summary lovin’ had me a-blast
The decision to deprecate the
summary attribute of
table caused what we lucky denizens of W3C Working Groups officially term a right shitstorm.
From a barely-used accessibility add-on, it became a talisman whereby the mature accessibility experts with real experience beat up the juvenile upstarts who are all clever ideas and no practical knowledge, while the brave young pioneers with the courage to boldly forge new paths attacked the silly old farts who are afraid of change.
It’s settled down now, with
summary remaining in the spec but advised against (a sensible compromise, in my opinion; I think
summary is superfluous).
A highly condensed partisan history of Oh, those summary nights is available from Google’s Mark Pilgrim, who memorably did his bit for inter-generational bonding by calling some accessibility practioners “charlatans and fools”.
This is vital work. ARIA is a bolt-on spec that extends HTML 4 to cover the accessibility of Web Applications, which stretch HTML 4 to breaking point because it was designed for static documents, not apps.
That stretch is one reason that HTML 5 was invented; its original name was “Web Applications 1.0”. Because HTML 5 is a new spec, it’s better to have accessibility built-in rather than bolted-on.
Also, the ARIA spec is complex and puts a lot of work on the developer, so it’s in everyone’s interests that ARIA be folded into HTML 5’s existing structures as far as possible.
Fortunately (and surprisingly, given the
summary fracas) no-one seems to be disagreeing on the need for the HTML 5/ ARIA integration process which appears to be going smoothly and without horses’ heads being left in beds.
canvas is the immediate drawing mode available in HTML 5. It’s fast, and therefore sexy, because it doesn’t have a “DOM”, but which means there is nothing for assistive technologies to hook into.
Some have suggested that
canvas be removed from the main spec, but that would make little difference except to confuse authors who already have too many specs to cross-reference.
Because the spec retrospectively codified what was already working in the browsers, we just have to accept that those implementations are inaccessible for now and not use
canvas where a more accessible method exists.
However, the first part step towards solving a problem is acknowledging that there is a problem, and it’s acknowledged that the original use-cases anticipated for
canvas don’t match what people are trying to do now (further discussion of this in my standards suck video interview).
I know that cabal member and fellow Operative Lachlan Hunt has been investigating how my old chum Bob Regan of Adobe went about retrofitting Flash for accessibility, way back in version 5. That’s a promising sign.
Chris Wilson of Microsoft resigned as co-chair, and two people replace him: Maciej Stachowiak of Apple, a cabal member through and through, and Paul Cotton of Microsoft. I don’t know Paul, but it’s good to see Microsoft continuing its involvement, and certainly we’re seeing lots of specific feedback from Internet Explorer Program Manager Adrian Bateman.
Zeldman and a group of celebs including Eric Meyer, Tantek Çelik, Dan Cederholm adopted the moniker HTML5 Super Friends and endorsed the direction the spec’s going, thereby immediately making it primetime.
They have a useful list of concerns. Regular readers (hello Mum!) may recall that I’ve previously submitted concrete proposals to the Working Group about the content model for
small, the problem of
legend in new elements, and the unnecessary restrictions to the
time element, so I’ll not reprise those, but here are my thoughts on the Super Friends’ hiccups.
I agree that
hgroup is clumsy and likely to be misused. Rather than wrap an
h1 and its
h2 subtitle in
hgroup to keep the subtitle out of the outlining algorithm, I would prefer to use
<subtitle>My wit and wisdom</subtitle>
as I think that’s easier to understand than a heading-that’s-not-a-heading, and it removes a wrapping element.
footer content model
I agree that it’s daft that you can have
nav, headings and
sections in a
header but not a
footer, and this contradicts what many people already do—see Webcamp BKK for an example taken at random from HTML5gallery.com.
Update 4 September: and, lo!, it is done:
Contexts in which this element may be used: Flow content, but with no
I’ve said before that
That better option is no longer available in HTML 5 which unnecessarily restricts the
cite element to only marking up the title of a work (in HTML 4 you can use it to mark up a name).
In my opinion, the HTML 5 spec is overly restrictive, as I’d like to continue using the
cite pattern, as
dialog has no mechanism for marking up stage directions such as “Exit, pursued by a bear“.
Frankly, I’m not even certain that
dialog merits its own element. If no-one is convinced that marking up ancient or fuzzy dates has a use-case, what is the use case for
dialog? Adrian Bateman of Microsoft agrees with me:
We also don’t think
dialogadds sufficient value to justify the spec,implementation, and test cost.
If you’re looking to read the HTML 5 spec from a markup author’s perspective (that is, ignoring all the stuff for implementors), you can find the huge single-page Author spec and multipage Author version.
Stack Overflow’s What improvements to accessibility are offered by HTML5? is an unbiased overview.
There’s a 10 min video interview on Standards Suck talking about some of the issues above, and an interview with Government Computer News in which I talk about HTML 5 development and its relationship to the US accessibility standards section 508.
And, by the way, if you’re interested in HTML 5, please vote for my South By Southwest HTML 5 panel.