Microformats are nifty little bits of semantically rich markup. But there have been some concerns about microformats with regard to accessibility and internationalization. With the value class pattern, those concerns are addressed and resolved.

Microformats are nifty little bits of semantically rich markup. They are surprisingly simple to implement given how powerful they are. That’s one of the reasons why they’ve proven so popular. Because they only require adding a few class names to existing markup, there are now millions of hCards and hCalendars published all over the web.

It’s no accident that microformats are easy to learn. In fact, that’s one of the microformats design principles: design for humans first, machines second. Of course that means that writing a microformats parser can be hard work. Anyone can publish with microformats, but you have to be pretty smart to create something like Oomph that consumes the published microformats. But that’s okay …ease of authoring is more important than ease of parsing.

In general, microformats don’t try to dictate what markup you should use. As long as you are using the right class values, you are free to choose whatever elements you consider to be semantically appropriate; spans, ems, divs, ps, whatever.

But historically, there’s always been one exception to this freedom. If you needed to mark up a datetime in a microformat—such as hCalendar—you didn’t have many options. In this case, machines aren’t smart enough to do natural language parsing so you were forced to write for machines first, human second.

You could either present the datetime between the opening and closing tags of whatever element you were using:

<span class="dtstart">
    2009-06-05T20:00:00
</span>

…or you could put the value in the title attribute of the abbr element:

<abbr class="dtstart" title="2009-06-05T20:00:00">
    Friday, June 5th at 8pm
</abbr>

Those were your only options. The first option looks ugly. The second option isn’t very flexible. The BBC removed hCalendar support because of this inflexibility. They were concerned about the accessibility implications of overloading the title attribute of the abbr element. Concerns about semantics and accessibility really came down to the fact that, as an author, you had very little choice in how you could mark up a datetime value.

But now authors have a choice, thanks to the value class pattern.

The what now? I hear you ask. Well, if you’ve been feeling hampered by the combination of the datetime and abbr design patterns, the value class pattern offers a few alternatives.

You can split up the date and time into two separate abbr elements:

<span class="dtstart">
 <abbr class="value" title="2009-06-05">
  Friday, June 5th
 </abbr>
 at
 <abbr class="value" title="20:00">
  8pm
 </abbr>
</span>

When we write about events, we don’t always write the date and the time of the event in the same spot. Until now, you would have had to munge the date and time values together to create a machine-readable datetime. Now you don’t have to. This means more work for parsers but it makes life easier for authors.

I like that pattern but then again, I don’t think there’s a semantic problem with putting a date or time in the title attribute of an abbr element. I think there’s a big difference between putting a date string into the title attribute of an abbr element and putting a datetime string in there. Others might disagree. They might think that even using dates in combination with the abbr design pattern is semantically dodgy. That’s fine. They now have some other options they can use. Thanks to the value-title subset of the value class pattern, they don’t have to use the abbr element at all.

By applying a class of value-title to any element, you can indicate that the machine-readable data is to be found in the title attribute rather than between the opening and closing tags:

<span class="dtstart">
 <span class="value-title" title="2009-06-05T20:00:00">
  Friday, June 5th at 8pm
 </span>
</span>

And you can still choose to split up the date and time values if you choose to use the value-title class:

<span class="dtstart">
 <span class="value-title" title="2009-06-05">
  Friday, June 5th
 </span>
 at
 <span class="value-title" title="20:00">
  8pm
 </span>
</span>

You can even choose to embed the machine-readable data in an empty element:

<span class="dtstart">
 <span class="value-title" title="2009-06-05T20:00:00"> </span>
 Friday, June 5th at 8pm
</span>

Personally, I don’t like the way that that smells. Putting data into empty elements feels a bit too much like dark data to me. But that’s just me. I’ll probably stick with the first option of splitting up the date and time portions of a datetime value.

To my mind, that’s one of the greatest strengths of the value class pattern: it doesn’t offer one alternative, it allows authors to choose how they want to mark up their content.

When it comes to writing, there are often no right or wrong answers, just personal preferences. That’s true whether it’s English, HTML, or any other language. As long as you use correct syntax and grammar, the details are up to you. You can choose semicolons or em-dashes when you’re writing English. You can choose abbr or value-title when you’re writing microformats.

The wiki page for the value class pattern doesn’t just list the options available to authors. It also explains them. That’s just as important. Head over there and read the document. I think you’ll agree that it’s an excellent example of clear, methodical writing. The microformats wiki needs more pages like that. One of the biggest challenges facing microformats isn’t any particular technical problem; it’s trying to explain to willing HTML authors how to get up and running with microformats. If you need some pointers or if you’d like to help others, please don’t hesitate to get stuck in: edit the wiki, hang out in the IRC channel, and join in the discussions on the mailing list.

You can start using the value class pattern today. It’s already supported in Brian Suda’s excellent X2V parser. As of now, it’s also supported in Oomph.