A Blog Not Limited

As I mentioned a while back, I'm honored to be writing for the new ScriptJunkie. My latest efforts have focused on microformats:

• Simple Semantics with Microformats, Part 1 introduces microformats and looks at XFN
• Simple Semantics with Microformats, Part 2 covers hCard
• Simple Semantics with Microformats, Part 3 details hCalendar
• Simple Semantics with Microformats, Part 4 focuses on combining microfoformats

The last in the series, part 4, also introduces a topic I've never talked or written about (even in my book): HTML5 microdata.

But rather than write an entirely new post on what I think HTML5 and microdata mean for microformats, I figured I'd just share with you some salient information from the the ScriptJunkie article. (Yes. I'm lazy.)

HTML5 & Microformats

Nothing is stopping you from writing microformats in HTML5. Microformats happily live in all versions of HTML 3 and later. But there are a few things to make note:

• HTML5 dropped the rev attribute, which is the attribute VoteLinks uses. As yet, there isn’t a substitute approach, so any instances of VoteLinks will be invalid HTML5.
• HTML5 also dropped the <profile> element. 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.

New Semantic Elements

At one point, some microformats parsers didn’t recognize the new HTML5 structural elements like <nav>, <section> and <article>. And the only way to currently get around this restriction was to add other, recognized elements as your class hooks.

For example, if you had hCard content within <nav>, you’d have to wrap it with a <div> in order to assign the root vcard value.

Fortunately, this isn't really an issue any longer. As I stated in the ScriptJunkie article:

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

• Operator Add-on for Firefox
• Tails Export Add-on for Firefox
• Michromeformats extension for Chrome (* didn’t detect hCalendar)
• Optimus-Microformats Transformer
• Microformats Bookmarklet

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 & Microformats

Straight from ScriptJunkie article:

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.

To get a more practical sense of the differences between microformats and microdata, first consider this hCard example from the article:

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

Now take a look at this same contact information marked up with microdata:

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

As you can see, the syntax isn't terribly different. Like microformats, an attribute (itemprop) is assigned a value based on a vocabulary (specified in itemtype). Even many of the values assigned are identical to those used by microformats.

Picking a Poison

So, which to use? Here's my take from the ScriptJunkie article:

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 …

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 make 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.

Not an Either/Or Proposition

Of course, you don't have to pick one or the other. Microformats and microdata can happily exist together. In fact, because there currently isn’t a way to tie HTML5 microdata to microformats, you have to write both if you want both.

For example, the new <time> element seems like a perfect fit with hCalendar's dtstart and dtend. However, existing parsers don’t recognize the relationship. As such, you have to write both <time> and microformat date values if you want both.

Here's an example from the article, which shows contact information marked up with both microformats and microdata:

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

While that sure is a lot of markup (with o so many redundancies), 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 will get you there.

The Future?

As I wrote in the ScriptJunkie article, 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. This echoes what Jeremy Keith wrote in his HTML5 for Web Designers:

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