With HTML 5 and the introduction of datasets, we can do something new. The main advantage and the really huge application area for datasets are, that you can include custom attributes in the serverside-rendered HTML, that the client-side script will use to enhance the browsing experience.

A common example: You have a gallery page, which has an area for displaying a large image and one for a list of thumbnails. In the serverside-rendered HTML you render the first picture in the large image and a list of thumbnails below. In javaScript you hook a function for each thumbnail to change the large image. But where do you supply the path for the large image? It could be done via several methods:

• from the server render a JavaScript-array that do the mapping,
• have a strict naming-convention, and e.g. always remove “-thumb” from the thumbnail path to obtain the large image path,
• hide it on the node by abusing some existing legal property – e.g. hide it in the title-field of the thumbnail, or
• add it is a new property on the node, that will make your document non-compliant with the standard.

But with datasets, the server simply includes the large image path on the thumbnail image node (or the surrounding link node) via a custom data-attribute here named data-fullpath:

<img
  id="large-image"
  src="images/large/picture1.png"
  alt="Large Picture 1"
/>
<ul id="thumbnails">
  <li>
    <a href="gallery_with_picture1_enlarged.html" title="View Picture 1">
      <img
        src="images/thumbs/picture1.png"
        data-fullpath="images/large/picture1.png"
        alt="Picture 1"
      />
    </a>
  </li>
  <li>
    <a href="gallery_with_picture2_enlarged.html" title="View Picture 2">
      <img
        src="images/thumbs/picture2.png"
        data-fullpath="images/large/picture2.png"
        alt="Picture 2"
      />
    </a>
  </li>
  <li>
    <a href="gallery_with_picture3_enlarged.html" title="View Picture 3">
      <img
        src="images/thumbs/picture3.png"
        data-fullpath="images/large/picture147_no_conventions.png"
        alt="Picture 3"
      />
    </a>
  </li>
</ul>

Of course, in live implementation the links above would link to pages, where the other thumbnails where shown in the large area to allow for graceful degradation, but this is just to show the idea. The above example have now been updated to provide actually interesting links in the surrounding <a>-tags and not just link to the image as several have suggested.

The JavaScript that went with this would be something along the lines of (asuming jQuery.dataset functionality):

$("ul#thumbnails a").click(function(e) {
	$("#large-image").attr("src", $(this).find("img").dataset('fullpath'));
	return false;
});

See full example here – it works in all browsers, and is valid HTML 5. The JavaScript works in non-HTML5 browsers, as it includes a little jQuery plugin I wrote adding the method dataset, which includes a fallback if the DOM attribute “dataset” is not available.

I personally find this to be a very clean way of implementing this feature over the many hacks, that we need to use today. And this is of course not limited to galleries, but can be used for anything, where the script needs to know extra information about the objects in the document in order to add additional functionality through scripts on the page – this could include having a reference to “previous” or “next” image in the above gallery, meta-information about rows in a table to use for client-side searching, filtering or sorting, meta data for link previews and many other possibilities.

NB: This is not to be used as meta-data for external entities – only for scripts on the page enhancing the browsing experience. For providing meta-data for external entities, use microdata, which is completely different from datasets – but the two could be used to convey the same meta information, just with different recipients in mind.

Related posts:

1. Web Sockets in HTML 5 might solve the http pull problem once and for all

But with the dawn of HTML 5, this worry is irrelevant, because with HTML 5 and the greatly improved JavaScript API, we also get a brand new Web Sockets API. This will have the same basic low-level access to bi-directional communication as ActionScript got with the XMLSocket API – it wasn’t XML only, it was just the (widely used) default transport method, but it could easily be circumvented.

Quite stunning though, how such a simple mechanism arrives in JavaScript 10 years later than it did in ActionScript!

When this becomes standard in new browsers across vendors, we will see it implemented in so many popular applications, that currently use all sorts of tricks to achieve the same results – like Facebook, who uses Comet to “push” JavaScript notifications. With this API, doing stuff like that becomes much easier and much cleaner. Or Google Docs, who use Comet as well as HTTP pulling. Or NFL live match view, who use a Flash object in the document to receive events about the match being watched.

And this of course also increase the opportunity for creating new multi-user applications – and games – in HTML and JavaScript. And given the extra computational strengths, that most JavaScript engines are being equipped with currently (Chrome started the race and IE8 perform surprisingly well), and given some of the other fun things in HTML 5 like canvas, things will really start to get interesting.

Go HTML 5 – get yourself final as soon as possible! Give us JavaScript programmers the same tools that we ActionScript programmers have had for a decade.

Related posts:

1. Datasets in HTML 5 and what they’re good for
2. Flash development and the practice of Scripted Layout

Personally, the Web Forms 2 specification really gets me excited, and the overall proposal seems sane and the most interesting and logical way to go. The HTML 4.01 and XHTML 1.1 recommendations are getting old and certainly does not reflect modern web content.

Thus I strongly support the adoption as do so many others. And it will come – just hang in there.

Related posts:

1. Datasets in HTML 5 and what they’re good for
2. Web Sockets in HTML 5 might solve the http pull problem once and for all