A Blog Not Limited

to web design, standards & semantics

Getting Semantic With Microformats, Part 7: Themes & Issues

Nov 20, 2008

Published in


According to what I planned when I introduced this series, we are at the end of this thrilling and exciting journey into the world of microformats.

And after spending all this time reviewing specific implementations of microformats on A Blog Not Limited, I didn't want to just end the series without some sort of conclusion.

But the more I thought about it, the more I realized that I'm not ready to conclude this series. There are still more microformats that I may implement on my blog or other sites that I will want to write about.

So, I've decided this article isn't a conclusion, but more of a reflection on some of the recurring themes and issues I've noticed during my research into microformats.

I'm going to get deep and philosophical with this one.

Well, no, not really. I just love a little tongue–in–cheek pretentiousness.

Series Recap

Before I begin, let's take a look back at what I've already discussed:

  • Indicating link based relationships with the rel attribute in Part 1
  • Extending the rel attribute to indicate social relationships with XFN in Part 2
  • Describing people, places and organizations with hCard in Part 3
  • Describing events and time/date-based activities with hCalendar in Part 4
  • Describing blogs, news and other content for syndication with hAtom in Part 5
  • Describing résumé and CV content with hResume in Part 6

Now that I've done the requisite retrospective (ah, alliteration), let's move on to the themes and issues I've noted during the process of writing this series.

Theme: Semantics

In every article of this series, I mentioned semantics as being one of the primary reasons I'm a fan of microformats.

Don't get me wrong, I love the parsers, search engines, browser tools and the like that utilize microformats.

But, for me, as an XHTML specialist, semantics are hugely important. And microformats enable me to be even more semantic.

The Semantic Web

But I don't think everyone understands semantics as it applies to the web.

There is The Semantic Web:

"… most information on the Web is designed for human consumption, and … the structure of the data is not evident to a robot browsing the web. … the Semantic Web approach instead develops languages for expressing information in a machine processable form."

Tim Berners-Lee

Utlimately, The Semantic Web is simply an extension of our current web, but with better information and meaning (semantics) that will allow computers/machines and humans to work together more effectively.

And while microformats aren't one of The Semantic Web's formal specifications, they do support that goal of machine-human cooperation. In fact, one of the tenets of microformats is "designed for humans first and machines second."

Semantic Markup

Then there are the semantics that I'm generally referring to when I talk about semantics: semantic markup, which is markup that describes what something is instead of what it looks like.

This is an approach to developing with web standards: separating structural information from presentational information.

And in keeping with pretentious (not to mention cheesy) geek-speak, it has even been given an acronym: POSH.

But despite the douchey moniker, this notion of separating structure from presentation (made all the better with validation) is probably one of my favorite concepts in web design/development.

Why is it a favorite of mine? Well, other than being a standard (and, damn, do I love rules when it comes to the web), semantic markup describes the content itself. Not what the content will look like, but what it is.

A list is a <ul>, a paragraph is a <p>, a headline is an <h1>. I'm a natural organizer/categorizer, so this just makes sense to me. I think this way, so I write my markup this way.

But, aside from sating my anal-retentiveness, it has some other benefits too, including one that is associated with The Semantic Web: computers don't care what your web page looks like.

Computers care about the data and information on the page, and being able to identify certain data as headings, for example (which offers an added bonus of organically boosting SEO).

So, with regard to this particular notion of semantics, microformats take it to another level by adding metadata and attributes to markup to provide even more semantic value and structure to web content.

Semantic CSS

Even better, because class values are what define a microformat (a few exceptions relating to the rel and title attributes), microformats support semantic naming conventions in CSS, of which I'm a huge proponent.

From my perspective, if you are going to bother using semantic markup, shouldn't you also consider semantic CSS naming?

For example, why assign a class="rightcolumn" when there's a possibility in the future that the presentation might change so that element isn't on the right any longer?

Instead, assign a class name that describes what the content is (such as class="relatedcontent") and use the CSS selectors to define its presentation.

Microformats do exactly this. The properties and sub-properties of microformats are class values that describe what an element is. For example, entry-title in hAtom.

Issue: Unnecessary Markup

The discussion of semantic markup is a nice segue into an issue I've noticed many people reference as a reason to not use microformats: unnecessary markup.

In fact, this particular "problem" was the focus of a recent article from Andy Clarke: A tribute to Microformats (a reader question answered).

The reader noted about microformats: "They really look like an excessive amount of tags and classes to me."

And when you take a look at some of the examples from the Microformats Wiki, the reader is spot-on:

  1. <div class="vcard">
  2.       <a class="fn org url" href="http://www.commerce.net/">CommerceNet</a>
  3.       <div class="adr">
  4.             <span class="type">Work</span>:
  5.             <div class="street-address">169 University Avenue</div>
  6.             <span class="locality">Palo Alto</span>, <abbr class="region" title="California">CA</abbr> <span class="postal-code">94301</span>
  7.             <div class="country-name">USA</div>
  8.       </div>
  9.       <div class="tel">
  10.             <span class="type">Work</span> +1-650-289-4040
  11.       </div>
  12.       <div class="tel">
  13.             <span class="type">Fax</span> +1-650-289-4041
  14.       </div>
  15.       <div>Email:
  16.             <span class="email">[email protected]</span>
  17.       </div>
  18. </div>

Ack! Divitis! Spanitis!

But as Andy deftly explains (and as I hope I've demonstrated in all of my examples in this series), "you can construct [microformats] using markup elements that are appropriate to the context of the content you're publishing."

And with regard to the reader's comment that there are excessive classes, Andy notes:

"… in the case of mature and widely adopted Microformats such as hCard and hCalendar, each one of these attribute values comes not from the vivid imaginations of the inventors of Microformats, but have been reused from existing, related standards such as vCard and vCalendar. In fact, these attribute values are one–to–one correlations between the two formats and it is this that, for example, makes writing conversion scripts such as Brian Suda's X2V possible."

So, the argument that excessive markup and classes outweigh any benefit of microformats isn't really an argument. It is an issue of ignorance that is, unfortunately, propagated by poor examples of microformat content.

Issue: Accessibility

Another topic that reared its head frequently during this series is accessibility and the fact that some parts of various microformats aren't accessible to screenreaders.

DateTime Design Pattern

Update: 06/02/2009

The datetime design pattern is now deprecated in favor of the value class pattern. See part 8 of this series for more on this new pattern.

I've mentioned the datetime design pattern several times in relation to hCard, hCalendar and hAtom, as well as the accessibility concerns associated with it and the abbr design pattern.

But it needs to be discussed again because this accessibility issue is one of the main reasons folks say they don't use microformats.

First, what is the datetime design pattern?

It is the recommended approach for defining date/time information in a microformat and it utilizes the abbr design pattern:

<abbr class="dtstart" title="2008-11-20T09:00:00">November 20</abbr>–<abbr class="dtend" title="2008-11-22T18:00:00">22</abbr>

You can see that the containing element is an <abbr>, where the contained information is "November 20" and the title attribute value is "2008-11-20T09:00:00".

This pattern was developed to support one of the basic principles of microformats: to design for humans first, machines second. All the while, aiming to provide both human- and machine-readable information.

The logic is that machines — such as web applications — will use the title value, while browsers will display the content contained by <abbr> to humans.


As nice as this pattern seems, it has its problems.

Over a year ago, The Web Standards Project posted hAccessibility, which details a significant accessibility problem with the datetime design pattern using the abbr design pattern: screen readers read/speak title values.

So, where the datetime design pattern indicates putting the machine-readable ISO 8601 date/time information in the title, a screen reader speaks the value literally.

Imagine every time your screen reader came across <abbr title="2008-11-20">, hearing this: "Two thousand eight dash eleven dash twenty." And it is even worse for longer values with time information.

This is, arguably, not human-friendly to those users.

At present, these issues have not been resolved. The WaSP accessibility task force has proposed alternatives to the abbr design pattern, including this one that makes some sense to me:

<span class="dtstart" title="20070312T1700-06">March 12, 2007 at 5 PM, Central Standard Time</span>

No, <span> may not be the most semantic element to use, but semantics are a goal, not an end-all absolute. There are exceptions and the "purity" of semantics isn't more important than the necessity of accessible web content.

Being Right vs. Doing Right

To date, this accessibility issue hasn't been addressed. And the more I learn about microformats, the more I don't understand why.

It seems to me, as an outside observer, there is a greater focus on posturing and "who is right" on this issue, rather than an genuine effort to get it resolved. Just read some of the comments in the WaSP article.

Granted, I completely understand the arguments that <abbr> is the right semantic element to use because the <abbr> title attribute offers an expanded version of the contents the tag contains (opposed to advisory content for the element, as with most tags).

But accessibility on the web (hell, in life) is paramount. It is a right, plain and simple, that people with disabilities get equal access to content.

This, plus the fact that this accessibility issue is one of the major barriers for microformats, is why it should be resolved expeditiously (in fact, I think it should already be resolved). Sadly, it doesn't look like that will happen.

And this only hurts microformats.

Theme: Not Enough Tools = Not Enough Benefit

Another theme I've discovered during this series (and is yet another reason why folks don't implement microformats): there is a dearth of tools that take advantage of microformats.

Now, when I've heard this argument before, I've not seriously considered it. Because I happen to be aware of a bunch of useful tools that aggregate, extract, search, etc. microformats:

Browser Tools
  • Opera recognizes the rel-home microformat when used in the <link> of a document <head>. The browser features a Navigation Toolbar that, when enabled, allows users to navigate to the home page.
  • The cmSiteNavigation Toolbar 0.8 for Firefox (1.5-2.0) recognizes rel-home and displays related web pages of the current web page in a toolbar to aid navigation.
  • The Operator add-on for Firefox recognizes several microformats (rel-tag, hCard, hCalendar) and provides context-specific searching across other web sites, including Amazon, YouTube and Flickr.
  • The Tails Export 0.3.5 add-on for Firefox identifies microformats on a web page (hCard, hCalendar, hReview, xFolk, rel-license) and provides export options. For hCard and hCalendar, it exports the microformat content into .vcf and .ics files, respectively, that can be added to address book and calendar programs.
  • rel-lint is a JavaScript-based bookmarklet that checks for known XFN values and flags those it doesn't recognize.
  • The Safari Microformats plugin is useful for Safari users to identify hCard microformats on a web page and save to address book programs.
  • The browser-independent Microformats Bookmarklet mimics the Safari plug-in functionality for hCard information.
  • Michael Kaply created an hAtom user script for Firefox's Operator add-on. This script adds additional bookmarking functionality for hentry occurrences.
  • Mapanui is a beta bookmarklet that leverages microformats to locate addresses on a map, without leaving the page.
Search Engines & Spiders
  • Yahoo!'s SearchMonkey open platform leverages extracted RDF and microformat content for third-party developers.
  • Google's Social Graph API indexes the web for XFN to help make the web more social and easier to find friends in new places on the web.
  • Yahoo!'s Creative Commons Search filters content based on rel-license.
  • Google, too, offers a search that filters based on rel-license content: "Usage Rights" search.
  • Rubhub is a social search engine where you can submit your site, and it is indexed and compared to other sites in the rubhub index to identify any social relationships.
  • Plaxo's Open Social Graph features a crawler that starts with a URL you enter and searches for rel="me" links to help with identity consolidation.
  • XFN Graph creates spider diagrams of how sites link to each other, providing a visual representation of social relationships between site/blog authors.
  • Technorati Microformats Search searches for hCard and other microformats, including hCalendar and hReview.
Creation Tools
  • XFN 1.1 Creator is a web-based wizard that creates links with proper XFN values, and is available in several languages.
  • MT Blogroll 2.12 Manual is a plug-in for Movable Type that allows you to define XFN relationships for blogroll links.
  • XFN Link Creator is another wizard that create links with XFN values. It also allows you to specify containing markup, as well as title values for links.
  • WordPress Links Manager is configured to allow you to define XFN relationships for blogroll links.
  • WP Microformatted Blogroll 0.2 is a WordPress plugin that outputs microformat-annotated links on your blog.
  • hCard creator is a simple form that generates an hCard from submitted information.
  • hCard microformat validator lets you submit a URL with hCard content, and then validates the properties and sub-properties.
  • The hCalendar Creator, courtesy of the Microformats community, is a form that generates hCalendar markup and properties/sub-properties from information you submit.
  • Both the pnh_mf plugin and JMC_Event_Manager gives you an easy way to add microformat content to your Textpattern blog/site.
  • WordPress, too, has a couple of plugins that help web authors add microformats to their WordPress blogs/sites: Structured Blogging (which is also available for MovableType) and WP-Microformats.
  • Courtesy of WaSP, there is a Dreamweaver microformats extension, which was designed for DW 8, but they say will work for MX and above.
  • The Conference Schedule Creator helps you create a complete conference schedule with all events marked up with hCalendar.
  • WordPress Sandbox theme is a "skeleton" theme that can be used as the foundation for custom WP themes and it supports hAtom.
  • Frances Berriman created an hAtom PHP WordPress loop that can be added to existing WP themes.
  • hResume creator generates an hResume from submitted information.
  • The hResume Project has created an hResume plugin for WordPress.
  • CV Antix is a dynamic, web-based resume/CV builder.
Parsers & Extractors

And these are just a sampling of the resources I've found during my research for this series. There are many more.

What About Joe Six Pack?

So, no question there are resources out there.

But then I did a little informal poll with some fellow web designers/developers to get their opinions about microformats.

Several folks pointed out that while there are tools to help make microformats easier for developers and useful for geeks, there's currently nothing that makes microformats useful to regular folks.

Once I thought about this perspective, I can't help but agree with this particular argument. It is true. My sister has no idea what microformats are and even if I showed her a Firefox extension, she would never use it or even care.

That said, though, I will still use microformats wherever I get an opportunity to do so. Because I believe this lack of what I'll call "common innovation" is partially tied to the fact that microformats themselves aren't broadly used.

If everyone used them in their web sites (appropriately), then there would be more development to support them and demonstrate their benefit to all communities (geek and non-geek).

And while I absolutely hate the movie, the "if you build it, they will come" line from Field of Dreams comes to mind. If more folks used microformats, I think more tools would be developed.

In fact, I think the recent release of the Oomph Microformats Toolkit is a step in this direction.

I recently reviewed Oomph, and I find that it is one of the first microformat tools that makes the presence of microformats on a site apparent to any user, regardless of their browser and/or extensions. Just look in the upper left-hand corner of this site to see it in action.

Theme: RDF vs. Microformats

While I didn't mention RDF once in any articles of this series, I would be negligent if I didn't point out that there is a division among folks who get all geeky with web semantics: RDF is better than microformats and vice versa.

But after doing some research on the topic, I realize this division is just a result of the typical sensationalists and "know-betters" that plague our industry.

They need something to argue about and make themselves feel superior, and the RDF vs. microformats debate is a good platform for such bickering … particularly when these folks don't bother to understand each.

RDF: The Basics

So, let's understand a bit about RDF:

  • RDF is a W3C specification for describing web information, such as title, author, modification date, content, and copyright information.
  • RDF was designed to provide a common way to describe this information so that it could be read and understood by computer applications, but not displayed on a browser to humans.
  • RDF is written in XML so that information can be exchanged between different types of computers using different types of operating systems and application languages.

This is the most superficial of descriptions, but it is apparent (to me, at least) that RDF and microformats share only one thing in common: describing information.

RDF is much more focused on the vision of The Semantic Web.

Microformats, By Comparison

Microformats are not and were never intended to be a replacement for RDF. They have their own place and purpose: adding metadata to web content with existing technologies and standards (XHTML and CSS).

And they are simple to encourage broad use and consumption. RDF, by comparison, is not simple at all … at least from my perspective.

Further, microformats are more concerned with semantic markup than The Semantic Web. Although, I do believe the use of semantic markup can play a role in The Semantic Web by introducing metadata to more people.

So, while you may see these RDF vs. microformats arguments pop up, realize that they are illogical comparisons between apples and oranges.

RDF and microformats are two different things. RDF is a data format for The Semantic Web, while microformats are a design pattern for semantic markup.

Both serve a purpose. Both are valuable.

Issue: Complicated Information

During all of my research for these articles — not to mention the time spent actually implementing the various microformats — the one thing that consistently bothered me was an overwhelming lack of easy–to–understand information, particularly on the Microformats Wiki.

I touched on this frustration in Part 6, but I'm going to mention it again because I'm in a rant sort of mood.

But before I go off bitching about this relatively minor point, I do need to acknowledge that the Wiki is invaluable. Its authors and contributors are largely responsible for my interest in microformats and my ability to implement them.

That said, though, I find the majority of content on the Wiki is far too "techy" for microformats, and the examples (as I mentioned) do not represent "best practices" for semantic markup.

Microformats are intentionally simple. But somehow the content on the Wiki makes them seem far more complicated than necessary.

Also, the Wiki is plagued with outdated information and broken links. Well, edit it then, right? It is a wiki …

True, I should take on some responsibility here. But I barely have the time to write these articles for my own blog.

Maybe I'm naive to assume that the folks behind the Wiki would have some sort of moderator or quality control, but I can't help but feel they have a responsibility to ensure the information on the Wiki is not only updated and correct, but represents the best of microformats (particularly in the code examples).

I have no solution to this particular problem other than to encourage more folks to write about their own experiences with microformats, as I've done. Putting them in practical terms with conversational language, I think, makes microformats far more palatable than the Wiki does.

Also, the Wiki was recently upgraded, so perhaps focus is renewed on this particular resource by the microformats folks.

Theme: I Love Microformats

The main theme that I noticed during the course of this series is that I really do love microformats and plan to use them whenever I have an opportunity to do so because they:

  • Use what I already know (XHTML and CSS)
  • Are easy to implement
  • Add semantic information to my content
  • Have potential for future technologies

The arguments against them — lack of technology and accessibilty — are valid, but, to me, aren't true arguments.

They are hurdles that microformats has to get over, and no reason not to spend the little extra time and effort adding them to markup.

What's Next?

I'm taking a break from these time-intensive microformats articles for a while (not too long, I promise). But I know I'll write a few more.

There are other microformats I'm very interested in, including hReview, xFolk and XOXO. So I'll be looking for opportunities to try those microformats out. And there's no way I'd miss a chance to write about them.

What will I write about next? I have more backend development to do on this blog, which I also plan to write about. I'm also interested in getting this blog (and all the other sites I work on) ready for WCAG 2.0, so I think an accessibility series is around the corner.

Hugs & Kisses

Lastly, I just want to say thanks to everyone who has been reading these articles and participating in the discussion. And thanks to my colleagues who offered their perspective and feedback. Also thanks to folks who contacted me via email and Twitter to let me know how useful these articles have been.

This experience has far exceeded any expectations I had. Not only do I know more about microformats than when I started, I feel honored to have encouraged other people to learn about them.

Update: 1/08/2009

Jan Sládek has translated this article in Czech: Kódujme sémanticky s mikroformáty: náměty a problémy.

HTML5 Cookbook

Interested in HTML5?
Get the Cookbook!

I was a contributing author for HTML5 Cookbook, available for sale on Amazon! Get yours now! (I hear chapters 1, 4 and 5 are particularly good.)

P.S. Don't forget my book Microformats Made Simple is still for sale!


Share the Love

Joe Lewis's Gravatar

Joe Lewis opines:


Once again, nice job! The whole series is a keeper - thanks for posting all this.

Regarding the RDFa: You’re right on with the apples/oranges analogy. They are both fruit however—different fruits in the semantic web salad. It’s good to have a variety…

I think there’s a simple idea for implementation at the RDFa core that might make it seem more simple. In essence, we declare a namespace, i.e. xmlns:dc=“http://purl.org/dc/elements/1.1/, and then we can use all those Dublin Core terms as attributes, i.e. property=“dc:title”. Not valid XHTML, but valid using the XHTML+RDFa doctype. OK its a little more complicated, but there is a payoff in flexibility and versatility. Of course RDFa is a bit like playing guitar: If you can play three chords and grimace musically, you’re perfectly fit to join a rock band. But practice and you can take it as far as you want to go. That probably goes for just about anything, really… ;-)

The way I see it, microformats handle that space where things have a lot of commonality - contacts, events, etc. RDFa picks up where that leaves off and we need that versatility to describe more complex areas of information. But the two don’t need to be exclusive - there is some overlap already (i.e. rel-license), and it should be entirely possible to include both in web markup side by side. My thinking is to try to use RDFa to pick up wherever existing microformats leave off, which will probably make a lot of sense in the scientific context. Ultimately, as our InterLab panel discussed last week, this stuff is trivial to implement will eventually be so common that it’ll be boring after a while. No reason not to start publishing using microformats and RDFa right away!

Emily's Gravatar

Emily responds:


Joe - Thanks so much for adding more to the discussion about RDF (RDFa?). What I know about it is just the very little bit I mentioned in this post.

But it sounds far less complicated than I originally thought, so I will definitely have to spend some time with it.

Sean's Gravatar

Sean opines:


bookmarked for reading later - too busy now, but looking forward to finishing off the series.

Matthew's Gravatar

Matthew opines:


I think the key to making Microformats ‘useful to regular folks’ is not just to expose actions, not data or acronyms, but to tie these actions in with external services.

For example, the ‘MoreFunctionsForAddressBook’ add-on for Thunderbird allows vCards to be imported into the address book. If only it ‘just worked’ when you export the vCard from Firefox by telling it to ‘Open with Thunderbird’!

Another example could be that just as you can set Firefox to use gMail or Yahoo webmail as your default email, it should be possible to export a contact into your webmail contacts list.

Actions like these, and similar ways to seamlessly get hCalendar events into desktop and web calendars/organisers, would be quite helpful for a lot of regular folks!

Great series, by the way - it’s wonderful to see a really practical (yet very readable) explanation of the hows and whys of Microformats.

Unresserm's Gravatar

Unresserm opines:


bath revolves <a >tamsulosin 0.4 mg</a>  pagespurpose belgium <a >proscar 5 mg</a>  scouring gatto <a >protonix tablets</a>  comneal groggily <a >kvinnligt viagra</a>  topicif treo <a >what is omeprazole 20 mg</a>  pagkalihay sneezed <a >viagra eiaculazione precoce</a>  desired fuelwood <a >baclofen</a>  mbaan bonillas <a >naproxen ibuprofen</a>  optimisation burtonfly <a >purchase effexor</a>  alcoholc bullshithow <a >seroquel and weight gain</a>  garages pipeline <a >ibuprofen vs naproxen</a>  rector diddle <a >oestradiol</a>  avenirs depthswith <a >cymbalta overdose</a>  noonor reep <a >prednisone dosage for dogs</a>  naida utagaesou <a >norvasc 10 mg</a>  plead pjordanrp <a >amlodipine maleate</a>  arnhemland newsdominant <a >plavix 75mg</a>  angrylarry concurrence <a >fosamax plus d</a>  jesch sayuran <a >clarithromycin and birth control</a>  herndon anteromedial <a >biaxin xl 500mg</a>

Maddy's Gravatar

Maddy opines:


I appreciate all the efrotfs the microformat people did. But I’m not sure if it is the right way to do it. The semantic world still depends on the browser vendors and as long as they don’t support XML these class attributs are only a remedy to what it realy should look like.

Commenting is not available in this channel entry.

The Coolest Person I Know

Emily Lewis

Yeah, that would be me: .

I'm a freelance web designer of the standardista variety, which means I get excited about things like valid POSH, microformats and accessibility. I ply my trade from my one-person design studio in Albuquerque, New Mexico 87106 USA.

A Blog Not Limited is my personal blog where I pontificate about web design, web standards, semantics and whatever else strikes my fancy. Head on over to Emily Lewis Design if you'd like to see my work or, even better, hire me.


I Tweet, Therefore I Am

Follow @emilylewis on Twitter!