A Blog Not Limited

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.

hAccessibility

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

• Technorati offers an Events Feeds Service and Contacts Feeds Service that transform hCalendar and hCard information into .ics and .vcf files.
• Optimus is robust microformats transformer that supports all microformats and provides a validator.
• Brian Suda's X2V is an XSLT stylesheet that extracts hCalendar and hCard information from a web page to create iCalendar and vCard files, respectively.
• Elias Torres created a hCalendar + Google Calendar Reminders GreaseMonkey script that identifies hCalendar information on a web page and provides an icon to add that event to your Google Calendar.
• There is an hAtom transformer that extracts hAtom from a page so that it can be automatically transformed into the XML for an Atom syndication feed.
• hAtom2Atom uses XSLT to transform hAtom markup into Atom XML.
• There is a remote proxy using hAtom2Atom from Luke Arno, as well as a Chris Casciano's filter script using hAtom2Atom.
• hAtom transcoder is another transformer that not only outputs Atom 1.0, but also RSS 2.0.
• There is a LinkedIn hResume plug-in for WordPress that extracts hResume content from a LinkedIn public profile, which can then be added to a WordPress page.

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.