From 4 to 5; a seismic shift in HTML

Further to my thoughts a few months back on the propsed specification for HTML5 (it was even commented on by a genuine web heavyweight). Well, the whole issue isn’t going away so I thought I’d bring my measly mind to bear on this fascinating subject again.

First, a quick explanation. I say “fascinating” because this is potentially one of the biggest shake-ups on the web in (10?) years. While new versions of browsers is noteworty, making large changes to the language that those browsers actually speak natively is a massive shift. Just think, in a couple of years time we could be marking up our documents with “aside”‘s, “dialog”‘s and “figure”‘s. That, dear readers, is a Big Thing.

The reason this has come to the fore again is because Anne Van Kesteren has written an easy-to-understand document outlining the differences between HTML5 and HTML4. As she states, most of the HTML5 specification isn’t about adding new things, but fixing the old things so they can be used in a standard way across user agents.

Still, it’s the new stuff that excites us geeks most of all. Here’s a few of my favourites which I didn’t make a note of last time (and maybe my feelings on this have changed in the last 4 months).

event-source can be used to “catch” server sent events”

Wow, so there’s going to be an actual element specifically for that AJAX stuff? Cool.

output represents some type of output, such as from a calculation done through scripting”

Ditto what I said above. This is good news, as despite my best intentions pages with a lot of JavaScript working on them always end up looking like a dogs dinner. Semanticise and control, I say.

And then this one is, as our American friends would say, a doozy:

The input element’s type attribute now has the following new values:

  • datetime
  • datetime-local
  • date
  • month
  • week
  • time
  • number
  • range
  • email
  • url

The idea of these new types is that the user agent can provide the user interface, such as a calendar date picker or integration with the user’s address book and submit a defined format to the server. It gives the user a better experience as his input is checked before sending it to the server meaning there is less time to wait for feedback.

Now that would be useful. Inbuilt browser input validation. I’ll raise a glass to that.

Anyway, take a look at the document. What bits are you most interested in?