Tuesday, November 1, 2011

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

Link to 'Why no <time>?' web site.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:

Pissed about the <time> fiasco? You can help: when blogging & speaking reference the W3C version not WHATWG version of HTML5 #occupyHTML5

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

Update November 3, 2011

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

2 comments:

  1. Just want to note that Drupal didn't actually have <time> in core yet. We were working on adding it and I was aware of the issue that Hixie had posted, so both myself and Everett Zufelt asked on Oct 22 whether the issue had been decided.

    Fortunately, in our case it is relatively easy to change from one to the other... we've centralized the output to one function so we just need to switch out an element and attribute name in a single bit of the code, plus Drupal 8 is still in early dev. However, I imagine it's not nearly as easy for a lot of people who implemented it.

    ReplyDelete
  2. Lin,

    Thanks for the clarification/correction. I am kind of hoping your question to Hixie resulted in the decision, even if I don't agree with the decision. At least now people are debating the business case for an element along with the process that got it where it is.

    ReplyDelete