A Blog Not Limited

to web design, standards & semantics

Getting Semantic With Microformats, Part 8: Value Class Pattern

Jun 02, 2009

Published in


Update: 2009-10-20

Tantek Çelik requested that I add inline examples of the value-class pattern markup in this article, so people working on applications to parse uses of the pattern can reference this article as a live example.

I finally obliged, and you will see those inline examples below, each of which is indicated as an update.

No, your eyes aren't deceiving you. It's another installment of my Getting Semantic With Microformats series (with a special thanks to Ben Ward for his technical assistance)!

It's been about six months since Part 7, so you may be wondering why I've waited so long. Well, let's just say I've been busy.

But even my insane schedule couldn't keep me from posting this latest installment, which comes on the heels of the announcement that the value class pattern is official. Let the celebration commence!

Let Me Refresh Your Memory

Unless you are a microformats geek like me, you probably don't know what the value class pattern is.

If, however, you've been following this series and happened to read my Microformats, hAccessibility & Moving Forward article, you probably know more than you realize.

But let me not assume too much and give you the background 411.


The Web Standards Project noted an accessibility problem in microformats (termed "hAccessiblity") regarding the datetime design pattern.

At the core of this problem is the use of abbr to contain human-readable date information, with the title attribute value representing the ISO 8601 machine-readable date. It looks like this:

<abbr class="dtstart" title="2009-05-18">May 18, 2009</abbr>

And, when read by a screenreader, this design pattern results in that ISO 8601 date being read to the user as "two zero zero nine dash zero five dash one eight." What's worse is when the ISO 8601 value is more than just date, but date and time, such as in this example:

<abbr class="dtstart" title="2009-05-18T10:30:00">May 18, 2009 at 10:30am</abbr>

This results in screenreader output: "two zero zero nine dash zero five dash one eight T one zero colon three zero colon zero zero."

The accessibility community (rightly, IMO) argued that this is not accessible to those users. Meanwhile, the microformats community argued that:

  • ISO 8601 dates are, in fact, quite (cross-culturally) human-readable;
  • The semantic value of offering expanded values via abbr outweighs the screenreader issue because
  • Most screenreaders don't have abbreviations set to expanded.

And this debate waged for years.


But it wasn't just hAccessibility that was a thorn in the side of microformats. There were also usability concerns related to the datetime design pattern.

Once again, at issue was the ISO 8601 date as the abbr title value. This time, though, the problem wasn't tied to screenreader activity, but normal browser behavior. You see, most browsers display abbr title values as a tooltip to the user:

Datetime tooltip screen capture

Only the geekiest–of–the–geek will likely recognize this information. For everyone else, it throws a (arguably small) wrench in their browsing experience. And the machine-readable parts of microformats are supposed to be invisible to the user. This tooltip display is not invisible and it can be confusing to everyday (non-geek) users.


Another commonly-heard complaint about microformats is that they aren't "internationalized." That is, some of the values required by microformats offer meaning only to those folks publishing in American-English.

Let's consider the accepted telephone type values in hCard: "cell" is the required value to use if you are indicating a cell phone. American-English users likely know what a cell phone is, however, British-English users call these types of phone "mobile."

Again, usability concerns.

Enter the Value Class Pattern

To address these concerns, the microformats community has been working diligently for quite a while to come up with a solution. In fact, I even tried my hand at authoring and testing what was originally called the value-excerption pattern.

And all that hard work finally paid off with the value class pattern, which offers authors several options for marking up their content without having to be concerned about the aforementioned usability, accessibility and localization issues.

Date & Time Information

I just said it, but I'll say it again: using the value class pattern, authors have several options for marking up date and time information. You pick the one you like; the one that is most relevant to your content and your preferences. I get shivers just thinking about it (doesn't take much these days).

First, let's take a look at some of the options for marking up date and time information.

You Can Still Use <abbr>

The value class pattern does not abolish the use of the abbr design pattern for date-time information (AKA datetime design pattern). If you are on the side of the "debate" that believes using abbr with ISO 8601 date and time title values makes semantic sense, go for it.

Before the value class pattern entered the picture, this is how you would mark up your date-time information for dstart in hCalendar:

<abbr class="dtstart" title="2009-06-06T18:30:00">June 6, 2009 at 6:30pm</abbr>

However, this method is considered deprecated for date-time information. Machines can still parse it, but now with the value class pattern, it is no longer the recommended method.

Note, though, that the abbr design pattern itself — for country name expansions, abbreviated latitude/longitude coordinates, etc. — is still completely valid. It is only for date-time information that things change slightly.

What are these slight changes?

<p class="dtstart"><abbr class="value" title="2009-06-06T18:30:00">June 6, 2009 at 6:30pm</abbr></p>

Note that the dtstart sub-property is assigned to the containing p (which can be any element), while the abbr is now assigned class="value". The ISO 8601 title value remains the same.

Keep in mind, however, that this example still results in the usability and accessibility issues behind hAccessibility. But this may be the preferred method of some contact authors. The beauty of the value class pattern is that you can pick which method works best for you.

Update: 2009-10-20

Inline example of the above value class pattern reference, using <abbr>

Test Event 1

June 6, 2009 at 6:30pm

Drop the Abbr Design Pattern

If you are wary of screenreader and usability issues related the abbr design pattern for your date-time information, the value class pattern is for you too, thanks to the value-title subset

So, instead of using abbr to contain the human-readable content with the machine data in the title attribute, you can use a span element assigned class="value-title" and a title attribute containing the ISO 8601 date. Machines then recognize that data value for that element (the one assigned class="value-title") should be extracted from the title, not the inner text.

<p class="dtstart"><span class="value-title" title="2009-05-18T13:00:00">May 18, 2009 at 1pm</span></p>

This achieves the goal of microformats for human and machine data, while not causing the display of tooltips in the browser or prompting screenreaders to read the machine date information. Most browsers, however, still display the tooltip value, the exception being Safari 3.0.3 on Windows XP.

Update: 2009-10-20

Inline example of the above value class pattern reference, using <span>

Test Event 2

May 18, 2009 at 1pm

Separate Date & Time

Further demonstrating how flexible the value class pattern is, you can also use it to separately specify the date and the time.

<p class="dtstart"><span class="value-title" title="2009-05-18">May 18, 2009</span> at <span class="value-title" title="13:00:00">1pm</span></p>.

Again, in this example, I've dropped the use of abbr and am using the span class="value-title" approach. But this time, note that I have the date and time separately specified in their own span class="value-title" elements (each with the appropriate ISO 8601 information in the title). Machines can then combine the separate date and time data into a single date-time value.

Update: 2009-10-20

Inline example of the above value class pattern reference, separately specifying date and time using <span>

Test Event 3

May 18, 2009 at 1pm

And this separation of date and time can be used with the abbr design pattern. In fact, some folks believe this helps address usability concerns with datetime tooltips. Specifically, the resulting individual tooltips for date and time are more "usable" than a tooltip displaying the full date-time string:

Date tooltip screen capture Time tooltip screen capture

For those folks, this implementation of the value class pattern applied to the abbr design pattern is ideal:

<p class="dtstart"><abbr class="value" title="2009-06-06">June 6, 2009</abbr> at <abbr class="value" title="18:30:00">6:30pm</abbr></p>

You just separately define the date and time values, each with their own abbr class="value" and the appropriate ISO 8601 title values.

Update: 2009-10-20

Inline example of the above value class pattern reference, separately specifying date and time using <abbr>

Test Event 4

June 6, 2009 at 6:30pm

Note, that I am not using the value-title subset in this example. That's because it should not be used with the abbr design pattern.

When using the value class pattern with the abbr design pattern, it is only necessary to assign class="value" to the abbr element. Machines already know to extract the ISO 8601 date and time from the abbr title attribute, so class="value-title" is unnecessary and invalid.

Value-Title Subset With Empty <span>s

And yet there is even another option; one that eliminates both tooltips and screenreader expansions.

You can also use the class="value-title" approach with an empty span … well, not truly empty. A span containing a single white space:

<p class="dtstart"><span class="title-value" title="2009-05-18T13:00:00"> </span>May 18, 2009 at 1pm</p>

Update: 2009-10-20

Inline example of the above value class pattern reference using the value-title subset with an empty <span>

Test Event 5

May 18, 2009 at 1pm

The end result is the same: users get the clear, comprehensible date information on the browser and machines get the ISO 8601 date. And, again, no screenreader issues. But this time, you also eliminate the "confusing" tooltips.

There are a few rules for this particular implementation, the first of which is to use this "empty title-value" approach restrictively. Only use it when you can't use the other design patterns. And when you do use it:

  • The empty value-title element should immediately follow the parent element, appearing before the human-readable content and without any additional nesting.
  • The empty value-title element should be used only once when defining the data value for a single property. So it shouldn't be used when separating date and time in, for example, the dtstart value of hCalendar.
  • The empty value-title implementation should only (at least for now) be applied to
    • ISO 8601 date, datetime, timezone and duration values
    • Enumerated values like the hCard tel, email and adr sub-properties
    • Coordinates for latitude and longitude in the geo microformat
    • Telephone number properties
Not Just for hCalendar

The examples I've covered thus far focus on date and time information that would appear in hCalendar. But you can apply the value class pattern to any microformat that references date and time information. For example, birthdays in hCard:

<p class="bday">My birthday is on <span class="value-title" title="1974-09-04">September 4</span>.</p>

Update: 2009-10-20

Inline example of the above value class pattern applied to bday in hCard

Person One

My birthday is on September 4.

Or publish dates in hAtom:

<p class="published"><span class="value-title" title="2009-06-03">June 2, 2009</span></p>

Update: 2009-10-20

Inline example of the above value class pattern applied to published in hAtom

Test Post by Test Author

June 2, 2009

Localize While Internationalizing

So far, I've only talked about the value class pattern in relation to date and time information. But remember my earlier discussion of internationalization concerns? Well, let's take a look at that and how the value class pattern helps.

Telephone types

In my earlier reference, I specifically mention the telephone types in hCard. The only valid type value for specifying a portable phone is "cell," but not everyone references those types of phones as such.

You can use the value class pattern to display the local value your users will understand, and indicate the required microformat value via span class="value-title" and the title attribute:

<p class="tel"><span class="type"><span class="value-title" title="cell">mobile</span></span>: <span class="value">505-123-4567</span></p>

In this example, because I'm using the value-title subset, machines will know to extract the type data value (cell) from my title attribute, rather than the inner text (mobile).

Update: 2009-10-20

Inline example of the above value class pattern applied to tel type in hCard

Person Two

mobile: 505-123-4567

Localized Telephone Numbers

Another example (which I stole from the Microformats Wiki, because I don't know enough about international dialing) is for localized phone numbers. In this case, a British number:

<p class="tel"><span class="type">Home</span>: <span class="value">+44</span> (0) <span class="value">1223 123 123</span></p>

The logic behind this implementation is that the the valid data for the telephone number is +441223123123. But Britons are familiar with the inclusion of (0) for local dialing. Yet +4401223123123 is an invalid number.

So, to give local British users the information most usable to them and still provide valid machine data for the number, you apply the value class pattern. In this example, the +44 prefix is contained by span class="value" as is the 1223 123 123 number. However the (0) is not contained by anything. So machines concatenate the two span class="value" inner text to form the complete and valid data.

Update: 2009-10-20

Inline example of the above value class pattern applied to separated tel values in hCard

Person Three

Home: +44(0)1223 123 123

And there are far more uses of the value class pattern. But this blog post is already longer than I anticipated (I don't know why that still surprises me, given my fondness for verbosity) and I've got other things to do … so I leave it to you to explore further.

Pick Your Poison

Not to suggest microformats are poison (they are indeed yummy goodness), but I felt like throwing in a cheesy heading.

The point remains, though, you pick which value class pattern implementation works for you. You aren't wedded to one way of marking up your content with this pattern.

As for my own preferences, I don't happen to be one of those folks who is interested in continuing to use the abbr design pattern for dates and times. Don't get me wrong. I actually think abbr makes semantic sense for containing date information and expanding with ISO 8601 via the title.

But as much as I love semantics, I'm not a true purist. I think the value that the non-semantic span class="value-title" offers for accessibility and usability far outweighs my compulsion to be semantic.

However, I'm not too keen on the use of the empty value-title approach. So I don't anticipate using it much. For the majority of my own implementations involving dates and times, I see myself using containing my content with span class="value-title" and specifying machine data in the title attribute.

There will likely be exceptions to this, but that's what I like most about the value class pattern. It is flexible to content authors' needs.

Update Your Implementations

While I found the time to put this article together, I haven't yet found the time to update my existing microformats implementations. But I will … oh, yes I will. And I hope you do, as well.

Already, developers are working to update their tools to properly recognize the new value class pattern. Optimus is leading the charge with its v0.8 update that supports the value class pattern.

So be sure to do your part and get your markup updated.

Will There Be More?

No promises at this point about future installments of this series. I'd like to cover some other microformats, but with my book obligations, I highly doubt I will have the time … at least not until after my final manuscript is complete in August.

But if you are dying for more, why not revisit some of the earlier articles covering:

I also recently gave a short presentation on microformats you may be interested in (or not).

So, until next time … and yes, there will be a microformats-related next time even if it isn't part of this series.

HTML5 Cookbook

Interested in HTML5?
Get the Cookbook!

I was a contributing author for HTML5 Cookbook, available for sale on Amazon! Get yours now! (I hear chapters 1, 4 and 5 are particularly good.)

P.S. Don't forget my book Microformats Made Simple is still for sale!


Share the Love

Jason Karns's Gravatar

Jason Karns opines:


Thanks for such a great write-up! I’ve been following microformats for a while and the recent announcement of the value-class pattern is music to my ears! However, I noticed 2 small errors in your post. Under the heading: Drop the Abbr Design Pattern you mentioned that using the @title attribute on <span> elements with @class=‘value-title’ would not cause the display of tooltips in the browser or prompt screenreaders to read the machine date information. This isn’t correct. Browsers today will generate a tooltip for any element with a @title attribute, not only <abbr> elements. Further most screenreaders will also read the title attributes on any element, if configured to do so. I don’t believe this setting is the default, but can be turned on by the user.

The second minor error I noticed is related to the first. Under the heading Value-Title Subset With Empty you again mentioned that putting the @title attribute on a <span> element will eliminate the tooltip. As above, browsers will generate a tooltip but it would rarely be noticed as the user would have to hover over the space character.

Emily's Gravatar

Emily opines:


@Jason - Thanks for catching that first error! Definitely an oversight on my part. Content has now been corrected.

However, the second point you mention about title on empty (containing a single space) spans generating the tooltip ... as it turns out, the tootip is not generated.

I did some testing of this a while back, and it was confirmed by testing by others in the MF community.

However, if you are seeing the tootip in your own implementations, you should add the results to the testing page on the Wiki.

Thanks again for reading, and helping me make sure my information is correct.

Jason Karns's Gravatar

Jason Karns opines:


@Emily - I did some more testing of the empty-span case and it seems that in my haste, I broke one of the rules regarding the empty-space usage of the value-class pattern. That is, I placed a single quote before the empty span:

<p class=“dtstart”>’<span class=“title-value” title=“2009-05-18T13:00:00”> </span>May 18, 2009 at 1pm</p>

This causes the space to render and generate a tooltip (but only if you hover over the space).

Thanks for the correction.

Phill Sparks's Gravatar

Phill Sparks opines:


This is certainly an interesting development, I’ve been loathing the abbr pattern since I started looking at microformats a few years ago.  They’ve certainly covered all the bases of multiple values for one property in the wiki, even if it does take a bit of reading to get through.

I wonder how long it will take for the various microformat plugins to catch up, specifically Operator and Safari Microformats?

Karsten Januszewski's Gravatar

Karsten Januszewski opines:


Nice write up. And I forgot about the use of date formats in conjunction with bday in hCard—thanks for that reminded! 

We’re just finalizing the update of Oomph (http://visitmix.com/lab/oomph) to fully support the value class pattern. Should be ready soon!

Tantek's Gravatar

Tantek opines:


Emily, would it be possible for you to include the code examples that you show as actual inline examples in your markup (e.g. “here’s how your browser renders this code:” ... ) so that folks working on code to parse uses of value-class-pattern can try your article as a live example?



Emily's Gravatar

Emily responds:


@Tantek - Sure. Good idea. I’ll try to do that this weekend. Thanks for the suggestion!

Dave Doolin's Gravatar

Dave Doolin opines:


Can’t figure out why I never found your microformat series before.  Going on to my must read list.

Hey… what’s this business over here to the right… you’re echoing my comment as I type.

Are you allowed to do that?  Nobody does that!

I’ll be back… in research mode right now, skipping across Blogistan collecting links.

Shoshana Ivie's Gravatar

Shoshana Ivie opines:


I like to contribute on this blog by adding that web standard are greatly important. Take a look at what is now taking place inbetween Adobe and Apple.

Steve Griggs's Gravatar

Steve Griggs opines:


Found this blog after reading the .net article, then buying the book. Semantics & microformats are the way the web is progressing. If a designer wants to be sucessful he/she must learn and use POSH. It’s the only way forward.

Joe Bowbeer's Gravatar

Joe Bowbeer opines:


The time element in HTML5 is a welcome enhancement.

Joss's Gravatar

Joss opines:


Excellent article and series mate,

Really helped clear up the syntax.

Commenting is not available in this channel entry.

The Coolest Person I Know

Emily Lewis

Yeah, that would be me: .

I'm a freelance web designer of the standardista variety, which means I get excited about things like valid POSH, microformats and accessibility. I ply my trade from my one-person design studio in Albuquerque, New Mexico 87106 USA.

A Blog Not Limited is my personal blog where I pontificate about web design, web standards, semantics and whatever else strikes my fancy. Head on over to Emily Lewis Design if you'd like to see my work or, even better, hire me.


I Tweet, Therefore I Am

Follow @emilylewis on Twitter!