Storing data in the DOM

One common strategy in progressive enhancement is to use the static content on a page as an initial data store for a richer application. This avoids an awkward loading screen and provides happy endings for everyone: users who who don’t support the app still get what they came for; users who do get a little more goodness in their browsing experience; and the development team avoids having to deliver redundant data. As an added bonus, it’s searchable: when index crawlers stop by, they won’t find a blank page waiting for an app to load.

To spoil the ending, there’s a handy jQuery plugin for retrieving data from the DOM available on github. If that’s what you’re here for, go get it! And if not, read on. We’ll start by inspecting a few common data formats.

1. The Data API

HTML5′s data-* syntax allows a single element to define model properties as arbitrary data attributes. This probably isn’t the best choice for models that could possibly have any shred of semantic meaning, but it is often used to store properties that wouldn’t ordinarily been shown.

<div class="city" data-id="134" data-lat="41.5", data-lng="-81.6">Cleveland</div>

2. Microformats

A much more common (and often more preferable) scheme is to give each datum semantic meaning through its markup. This is the strategy taken by microformats, and it looks something like this:

<div class="guitar">
  <span class="make">Fender</span>
  <span class="model">Stratocaster</span>
  <span class="finish">Natural</span>
</div>

This approach makes it easy to style individual fields of the model and is well-suited to presenting more involved data.

3. Lists are collections

Lists are a convenient means of storing a collection of data elements. No surprises here:

<ul>
  <li class="car">
    <span class="make">AMC</span>
    <span class="model">Hornet</span>
  </li>
  <li class="car">
    <span class="make">Chevrolet</span>
    <span class="model">Corvair</span>
  </li>
</ul>

4. Tables: not just layouts anymore

It’s probably surprising, but the real reason tables were included in the HTML spec doesn’t have anything to do with helping web developers create terrible layouts. Rather, they’re intended to do what tables usually do–present data.

<table>
  <thead>
    <tr>
      <th>Year</th>
      <th>Title</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1977</td>
      <td>The Hobbit</td>
    </tr>
    <tr>
      <td>1977</td>
      <td>Wizards</td>
    </tr>
  </tbody>
</table>

All in a tidy plugin

If you’re anything like me, having a generic script to draw data from these common forms could save a few minutes of development on that next project. So I’ve gone ahead and encapsulated adapters for each of the data formats described above into a single jQuery plugin.

The syntax is fairly simple. To retrieve a model’s properties from a DOM field, define the model’s attributes and call the DOMDataSource method on the element that contains its data (fiddle here).

<div class="car">
  <span class="color">yellow</span>
  <span class="make">dodge</span>
  <span class="model">dart</span>
</div>

<script>
var attributeTemplate = {
  make: '',
  model: '',
  year: ''
};

var model = $('div.car').DOMDataSource(attributeTemplate);
</script>

The same method can be used to retrieve a collection of items from a list (fiddle here):

<ul>
  <li>
    <span class="color">blue</span>
    <span class="make">amc</span>
    <span class="model">hornet</span>
  </li>
  <li>
    <span class="color">orange</span>
    <span class="make">chevrolet</span>
    <span class="model">corvair</span>
  </li>
</ul>

<script>
var cars = $('ul').DOMDataSource(attributeTemplate);
</script>

It doesn’t get much easier than that!

Let’s keep in touch

Get noise-free updates on software, product, and process.

Hey, I'm RJ: digital entomologist and intermittent micropoet, writing from the beautiful Rose City.