(Article updated to correct some typos noticed by commenters, and clarify some aspects.)
Avid HTML5 watchers will know that the <time> element was dropped from HTML, then re-instated, with more New! Improved! semantics.
As before, you can put anything you like between the opening and closing tags – that’s the human-readable bit. The machine-readable bit is contained within a datetime attribute. Dates are expressed YYYY-MM-DD.
Previously, you could only mark up precise dates. So, 13 November 1905 could be expressed in HTML <time datetime="1905-11-13"> but November 1905 couldn’t be. This is a problem for historians where sometimes the precise date isn’t known.
Now, “fuzzy dates” are possible:
<time datetime="1905"> means the year 1905
<time datetime="1905-11"> means November 1905
<time datetime="11-13"> means 13 November (any year)
<time datetime="1905-W21"> means week 21 of 1905
As before, times are expressed using the 24 hour clock. Now, you can separate the date and time with a space rather than a “T” (but you don’t have to). So both of these are valid:
<time datetime="1905-11-13 09:00">
You can localise times, as before. Appending “Z” to the timezone indicates UTC (a way of saying “GMT” without it being comprehensible to normal people). Otherwise, use an offset:
<time datetime="09:00Z"> is 9am, UTC.
<time datetime="09:00-05:00"> is 9am in the timezone 5 hours behind UTC.
<time datetime="09:00+05:45"> is 9am in Nepal, which is UTC + 5 hours and 45 minutes.
In New! Improved! HTML5 <time>, you can represent durations, with the prefix “P” for “period”.
The datetime attribute “D” for days, “H” for hours, “M” for minutes and “XQ” for seconds. Just kidding – that’s “S”.
You can separate them with spaces (but you don’t have to). So <time datetime="P4D"> is a duration of 4 days, as is <time datetime="P 4 D">.
Using a “T” after the “P” marker allows you to be more precise: <time datetime="PT23H 9M 2.343S"> is a duration of 23 hours, 9 minutes and 2.345 seconds.
Whichever you choose, it’s represented internally as a number of seconds. Because of this, you can’t specify a duration in terms of months, because a month isn’t a precise number of seconds; a month can last from 28 to 31 days. Similarly, a year isn’t a precise number of seconds; it’s 12 months and February sometimes has an extra day.
You still can’t represent dates before the Christian era, as years can’t be negative. Neither can you indicate date ranges. To mark up From “21/02/2012 to 25/02/2012”, use two separate <time> elements.
The pubdate attribute (a boolean that indicates that this particular date is the publication date of the parent <article> (or, if there is none, the whole document) is currently missing from the W3C version of the spec, but is still current in the WHATWG version. Its status is unclear to me (but I’m still using it).
Update 10 August 2012: in response to a query, I checked again and pubdate is gone from both the WHATWG and W3C specs.
As professionals, we need to keep our jargon accurate. That’s why I hate hearing “HTML5” used as an umbrella term for any web technology, especially when people confuse HTML5 (mark-up and APIs) with CSS 3 (eye-candy). Repeat after me: HTML5 != CSS 3.
So we need a buzzword, as “HTML5 and related technologies” is unwieldy (and inaccurate). I prefer “NEWT” which stands for New Exciting Web Technologies and can thus safely encompass real-HTML5, CSS 3, SVG, XHR2, Geolocation, Web Sockets, WOFF, Web DB, IndexedDB, WebGL and the like.
Because new acronyms need a logo, the talented and generous Rob Winters made a cute newt.
<summary>Get in touch</summary>
<p>Interested in sponsoring? Get in touch.</p>
If you click on the text inside the summary element (which defaults to the text “details” if absent), the details element expands. Click again, and it contracts.
The answer is because it’s much more hassle to pull in script and keep role and state info with ARIA. It’s much better to build these things into the language, with built-in accessibility because the browser vendors bake in role and state information and hook up the widgets to the operating system.
Expecting developers to reinvent this wheel every time is “bolt-on” accessibility, and we all know that they won’t actually do it. Yes, they can use a library. I’ve seen the whole jQuery library pulled in just to make an expando box behave like details.
I refer you to John Foliot, whose email to the HTML Working Group makes an excellent argument that explains the subject much better than I can. I should add that Foliot is by no means an HTML5 cheerleader and is a great advocate of accessibility and ARIA. His main points are
If something needs to be referenced you should normally make it an element, with an id attribute
If something represents a separate entity, make it an element: you might want to add attributes later
having a simple element express something instead of requiring a bunch of lines of scripting is way more efficient.
moving functionality into the browser natively, instead of relying on scripting which requires additional CPU is an efficient design choice
having ‘accessibility’ built-in rather than bolt-on (which is what ARIA is) is a fundamental desire of most of us in the a11y community.
I agree. It is. It’s also several different kind of messes, not all of which are avoidable or bad. Let’s look at them.
The backwards compatibility mess
The first kind of mess is because it builds on HTML 4. I’m sure if you were building a mark-up language from scratch you would include elements like footer, header and nav (actually, HTML 2 had a menu element for navigation that was deprecated in 4.01).
You probably wouldn’t have loads of computer science oriented elements like kbd,var, samp in preference to the structural elements that people “fake” with classes. Things like tabindex wouldn’t be there, as we all know that if you use properly structured code you don’t need to change the tab order, and accesskey wouldn’t make it because it’s undiscoverable to a user and may conflict with assistive technology. Accessibility would have been part of the design rather than bolted on.
But we know that now; we didn’t know that then. And HTML 5 aims to be compatible with legacy browsers and legacy pages. This page is written in HTML 5, and although your browser doesn’t “understand” it, it it still renders it.
There was a cartoon in the ancient satirical magazine Punch showing a city slicker asking an old rural gentleman for directions to his destination. The rustic says “To get there, I wouldn’t start from here”. That’s where we are with HTML. If we were designing a spec from scratch, it would look much like XHTML 2, which I described elsewhere as “a beautiful specification of philosophical purity that had absolutely no resemblance to the real world”, and which was aborted by the W3C last week.
That’s one reason why HTML 5 a mess. It’s built on a mess.
Why is the nav element so loosely specified? (“Only sections that consist of major navigation blocks are appropriate for the nav element”—define “major”, if you please.) Why can you have nav inside a header and not in a footer?
I should clarify two things after some tweets and a Skype conversation with Lachlan Hunt. The first is in fairness to Hixie: he changed the definition of nav to clarify that there can be more than one per page, and I agreed that the new defintion was an improvement. But, as I’m a self-confessed dimwit, I only realised later that the word “major” leaves ambiguity as well. So that’s my brain parsing slowly, not Hixie’s bad.
Secondly, and most importantly, I haven’t had some kind of damascene conversion to the anti-HTML 5 camp. I firmly believe that it’s the best way forward for an Open Standard that allows us to write richer web pages and applications. And I’m sure that no-one, especially those in the Working Group, believes it’s perfect already. In fact, the Working Group consistently call for developer participation in reviewing the spec.
To reiterate: bitching in blogs (like I’m doing now!) and on twitter is OK, but the best way to be sure that your views are heard is to mail to Working Group.
An Event Apart Boston is going swimmingly, but I’m taking a break to post this story from a BBC site that explains that the BBC has taken the decision to remove the hCalendar microformat from /programmes until
either the BBC accessibility group does further testing and declares the abbreviation design pattern to be safe to use
or the microformats community settles on an accessible alternative to the abbreviation design pattern
I’ve long been worried about the accessibility of microformats, so experimented and found that the way that dates are marked up is inaccessible to users of the big two screenreaders, and began writing an article to that effect.
James Craig, who is 97 times more helpful than I am, decided to research a better way to embed machine-parsable dates in content.
We jointly wrote up our results in an article called “hAccessibility“, which James published today.
Yay for the Geek in the Park meeting. I missed the picnic, as I was returning from monstrous partying for my kid brother’s birthday, but got there in time to actually have a pre-speaking run-through with my partner-in-crime, Pat Lauke, to make sure the two-handed presentation we’d jammed by phone and mail worked.
My notes, combined with some notes Patrick gave me, are reproduced. These are dense, as we talked for two hours, as this is just our crib sheet rather than a full transcript (if you want the full thing, we are available for weddings, barmitzvahs and satanic orgies. Especially satantic orgies).
In the world of religious loonies, there are two main kinds of nutter. One is the fundamentalist – someone with the attitude that a tract is the work of God, perfect and unquestionable; if it’s mentioned in the Book, it’s beyond doubt no matter how daft. The second sub-genre of nutter is the exegesist: someone who believes that extra, unwritten information may be teased out of the text with enough insight and critical reading.
Web Standards evangelist types will all recognise both type of adherent to that Holy of Holies: the w3c specs.