I can never pinpoint the exact moment at which I “get into” a particular technology. CSS, DOM Scripting, microformats …there was never any Damascene conversion to any of them. Instead, I’d just notice one day, after gradually using the technology more and more, that I was immersed in it.
That’s how I feel about HTML5 now.
There’s another feeling that accompanies this realisation. I remember feeling it about CSS in the late 90s and about DOM Scripting half a decade ago. At the same time as I look up from my immersion, I cast a glance around the web development landscape and ask Why aren’t more people paying attention to this?
In the case of HTML5, this puzzling state of affairs can, to a large extent, be explained by the toxic 2022 meme. Working web developers with an idle interest in HTML5 would google the term, find a blog post telling that it won’t be “ready” until 2022, and then happily return to their work, comforted by the knowledge that HTML5 was some distant dream on the horizon—one that doesn’t affect them in any way today.
Nothing could be further from the truth. The Last Call Working Draft status is (optimistically) planned for October; that’s one month away.
And what rough beast, its hour come round at last, slouches towards Bethlehem to be born?
If you want to have a say in the formation of the most important web standard in existence, don’t put off getting involved. As Bruce says, If you don’t vote, you can’t bitch.
Still, I think the attitude of most web developers towards HTML5 right now is, at the very least, “interested, if a little sceptical”—that’s certainly how I felt when I started dabbling in it.
A little while back, I got together with some of my interested (if a a little sceptical) colleagues in New York, thanks to a generous invitation from Zeldman.
After a fairly intense two days of poring over the spec, I think it’s fair to say that, on balance, the interest increased and the scepticism decreased. That’s not to say that everything looks rosy in the current incarnation of HTML5. When you’ve got some of the smartest front-end web developers I know of in the same room together and they all agree that some parts of the spec are confusing or downright wrong, that’s quite worrying.
On the plus side, most of the issues are pretty minor in the grand scheme of things. It’s fair to say that most of the stuff that interests web authors—the semantic side of things—only accounts for a small part of HTML5. Most of the HTML5 specification is about error handling, APIs and shiny new interactive content. There are plenty of programmers and browser makers forging those powerful new tools. But as qualified as they are to hammer out those complex constructs, they are not necessarily the most qualified to make decisions on creating new structural elements. For that, you need the input of authors. And authors have been decidedly slow to get involved with HTML5.
It’s time for authors to get involved. I believe our voices will be welcomed. According to the HTML design principles:
…consider users over authors over implementors over specifiers over theoretical purity.
I’ll get the ball rolling with my own little list of things that are troubling me…
I’m with Bruce and Remy. If the small element is being redefined for disclaimers, caveats, legal restrictions, or copyrights
, it needs to be handling how that kind of content is published in the wild. That means it needs to be able to wrap paragraphs, lists and other flow content.
Alternatively, it should go the way of its evil twin, the big element, and simply be deprecated …sorry, I mean obsolete and non-conforming.
I’ll join in the chorus of people who think that the restrictions on the information that the new time element can contain are unnecessarily draconian. You can encode a date and time, you can encode a date, but you can’t encode just a month and a year. So you can’t make a piece of information like “April 1912” machine-readable. The spec says the time element:
…is intended as a way to encode modern dates and times in a machine-readable way
Which is great. But the sentence doesn’t finish there. It goes on:
so that user agents can offer to add them to the user’s calendar.
That’s one use case! I don’t think it’s wise to rain on the parade of anyone wanting to build, say, timeline mashups. Trying to mandate use cases ahead of time is not just counter-productive, it’s probably impossible. Can you imagine if Flickr had launched their API with strict instructions that it could only be used for one particular purpose?
I have nothing against the figure element itself, although it does seem uncomfortably close to aside, but the insistence on recycling the legend element to handle the caption is problematic.
Don’t get me wrong: I’m all for re-using existing elements rather then creating new ones, and I know that Hixie looked at all the options. But the way that browsers currently treat the legend element makes it unusable outside of a form.
I think that the label element could work instead.
Just like figure, the details element reuses legend. In this case, label won’t do the trick. details is an interactive element and it doesn’t look like the label element can be made keyboard accessible.
In this case, as undesirable as it is, a new element may be called for.
I’ve got two issues with the article element.
Firstly, its definition sounds awfully similar to section. I’m not convinced that there needs to be two different elements. Having two elements that look like a duck, walk like a duck and quack like a duck is just going to lead to confusion amongst authors wondering which duck to use.
The article element, unlike the section element can take an optional pubdate attribute to encode the publication date. I’m all in favour of having this information be machine-readable but the pubdate attribute smells like dark data, subject to metacrap rottage. In most cases, the publication date will be repeated in the content of the article anyway, so I’m in favour of adding a flag there rather than duplicating data. A Boolean pubdate attribute on a time element within an article header or footer should do the trick.
Update: Belay that last gripe, ensign. As proof of just how fast this spec moves, less than 24 hours after I published this, Hixie has implemented what I was suggesting.
Speaking of footer, this one is the biggie…
There is a big disconnect between what the HTML5 spec calls a footer and what authors on the web call a footer.
According to the spec, you’re only supposed to put some kinds of content inside a footer:
Flow content, but with no heading content descendants, no sectioning content descendants, and no header or footer element descendants.
That means no nav or headings in footer. The way that the footer element is defined in the spec, it’s a slightly more expanded version of address.
Ah, address! One of the most problematic elements in HTML 4. It is often incorrectly used to mark up street addresses. But is it any wonder? When an element has a name address, it’s hardly surprising that authors are going to use it for marking up addresses. The same thing is going to happen with footer.
The term “footer” was not invented for HTML5. It’s been in use on the web for years and in print for even longer. But if you ask any author to define what they mean by the term “footer”, you’ll get a very different definition to the one in the HTML5 spec. They may even point to specific examples of footers on sites like Flickr or on blogs, where they contain headings and navigation.
To be fair, when the new structural elements were being forged back in 2005, there wasn’t as much prevalence of what Derek Powazek termed fat footers. So when Hixie ran his analytics on a shitload of web pages crawled by Google and found that “footer” was by far the most common class name, most footer content was pretty meagre. But usage changes (see also: time).
The way that the element named footer is defined in HTML5—to be used multiple times in a single document in sections and articles as well as at the document level—is very different from the convention named footer in common usage on the web today. Most of the instances of what authors call a footer are more like what the HTML5 spec defines as aside.
I don’t want to spend the next decade telling authors not to mark up their footers as footers. It was bad enough telling people not to mark up addresses as addresses. In any case, authors aren’t going to listen. If they see there’s an element called footer, they will assume it refers to the device known as a footer, and mark up their content accordingly. At that point, the HTML5 spec will have become a work of fiction instead of documenting what’s actually on the web.
One of two things needs to happen. Either:
- The content model of
footer is updated to match that of header, which is much more liberal in what it accepts, or:
- The name of the element currently called
footer should be changed to match the current, restrictive definition. I suggest using contentinfo, which is the name of an existing ARIA role for exactly this kind of content.
ARIA roles, by the way, are an excellent addition to HTML5. ARIA integration is a win for ARIA and a win for HTML5, in my opinion. Most of all, it’s a win for authors who now have a whole swathe of extra semantics they can sprinkle into their documents (and use as styling hooks with attribute selectors).
Thus endeth my list of things I want to see fixed in HTML5. I’m leaving out the massive issue of canvas accessibility because:
- that’s beyond my area of expertise,
- smarter people than me are working on it, and
- I think that
canvas would probably benefit from being spun off into a separate spec.
There are other little things that bother me in HTML5—hgroup smells funny, cite shouldn’t be restricted to titles of works, and I miss the rev attribute on links—but those are all personal foibles; opinions unsupported by data. I’d rather concede than argue without data.
Because, make no mistake, data is what’s needed if you want to affect change in HTML5. Despite the attempts to paint Hixie as a stubborn, opinionated dictator, he is himself a slave to data. He shows an almost robot-like ability to remove his own ego from a debate and follow where the data leads.
If you are an author of HTML documents, I strongly encourage you to get involved in the HTML5 process.
- Read the spec.
- Join the mailing list.
- Hang out in the IRC channel.
Like I said, most of the spec and discussion is about APIs rather than semantics, but it’s precisely because the spec isn’t directly aimed at authors that authors need to get involved.
