Microformat specifications

There are currently 34 microformats specifications (listed below) in varying levels of completion, and you can find out more about them on the microformats wiki.

These specifications and patterns cover many common types of data. They’ve been created by a grass-roots organisation of interested people, and anyone is welcome to contribute or even propose a new microformat.

Using rel-license for licensing information

Adding license information is quite a common activity, and while we can add a link to Creative Commons or another license easily enough, someone would have to read it to understand the content’s license:

<small>This article is licensed under a 
  <a href="http://creativecommons.org/licenses/by-nc-sa/2.0/">
  Creative Commons Attribution Non-commercial Share-alike 
  (By-<abbr>NC</abbr>-<abbr>SA</abbr>) license</a>.
</small>

If this information was machine-readable, search engines could use it to help consumers searching by license. By using the rel-license microformat to add rel="license" to the license link (indicating it’s the license for the page’s main content), we can do just that:

<small>This article is licensed under a 
  <a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/2.0/">
  Creative Commons Attribution Non-commercial Share-alike 
  (By-<abbr>NC</abbr>-<abbr>SA</abbr>) license</a>.
</small>

This may be so easy you don’t even realise you’ve just microformatted the link! In fact, Google already uses this data to allow us to search by license (look in advanced search, in the extra options).

Using XHTML Friends Network (XFN)

Maybe we should term this one eXtensible Friends Network instead XFN is a way of specifying your relationship with people — everything from “met” to “sweetheart” — using the rel attribute on a link to their homepage.

There are two main values: (1) rel="contact" (someone you know how to get in touch with), and (2) rel="me". The rel="me" value allows you to claim ownership of your various websites, including your accounts on social networks. For example, I could have a profile with a link to my Twitter account:

<p>Oli Studholme — <a href="http://twitter.com/boblet">follow me on
  Twitter (@boblet)</a></p>

A person can infer that @boblet is my Twitter username, but by adding rel="me" we can state this relationship in a machine-readable way.

<p>Oli Studholme — <a rel="me" href="http://twitter.com/boblet">follow me on
  Twitter (@boblet)</a></p>

In order to actually work, this would need to be on my personal homepage, with the same homepage added to my Twitter profile. By doing this, a social web app that understands XFN could confirm @boblet is me, check my friends on Twitter, check if those people are already registered, and then allow me to follow them all with one click — much easier.

For more on this idea, check out Identity consolidation and the XFN rel="me" value, the RelMeAuth proposal on the microformats wiki, and Google’s Social Graph API. It seems Facebook is supporting rel="me" too.

Using hCard for contact information

Almost every website has an about page with some contact information:

<p>Oli Studholme — <a href="http://oli.jp/">http://oli.jp</a>, or 
<a href="http://twitter.com/boblet">follow me on Twitter (@boblet)</a>.</p>

Unfortunately, adding someone’s contact information to your phone or address book generally involves a lot of copying and pasting. If the data was machine-readable, however, we could use a tool to do that. Let’s add the hCard microformat to this code snippet.

<p class="vcard"><span class="fn">Oli Studholme</span> — 
<a class="url" href="http://oli.jp/">http://oli.jp</a>, or 
<a class="url" href="http://twitter.com/boblet">follow me on Twitter 
(@<span class="nickname">boblet</span>)</a>.</p>

So we’ve added a bunch of classes. There’s nothing special about that, of course, until you realise they're all part of the hCard microformat. The first one is vcard on the containing <p> element, indicating that there's hCard data here. Then we have fn, which stands for full name, url for an associated homepage, and nickname for, well, a nickname.

This is a simple example, and in fact a valid hCard only requires vcard and fn. But hCard has much more depth. We can mark up all kinds of contact-related data: addresses, company information, even a profile photo. For example, we can explicitly specify a given name and family name (this is essential for Chinese, Korean, Japanese and Vietnamese names), even middle names and titles.

<span class="vcard"><span class="fn n" lang="ja"><span class="family-name">
スタッドホルム</span>・<span class="given-name">オリ</span></span></span>

The additional n value is actually required, but can be inferred and therefore omitted for names that follow these patterns (the so-called “implied n optimisation”):

• given-name family-name
• family-name, given-name

So what’s the benefit of this? Well, there are several tools that will convert this hCard-microformatted data into a vcard file we can download and automatically add to our address book. Nifty!

It’s also recognised by Google’s Rich Snippets and Yahoo’s SearchMonkey, useful for the contact information on any company website.

Organisations, addresses, and phone numbers

Smaller company websites often have the company name and contact details in the footer, so let’s briefly see how to do that.

<p class="vcard">
<a class="fn org url" href="http://www.w3.org/Consortium/contact-keio" title="Contact Information for W3C/Keio"><span class="organization-name">W3C</span>/<span class="organization-unit">Keio</span></a><br>
<span class="adr"><a class="extended-address" href="http://www.keio.ac.jp/english/about_keio/campus_info/sfc1.html">Keio University Shonan Fujisawa Campus</a><br>
<span class="street-address">5322 Endo</span>, <span class="locality">Fujisawa city</span>,<br>
<span class="region">Kanagawa prefecture</span> <span class="postal-code">252-8520</span> <b class="country">Japan</b><br>
<span class="tel">Telephone: <span class="value">+81-466-49-1170</span></span><br>
<span class="tel"><span class="type">Fax</span>: <span class="value">+81-466-49-1171</span></span></span>
</p>

W3C/Keio
Keio University Shonan Fujisawa Campus
5322 Endo, Fujisawa city,
Kanagawa prefecture 252-8520 Japan
Telephone: +81-466-49-1170
Fax: +81-466-49-1171

By using fn together with org we can create an hCard for an organisation. Each part of the address is specified (<span>licious!), and we’ve also included a phone number (tel’s default type is voice) and fax number (specifying type and using the value class pattern).

And with Operator, we can add this hCard to our computer’s address book in one click. If you’ve ever manually added an address to your address book, you’ll love this

Using hCalendar for event information

Let’s briefly look at marking up a simple event. Here’s one I’m involved with:

<h3><a href="http://atnd.org/events/5181">WDE-ex Vol.11 —
  Designing for iPad: Our experience so far</a></h3>
<p>July 21st 19:00-20:00 at 
<a href="http://www.apple.com/jp/retail/ginza/map/">Apple Ginza</a>.</p>

Just by reading, we understand the event name, date, time, and location. But this information is difficult for computers to extract. By using the hCard microformat, it will be machine-readable.

<div class="vevent">
  <h3><a class="url summary" href="http://atnd.org/events/5181">
  WDE-ex Vol.11 — Designing for iPad: Our experience so far</a></h3>
  <p><span class="dtstart"><abbr class="value" title="2010-07-21">
  July 21st</abbr> <span class="value">19:00</span></span>-
  <span class="dtend"><span class="value">20:00</span></span> at 
  <a class="location url" href="http://www.apple.com/jp/retail/ginza/map/">
  Apple Ginza</a></p>
</div>

We’ve added vevent on a wrapping element to indicate this is an hCalendar. Events are required to have a summary and a starting time, so we’ve added summary and indicated the starting date and time using dtstart. While historically datetimes were indicated using <abbr title="">, the required ISO 8601 format (for example “2010-07-10T19:01:29”) is very unfriendly to screen readers. Imagine having those numbers read to you! For this reason, the hCalendar specification recommends either breaking the datetime into separate date and time pieces, using the value class pattern, or possibly doing both. The specification is also smart enough to know that if the end datetime dtend is only a time, then it’s on the same day, so we don’t need to specify the date again, although tool support for this is spotty. Finally, we’ve added some URLs, one of which is for the event’s location.

With this data now being machine-readable, we can do things with it. For example, we can add the event to a calendar app with one click.

The rev-based VoteLinks microformat

One of the things that’s been cut in HTML5 is the rev attribute, which was the reverse relationship of rel. On the question of whether microformats should use rev, the microformats wiki states:

The short answer is unfortunately “NO”. Use of “rev” should be avoided. However, VoteLinks’ use of rev has been grandfathered since it was such an early use.

The VoteLinks specification mentioned here allowed us to add vote-for, vote-against, or vote-abstain values to a link via the rev attribute, indicating agreement, disagreement, or indifference (respectively) toward the destination URL. However, as the default state of a link is an implicit vote of agreement, and as the rel-nofollow link microformat is equivalent to vote-abstain, the only one we’re unable to replicate is vote-against (no link? ). I expect that the microformats community will eventually come up with rel-based equivalent names for VoteLinks, but until then you’ll need to avoid this microformat when using HTML5.

The profile attribute

The profile attribute is obsolete in HTML5, as it was determined unnecessary. Currently, microformat profiles are very rarely used in the wild and are not required, so this probably won’t affect you.

Microformats specifications vs HTML5

While microformats using class and rel work fine, some of the new features in HTML5 aren’t supported yet. The Microformats in HTML5 page on the microformats wiki currently begins:

This page is to document future use of microformats in HTML 5. None of the items documented are supported now, and may change upon proper development within the microformats community, or changes in the HTML 5 specification.

This includes the nifty new <time datetime=""> element, which would be perfect for microformat times, such as dtstart and dtend in the hCalendar microformat. It’s also true for adding microformats via microdata rather than class and rel. There has been talk of a general way to map any microformat into microdata, but this hasn’t eventuated as of yet.

Microformats-consuming tools (or, the problem with HTML Tidy)

The microformats wiki’s warning about <time> brings us to another caveat: tool support. Even if <time datetime=""> was valid in the microformats spec, at present none of the microformats tools know to get this information from the datetime="" attribute. Now, you could wrap <time datetime=""> around a microformats dtstart or dtend:

<time datetime="2010-07-21T19:00:00+09:00"><span class="dtstart">
  <abbr class="value" title="2010-07-21">July 21st</abbr>
  <span class="value">19:00
</span></span></time>

However, as the <time datetime=""> data is then not explicitly part of the microformat, doing this isn’t really getting you anywhere, except bloated code-ville.

Worse, H2VX.com — a handy microformats tool allowing you to convert hCard and hCalendar microformats into vcard and ical files for users to add to their address books and calendars, respectively — doesn’t see microformat class names on any new HTML5 elements. That means while we can use HTML 4-based microformats code in HTML5 with no problems, if we want to use H2VX we’ll have to add microformats classes to wrapping elements from HTML 4 (such as <div>s and <span>s), and not on any new HTML5 elements. For example, in the code snippet above, you can’t add class="dtstart" to <time> to remove the wrapping <span class="dtstart">, as then H2VX wouldn’t see dtstart.

Books and DVDs

• Microformats: Empowering Your Markup for Web 2.0 — John Allsopp
  
  Amazon UK
  |
  Amazon US
  |
  Amazon DE
  |
  Amazon JP
  |
  Amazon JP (日本語版)
• Designing with Microformats for a Beautiful Web (DVD) — Andy Clarke
  
  Amazon UK
  |
  Amazon US
  |
  Amazon DE
  |
  Amazon JP
• Microformats Made Simple — Emily P. Lewis and Tantek Celik
  
  Amazon UK
  |
  Amazon US
  |
  Amazon DE
  |
  Amazon JP

CSS we can use

Having said that no browsers support the CSS3 Ruby module yet, there are still a few things we can do to style <ruby> and friends. Default browser styles use font-size and display, so we can safely change these to affect display in both supporting and non-supporting browsers.

If you want to de-emphasise the <rt> ruby text when it’s displayed inline in non-supporting browsers, you could do this via setting the size of <rt> and <rp>, as IE and Webkit do:

rt, rp {font-size: 60%;} /* = Webkit value */

You can also move ruby text and parentheses to after the base text, mimicking non-supporting browser rendering on supporting browsers:

rt, rp {display: inline; font-size: 100%;}

Finally, if you’re brave/foolish, you can implement ruby display yourself via CSS inline-table (CSS with explanation and demonstration (Hiragana.jp)). Note that this currently doesn’t work in Chrome because of a bug with display:inline-table on <ruby> (fixed in trunk), and as you’ll probably need per-browser style tweaks, I recommend against it.

<ruby> in Japanese — furigana and rōmaji

Using <ruby> without <rp>

<ruby>攻殻<rt>こうかく</rt>機動隊<rt>きどうたい</rt></ruby>

Using <ruby> with <rp>

<ruby>攻殻<rp>（</rp><rt>こうかく</rt><rp>）</rp>機動隊<rp>（</rp><rt>きどうたい</rt><rp>）</rp></ruby>

Nested <ruby> for multiple ruby texts

<ruby><ruby>攻<rp>（</rp><rt>こう</rt><rp>）</rp>殻<rp>（</rp><rt>かく</rt><rp>）</rp>機<rp>（</rp><rt>き</rt><rp>）</rp>動<rp>（</rp><rt>どう</rt><rp>）</rp>隊<rp>（</rp><rt>たい</rt><rp>）</rp></ruby><rp>（</rp><rt>Kōkakukidōtai</rt><rp>）</rp></ruby>

<ruby> in Chinese — Pīnyīn and zhùyīn fúhào (bopomofo)

Ruby is used to some extent in China (pīnyīn), and more so in Taiwan (zhùyīn fúhào), especially in textbooks and signage.

Pīnyīn

<p>The <b>Grass mud horse</b> — <ruby>草泥馬<rp>(</rp><rt>Cǎo Ní Mǎ</rt><rp>)</rp></ruby> — is … characterised as “lively, intelligent and tenacious”. However, their existence is said to be threatened by the “river crabs” — <ruby class="styled">河蟹<rp> (</rp><rt>héxiè</rt><rp>) </rp></ruby> — which are invading their habitat.</p>

Zhùyīn fúhào

<ruby><ruby>世<rp>（</rp><rt>ㄕˋ</rt><rp>）</rp>上<rp>（</rp><rt>ㄕㄤˋ</rt><rp>）</rp>無<rp>（</rp><rt>ㄨˊ</rt><rp>）</rp>難<rp>（</rp><rt>ㄋㄢˊ</rt><rp>）</rp>事<rp>（</rp><rt>ㄕˋ</rt><rp>）</rp>只<rp>（</rp><rt>ㄓˇ</rt><rp>）</rp>怕<rp>（</rp><rt>ㄆㄚˋ</rt><rp>）</rp>有<rp>（</rp><rt>ㄧㄡˇ</rt><rp>）</rp>心<rp>（</rp><rt>ㄒㄧㄣ</rt><rp>）</rp>人<rp>（</rp><rt>ㄖㄣˊ</rt><rp>）</rp></ruby><rp> （</rp><rt>Anything can be done with enough perseverance</rt><rp>）</rp></ruby>

Korean ruby

While the use of hanja (kanji) is decreasing in South Korea, they are still used for disambiguation and proper names.

<ruby>한자<rp>(</rp><rt>漢字</rt><rp>)</rp></ruby>

Using <ruby> for English

Not everyone is using East Asian languages, but any short annotation is (theoretically) applicable. While English doesn’t typically have pronunciation guidance, phonetic annotations are used in dictionaries:

<ruby><strong>cromulent</strong> <rp>(</rp><rt>crôm-yü-lənt</rt><rp>)</rp></ruby>

The <i> element

The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose (content whose typical typographic presentation is italicized).

Things that are typically italicised include foreign words (using the attribute lang=""), taxonomic and technical terms, ship names, inline stage directions in a script, some musical notation, and when representing thoughts or hand-written text inline:

Only use <i> when nothing more suitable is available — e.g., <em> for text with stress emphasis, <strong> for text with semantic importance, <cite> for titles in a citation or bibliography, <dfn> for defining a word, and <var> for mathematical variables. Use CSS instead for italicizing blocks of text, such as asides, verse, and (as used here for W3C specification quote) block quotations. Remember to use the class attribute to identify why the element is being used, making it easy to restyle a particular use. You can target lang in CSS using the attribute selector (eg [lang="ja-latn"]).

The <b> element

The <b> element represents a span of text offset from its surrounding content without conveying any extra importance; for example, keywords in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is bold text.

For <b> text that should merely look different, there is no requirement to use font-style: bold; — other styling could include a round-cornered background, larger font size, different color, or formatting such as small caps. For instance, in the script example above, <b class="character"> is used to indicate who’s speaking or narrating.

Text that is bold by typographic convention (and not because it’s more important) could include names in a Hollywood gossip column or the initial text on a complex or traditionally designed page:

Only use <b> when there are no other more suitable elements — e.g., <strong> for text with semantic importance, <em> for emphasized text (text with “stress emphasis”), <h1>–<h6> for titles, and <mark> for highlighted or marked text. Use classes on list items for a tag cloud. To recreate traditional typographic effects, use CSS pseudo-element selectors like :first-line and :first-letter where appropriate. Again, remember to use the class attribute to identify why the element is being used, making it easy to restyle a particular use.

The <em> element

The em element represents a span of text with emphatic stress.

The ‘stress’ being referred to is linguistic. If spoken, this stress would be emphasised pronunciation on a word that can change the nuance of a sentence. For example, “Call a doctor now!” emphasises the importance of calling a doctor, perhaps in reply to someone asking “Should I get a nurse?” In contrast, “Call a doctor now!” emphasises the importance of calling immediately.

Use <strong> instead to indicate importance and <i> when you want italics without implying emphasis. The level of nesting represents the level of emphasis.

The <strong> element

The strong element represents a span of text with strong importance.

Not much more to say really — it’s the <strong> we all know so well. Indicate relative importance by nesting <strong> elements, and use <em> for text with stress emphasis, or <b> for text that is “stylistically offset” or bold without being more important.