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.
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
abbroutweighs 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
title value. This time, though, the problem wasn't tied to screenreader activity, but normal browser behavior. You see, most browsers display
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.
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
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.
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.
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.
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:
<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
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
title attribute, so
class="value-title" is unnecessary and invalid.
Value-Title Subset With Empty
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>
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
dtstartvalue 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
- 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>
Or publish dates in hAtom:
<p class="published"><span class="value-title" title="2009-06-03">June 2, 2009</span></p>
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.
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
<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).
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.
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
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
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.