• Article

Simple Semantics With Microformats, Part 4

Emily P. Lewis | November 10, 2010

 

In this fourth and final installment of my microformats series, we’ll cover how to use microformats together to give your content even more semantics. You’ll learn practical examples for combining XFN and hCard, as well as hCard and hCalendar.

We’ll finish our journey with a peek at what HTML5 and microdata, in particular, means for microformats.

Combining Microformats

One of my favorite things about microformats is they can be combined to further increase the semantic richness of your content. In fact, several microformats require or recommend the inclusion of other microformats. For example, author information in both hReview and hRecipe (two more microformats indexed for Rich Snippets) should be marked up with hCard.

Before we get started, make sure you first familiarize yourself with:

XFN & hCard

Let’s start with the rel-me (from XFN) and hCard microformats we looked at earlier. The individual hCard example was my own contact information, including a link to my blog. Based on the content, it makes sense to add rel-me to indicate my blog is part of my online identity:

<dl class="vcard">
<dt class="fn"><a href="https://ablognotlimited.com" class="url" rel="me">Emily Lewis</a></dt>
<dd class="title">Web Designer</dd>
<dd class="adr"><span class="locality">Albuquerque</span>, <abbr title="New Mexico" class="region">NM</abbr> <span class="postal-code">87106</span></dd>
</dl>

With the simple addition of rel="me"to the link in my hCard, I get the benefit of providing contact information users can download and I’m supporting my online identity consolidation.

In fact, XFN as a whole makes sense combined with hCards. XFN describes the online social relationships of people and hCard describes those people. Whenever I have an hCard for a person I know, I add our XFN relationship:

<p class="vcard"><a href="https://twitter.com/t" class="fn url" rel="met colleague friend muse">Tantek Çelik</a> was the technical editor of my book, Microformats Made Simple.</p>

hCard & hCalendar

Depending on the content, hCard and hCalendar go well together too. Events are often associated with a venue, and hCard can be used to describe those locations. Consider the SXSW hCalendar example in part 3, which contains location information. Whether you consider the Austin Convention Center to be an organization or a named place, hCard is a perfect fit:

<div class="vevent">
<h1><a href="https://sxsw.com/interactive" class="summary url">SXSW Interactive</a></h1>
<p class="description">Five days of compelling presentations from the brightest minds in emerging technology.</p>
<ul>
<li><span class="dtstart"><span class="value-title" title="2011-03-11"> </span>March 11</span><span class="dtend"><span class="value-title" title="2011-03-15"> </span>-15, 2011</span></li>
<li class="location vcard"><a href="https://www.austinconventioncenter.com" class="fn org url">Austin Convention Center</a></li>
</ul>
</div>

In this example, I just added the vcardroot to class="location" and nested the other relevant hCard classes inside the parent <li>. Without any additional markup and only a few class values, I’m giving machines important meaning for my content and users downloadable contact and event information.

hCard & hCard

One scenario we haven’t covered is a person’s contact information that includes the name of an employer, which is indicated by adding the org value for hCard:

<p class="vcard">My name is <span class="fn">Emily Lewis</span>, and I recently formed my own web design studio <a href="https://emilylewisdesign.com" class="url org">Emily Lewis Design, LLC</a>.</p>

Since hCard describes both people and organizations, I can nest an hCard for my company within the hCard for myself:

<p class="vcard">My name is <span class="fn">Emily Lewis</span>, and I recently formed my own web design studio <a href="https://emilylewisdesign.com" class="org vcard"><span class="fn org">Emily Lewis Design, LLC</span></a>.</p>

HTML5 Considerations

As I was writing this article, HTML5 Doctor posted Extending HTML5 —Microformats. It’s a great read that covers the basics of microformats and discusses some issues with HTML5:

  • HTML5 dropped the rev attribute, which is the attribute the VoteLinks microformat uses to indicate support (or lack of) of a link destination (href). As yet, there isn’t a substitute approach, so any instances of VoteLinks will be invalid HTML5.
  • HTML5 also dropped the <profile> element, which indicates the XMDP of microformats used on a page. Frankly, I suspect I may be the only person who ever used the profile URIs, but if you do too, you’ll need to remove that element from your HTML5 if you want it to validate.
  • There currently isn’t a way to tie HTML5 microdata to microformats. So, while the new <time> element seems like a perfect fit with dtstart and dtend, existing parsers don’t recognize the relationship. As such, you have to write both<time> and microformat date values if you want both.
  • Some microformats parsers don’t recognize the new HTML5 structural elements like <nav>, <section>and <article>. The only way to currently get around this restriction is to add other, recognized elements as your class hooks. For example, if you have hCard content within <article>, you’ll have to wrap it with a <div>in order to assign the root vcard value.

They did a thorough job covering the details, so definitely read it yourself. I do have a few cents of my own, though.

Forget the Extra Markup

I’m sure there are still parsers out there that haven’t updated to recognize the new HTML5 structural elements, many of the ones I use (and mention in this series) have updated.

I’ve been working on an HTML5 site with microformats for a few weeks now, and all of the following machines had no problems* recognizing hCard and hCalendar (or adr and rel-license, for that matter) assigned to <section>, <header>, <footer>, <aside>, <nav> and <article>:

And the H2VX conversion services are currently being updated to work with HTML5 structural elements (give them a try and offer your feedback).

While this is by no means firm proof that the new HTML5 elements and microformats will live happily ever after, it is positive sign that development is moving forward. That’s enough for me to continue adding microformats to whatever markup I’m using to best describe my content, whether that is a <dl>, <p>, <section> or <article>.

Microdata

Microdata is similar to microformats, in that both extend markup to include machine-readable metadata that describes web content. As such, microdata has become the third contender in the “my semantic technology is better than yours” argument that has been waging among microformats and RDFa proponents.

Ultimately, all three are ways to deliver machine-readable semantics. And each is unique, with its own benefits, issues and appropriate use cases.

Microformats are designed for the most common web content. They are built on markup and attributes that are already understood and used now. And they are simple, using pre-defined vocabularies.

Microdata is part of the HTML5 specification. It relies on custom vocabularies and new attributes to apply metadata. And it isn’t necessarily restricted to any particular type of web content; it can describe unique content that isn’t addressed by microformats. Further, microdata annotates the DOM, which can make parsing the metadata easier.

From a publishing perspective, my contact information marked up with hCard:

<dl class="vcard">
<dt class="fn"><a href="https://ablognotlimited.com" class="url">Emily Lewis</a></dt>
<dd class="title">Web Designer</dd>
<dd class="adr"><span class="locality">Albuquerque</span>, <abbr title="New Mexico" class="region">NM</abbr> <span class="postal-code">87106</span></dd>
</dl>

The same content with microdata, using the vocabularies defined for Google Rich Snippets:

<dl itemscope itemtype="https://data-vocabulary.org/Person">
<dt itemprop="name"><a href="https://ablognotlimited.com" itemprop="url">Emily Lewis</a></dt>
<dd itemprop="title">Web Designer</dd>
<dd itemprop="address" itemscope
    itemtype="https://data-vocabulary.org/Address"><span itemprop="locality">Albuquerque</span>, <abbr title="New Mexico" itemprop="region">NM</abbr> <span itemprop="postal-code">87106</span></dd>
</dl>

At first glance, microdata looks more complicated than microformats. But upon closer inspection, the syntax isn’t terribly complex.

Like microformats, an attribute (itemprop) is assigned a particular value based on a vocabulary (specified in itemtype). Even many of the values assigned are identical to those used by microformats. And while I’m not a developer, I can appreciate easier manipulation of the data, thanks to the DOM API.

All of that sounds pretty decent, right? Yet I’m not actively implementing microdata in my HTML5 sites, while I am using microformats all over the place. My reasons are simple and based entirely on what makes sense for me, my clients and my sites:

  • Microformats are still supported in HTML5.
  • Microformats are comparatively more used, which means I have more resources at my disposal for leveraging microformats.
  • There are more broadly-available tools and services that parse and transform microformats.
  • I don’t have to learn anything new to publish microformats.
  • I like using class names that give me both semantics and presentational hooks.

In addition to those more practical reasons, I share Frances Berriman’s feeling that microdata is more than we need:

My gut instinct with microdata is that it’s overcomplicating things. We have RDFa already if you really want to get into the nitty-gritty of machine-readable data and, dare I say it, microformats and good semantic practice for creating shared vocabularies for plain-old semantic HTML.

I also agree with her concerns about microdata’s learning curve. While it is simpler than RDFa, microdata is not as simple microformats. And, based on my experience, people already struggle to get their heads around microformats (not to mention actually write semantic markup). I don’t think a positive step towards getting broader acceptance of semantic metadata is to mark it harder.

None of this is to say that I won’t use microdata or even that microformats are better than microdata. First and foremost, I use microformats for its semantic metadata that is easy for me to understand and use. If microdata ends up offering a better means for achieving semantic metadata, I’ve got no problem making the switch. Until then, microformats work for me now.

One Bird, Two Stones

Of course, microformats and microdata can happily exist together. For example, utilizing both the microformats class values and the microdata properties:

<dl itemscope itemtype="https://data-vocabulary.org/Person" class="vcard">
<dt itemprop="name" class="fn"><a href="https://ablognotlimited.com" itemprop="url" class="url">Emily Lewis</a></dt>
<dd itemprop="title" class="title">Web Designer</dd>
<dd itemprop="address" itemscope itemtype="https://data-vocabulary.org/Address" class="adr"><span itemprop="locality" class="locality">Albuquerque</span>, <abbr title="New Mexico" itemprop="region" class="region">NM</abbr> <span itemprop="postal-code" class="postal-code">87106</span></dd>
</dl>

Although that sure is a lot of markup. Just looking at the redundancies bugs me. But this is where we are now. If you want to take advantage of semantic parsing tools today and be ready for what may come in the future, this approach certainly would work.

As for what’s next, I’m less interested in future-gazing than I am in using what makes sense today … letting the people who write markup decide what parts of the spec actually make it to the web.

What I ultimately believe echoes the ever-pragmatic Jeremy Keith, who wrote in his HTML5 for Web Designers:

What really matters are the native semantics, agreed upon by a community and implemented by browser vendors.

Go Forth & Microformat!

There are many microformats I’ve not covered in this series, not to mention many more class values available for hCard and hCalendar. Still, you are now armed with the basic information and resources to start publishing microformats right away.

They are simple and use what you already know (HTML). You don’t have to spend any money on special software or technology. The learning curve is minimal. And with so little required on your end, you get a pretty good return:

  • User experience enhancements
  • Extensible content
  • Improved findability
  • Workflow efficiencies

Recommended Reading

Now that you are (I hope) inspired to enrich your content with microformats, be sure you enrich your perspective by reading the articles referenced in this series:

Authoring Tools

To help you start publishing microformats now, don’t forget the authoring tools I mentioned in this series. Just remember my previous caveats: Use these with caution, as not all of them have been updated to work with the value class pattern I covered in part 3, and some of them generate horrid markup.

Parsers, Extractors & Transformers

Finally, be sure to try the machines I discussed in this series:

 

About the Author

Emily Lewis is a freelance web designer of the standardista variety, which means she gets geeky about things like semantic markup andCSS, usability and accessibility. As part of her ongoing quest to spread the good word about standards, she writes about web design on her blog, A Blog Not Limited, and is the author of Microformats Made Simple and a contributing author for the HTML5 Cookbook. She’s also a guest writer for Web Standards Sherpa, .net magazine and MIX Online.

In addition to loving all things web, Emily is passionate about community building and knowledge sharing. She co-founded and co-manages Webuquerque, the New Mexico Adobe User Group for Web Professionals, and is a co-host of the The ExpressionEngine Podcast. Emily also speaks at conferences and events all over the country, including SXSW, MIX, In Control, Voices That Matter, New Mexico Technology Council, InterLab and the University of New Mexico.

Find Emily on: