Getting Semantic With Microformats, Part 8: Value Class Pattern ~ A Blog Not Limited

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.

hAccessibility

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.

Usability

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:

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.

Internationalization

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?

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

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.

May 18, 2009 at 1pm

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 

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.

May 18, 2009 at 1pm.

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 

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:

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

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

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 ``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:

 May 18, 2009 at 1pm

Update: 2009-10-20

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

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:

My birthday is on September 4.

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:

June 2, 2009

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 `type`s

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:

mobile: 505-123-4567

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:

Home: +44 (0) 1223 123 123

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.

A Blog Not Limited

to web design, standards & semantics