End of [time] Is Not Helping the Case for HTML5

Yesterday afternoon I posted a general overview of recent changes in HTML5, focusing on this weekend’s development over the removal of <time>: HTML5 kills <time>, Resurrects <u>

I thought I was already a little late to the party, but apparently not so. With the start of the week people swung into action to protest the move, even firing up a brand new site, Why no <time>?, working its way across the web thanks to the #occupyhtml5 hashtag on Twitter.

As you follow the hashtag and read comments on Bruce Lawson’s blog post and Zeldman’s blog post, you can see a trend start to emerge — people are often annoyed because they have already implemented <time> in their own projects. For some it’s personal and pet projects, for others it’s been done on client sites, and then there are popular sites that have worked it in as well, such as Reddit, The Boston Globe, the default WordPress theme, and now parts of Drupal’s core.

Each of these represents some investment of time, effort and/or cash (I argue all three). These are people implementing it before it’s a final specification. They are selling bread when the batter isn’t even fully mixed but with the promise that it has no nuts.

In January 2010 I wrote about whether it was too soon to advocate HTML5. At the time I believed it was too soon. As the specification has moved forward and people have found good business cases for leaning on promised features (who aren’t confusing them with WebGL, SVG, CSS3, and so on) I have started to warm to the idea.

If you go back to August 2009 you might recall when the HTML5 Super Friends (Zeldman, Jeremy Keith, Eric Meyer, etc.) got together to voice their concerns over elements and attributes in HTML5, even raising points about <time>. Back then the campaign got some resolution and things seemed to stabilize for at least one element — <time>.

This recent dust-up leads me to question just how stable the specification is. Even <time>, after a review and edits, still only got just over two years before it was gutted. Software projects can take that long to implement, so relying on a feature (in this case an element) at the start of a project that might go away before you are done is a huge risk.

If HTML5 is supposed to be a reflection of the current state of web development, as we see in its cavalier approach to attribute quoting, closed elements, proper nesting and so on, then I can’t imagine why an element in the wild for over two years gets cut while other derided elements like <u> get a reprieve and are brought back into the fold.

Now let’s add the case that WHATWG has made for moving HTML5, the one under its auspices, to a version-less model. WHATWG explains it in the post HTML is the new HTML5:

…[W]e realised that the demand for new features in HTML remained high, and so we would have to continue maintaining HTML and adding features to it before we could call “HTML5” complete, and as a result we moved to a new development model, where the technology is not versioned and instead we just have a living document that defines the technology as it evolves.

We have just witnessed what that means. An element in which significant investment has been made can just go away at the whim of one man. For this reason John Foliot has hit the nail on the head with this tweet when referring to the HTML5 specification:

I am taking a different approach with clients. I am resisting the gee-whiz desire to be bleeding-edge with no business case to support HTML5 implementation and sticking with HTML 4.01. It’s amazing how limiting that isn’t given all the other great things going on with parallel web standards.

Update November 2, 2011

• To distill the post Timeless by Jeremy Keith, Keep using the time element.
• Oli Studholme touches on these same points and discusses <data> in Goodbye time, datetime, and pubdate. Hello data and value.

Update November 3, 2011

The <time> element has been restored. Read more: Well, It’s about <time>