Chapter 1. Introduction

What Are Microformats?

Microformats are simple, open design patterns based on existing standards that you use to describe common web content, including people, places, events, links, and much more.

Existing standards? Yes. HTML (Hypertext Markup Language) and CSS (Cascading Style Sheets). That’s it. Seriously. No fancy software. No new languages. Just markup and class patterns using two of the most basic building blocks of the web today.

Which is why microformats are so simple and easy-to-use.

Humans first, machines second

The markup and class patterns you use to define microformats are designed for humans first, machines second.

What does that mean? Basically, the content “contained” by microformats is consumed by humans, such as a person’s name as viewed on the web in a browser. From the user’s perspective, web content using microformats is indistinguishable from content without. People just get the content. The microformats are invisible.

But the true power of microformats is the second part. The data patterns of microformats allow machines—computers, user agents, applications, and the like, not The Terminator—to extract that human-readable content for a wide range of uses.

For example, if you use the hCard microformat for a person’s contact information, the Operator plug-in for Mozilla Firefox extracts that contact information and allows the user to save it to his computer’s address book, rather than having to manually copy or type the information.

With microformats, you write your content and markup once, but make it available to a potentially infinite number of uses.

Meaning through semantics

One of the reasons microformats are so simple is they rely on structure. This is something every website already has: structure through markup. Microformats just take it to another level with specifically defined structures for particular web content.

But structure by itself isn’t everything. Semantics are essential to microformats. They give structure meaning through the use of semantic markup and CSS. And we can all use a bit more meaning in our lives, can’t we?

POSH

What is semantic markup? It is markup that describes the content itself, not its presentation. And because geeks love acronyms, semantic markup is also known as POSH (Plain Old Semantic HTML).

This concept is part of today’s web standards that encourage the separation of content from presentation. No more <font> tags. No more <b> tags. No more <tables> for layout.

Instead, semantic markup means using <ul> for a list, <p> for a paragraph, and <h1> for a headline. Meanwhile the presentation, such as bold type or layout, is controlled via CSS.

In addition to being semantic, POSH markup must be valid. All that means is your markup must validate against the assigned DOCTYPE. And there are plenty of tools to help you validate, including the W3C’s (World Wide Web Consortium) Markup Validation Service (http://validator.w3.org/). Couldn’t be easier.

With this book, you won’t just become a microformats master, you’ll also learn about POSH. All of the examples in this book use POSH, and I explain my logic behind the semantic markup used.

And I should mention that all of the examples of and references to markup are XHTML. This is simply my personal preference, not a requirement. If your language of choice is HTML 4, go for it. If you are exploring the forthcoming (I’m using that term loosely) HTML5, no problem. Remember, microformats rely on markup attributes that are inherently supported in all versions of HTML 3 and later.

With all that microformatty and POSHy goodness (and my charming tongue-in-cheek wit) you are really going to get your money’s worth with this book. Lucky you!

Semantic CSS

I’ve mentioned that in POSH, CSS controls presentation. But it’s not just CSS, it’s semantic and valid CSS. Semantic CSS simply extends the notion of describing what the content is (rather than what it will look like), to class and id naming.

For example, rather than assigning class="rightColumn" to a section of related content, you assign class="relatedContent". This helps you account for a future possibility that the presentation of the content changes to be positioned on the left.

It is important to note, though, that the class attribute is part of HTML, not CSS. Further, the use of class in microformats isn’t primarily for presentation purposes. Granted, CSS styling is the most common use of class, but the HTML specification indicates that class has several roles, including for general purpose user-agent processing. It is this general purpose role that drives the use of class in microformats: to add semantic context to web content.

Still, I personally like to think that microformats support the notion of semantic CSS. Each microformat has unique and semantic class names (along with other metadata) that are assigned to markup to describe the content. For example, hCard uses class="url" for a person’s website address. And if you choose to style your content with CSS, these class names give you a semantic hook to do just that.

As for the CSS validation that POSH requires, you simply validate your CSS against the version/profile you are using (just as with your markup). It doesn’t matter whether it is CSS 1 or CSS 3. Whatever you choose to use is fine, as long as it validates. Once again, the W3C offers a CSS validation tool (http://jigsaw.w3.org/) that will validate your CSS against a selected profile. Easy peasy.

Some Background

I’ve talked a bit about semantics, but I feel it is important to distinguish this concept from that of the Semantic Web.

The Semantic Web

The Semantic Web was proposed as a replacement for the current Document or Presentation Web, where content publishers produce two versions of their content: one for human consumption and one, using RDF (Resource Description Framework), for machines.

Sir Tim Berners-Lee, who envisioned the concept, explains:

“. . . 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.” (www.w3.org/DesignIssues/Semantic.html)

Microformats are not a formal specification of the Semantic Web. But because they embrace the idea of information for both humans and machines, they support the Semantic Web’s goal of human and machine consumption. Yet unlike the Semantic Web, which advocates separate machine versions of content, microformats encourage making human-readable content more machine-readable.

Why is machine readability important? Because computers don’t necessarily understand human-readable content. And computers could care less about what your content looks like. Computers care about the data and information on the page, and being able to meaningfully identify that data. Microformats and POSH help with that identification.

For example, a search-engine spider likes to know which content is a headline, and using <h1> gives that content the extra “headline” meaning so the spider can easily identify it. Not to mention, this can offer the bonus of organically boosting your search engine optimization (SEO).

A brief history of microformats

At present, the Semantic Web isn’t fully realized. But that doesn’t mean folks don’t want semantics to enrich web content now. In fact, during the early 2000s, web designers began using semantic HTML (now referred to as POSH), as well as semantic CSS. Then, in 2003, the microformats initiative kicked off with the rel="friend" XFN (XHTML Friends Network) proposal.

The microformats community decided early on that one way toward the Semantic Web was to utilize existing technologies to add semantic value to content. As part of the GMPG (Global Multimedia Protocols Group) work, three HTML attributes were identified that could be utilized for that purpose: class, rel, and rev.

They then defined the core microformats principles, each aimed at ensuring the desired semantics would be created via a controlled, standardized process:

• Solve a specific problem.

• Be as simple as possible.

• Design for humans first, machine second.

• Use widely adopted standards.

• Be modular and embeddable.

• Encourage the “spirit of the web” through decentralization.

And that brings us to today, where we have eight stable, standard microformat specifications:

• hCalendar for events

• hCard for people, places, and organizations

• rel-license for licensed content

• rel-nofollow for limiting user-agent link analysis on hyperlinks

• rel-tag for indicating a link destination is to a page about a keyword (tag) for the current page

• VoteLinks for indicating endorsement, disagreement, or neutrality of the destination of a hyperlink

• XFN for representing human relationships in links

• XOXO (Extensible Open XHTML Outlines) for indicating outlines and blogrolls

We also have 15 draft microformats, (with more being considered all the time):

• adr for specifying address information

• geo for indicating geographic coordinates

• hAtom for content that can be syndicated

• hAudio for audio recordings

• hMedia for publishing images, audio and other media

• hProduct for consumer products

• hRecipe for food and beverage recipes

• hResume for résumés and CVs (curricula vitae)

• hReview for reviews of things like products, services, and businesses

• rel-directory for indicating the destination of a link is a directory listing that contains an entry for the current page

• rel-enclosure for indicating attachments that can be downloaded and cached

• rel-home for specifying the link to a site’s home page

• rel-payment for payment mechanisms

• robots exclusion to indicate page-specific direction for web crawlers on any content

• xFolk for collections of bookmarks

Everyone’s doing it

It’s been six years since the microformats initiative began, and millions of sites are using them:

XFN

• According to Yahoo! SearchMonkey results, there are 445,000,000 web pages using XFN.

• Online identity consolidation services like Plaxo and claimID use XFN to identify online social relationships.

• Google’s Social Graph API (Application Programming Interface) uses XFN for data visualization of social relationships

• Social networks like Twitter, Flickr, and LinkedIn use XFN for friends and followers.

hCard

• Yahoo! SearchMonkey shows 1,370,000,000 results for hCard.

• Google Maps uses hCard, while Google’s Rich Snippets feature leverages hCard to display more contextually-relevant search result information.

• Both Twitter and Last.fm apply hCard to their users’ profile pages.

• Yahoo! Local and MapQuest Local apply hCard to their search results.

• Technorati’s microformats search indexes hCard.

rel-license

• Creative Commons uses rel-license in its generated license markup.

• Both Google and Yahoo! offer search engines that can filter results based on rel-license content.

hReview

• There are 37,200,000 pages using hReview, according to SearchMonkey

• Google’s Rich Snippets use hReview for search result information.

• Cork’d Tasting Notes uses hReview.

• Both Yahoo! Local’s user feedback and ratings apply hReview, as does its broader search results. Yahoo! Tech’s reviews also use hReview.

• Technorati searches for hReview from submitted URLs (Uniform Resource Locators)

hCalendar

• SearchMonkey reports 36,900,000 results for hCard.

• Yahoo! Upcoming uses hCalendar for all events, as do Facebook and Last.fm.

• Event-based search results in Yahoo! Local are marked up with hCalendar. Same with MapQuest Local.

• Technorati also indexes hCalendar information for its microformats search.

And, of course, I use microformats all over my blog, my design portfolio, and my work sites.

The list goes on an on, but I won’t bore you any further. Want to see more microformats in the wild? Go to http://microformats.org/wiki/examples-in-the-wild.

All these microformat implementations are getting you excited, right? You don’t want to be left out in the cold, do you? You want to be one of the cool kids. So get on board and start using microformats today! Do it. Do it. Seriously. Do it.

Core Concepts

Since I know you are now an eager beaver (peer pressure can be quite effective) and want to dive straight into microformats, please be patient as I first cover some of the common elements and core concepts of microformats.

I know, I know, you just want the examples. But trust me. Understanding the foundations of microformats will make it easier for you to conceptualize them once we get into the examples. Really, trust me.

Basic syntax

Let’s start with syntax, and it is going to blow your mind how simple it is.

While I’ve stressed the importance of POSH in microformats, the truth is that markup tags have virtually nothing to do with the syntax of microformats. Do not misunderstand, though. Good, valid, and semantic markup is essential for an effective microformat implementation.

If you are going to bother adding semantic richness to your content with microformats, why dilute that with crap markup? POSH helps ensure that your content has the greatest semantic value possible.

That said, the keys to microformats are classes and other metadata. Technically, you can use any markup as long as the class and attribute values follow the microformats specifications. But really, “any markup” simply isn’t good enough. Be committed to quality and professionalism and use POSH with your microformats. Hell, you should use POSH, period.

So, how about a look at the most basic of microformats, rel-me, which uses the rel attribute in links for identity consolidation (associating one page about a person to other pages about that same person):

<a href="http://www.ablognotlimited.com" rel="me">A Blog Not
Limited</a>

In this example, the addition of rel="me" indicates that the link destination references a page about me or for which I am responsible.

Taking this same content a bit further, let’s look at the basic syntax for hCard:

<p class="vcard"><a href="http://www.ablognotlimited.com"
rel="me" class="fn url">Emily Lewis</a></p>

In this example, I changed the displayed content of the link to be my name. As this is contact information, I added the class value vcard to the <p> to designate the content as contact information.

Next, I added class="fn url" to my link, which indicates that the link destination is my website and the link content is my name. And, you will note, I retained the rel="me" value because you can (and should) combine microformats where it makes sense.

That’s it. A few class values, a rel attribute value, and I’ve got two microformats in action. Is your mind effectively blown? Sweet.

Terminology

Now that I’ve covered the basic syntax, let’s talk terminology.

Elementals and compounds

There are elemental microformats and compound microformats.

Elemental microformats contain a single attribute and value, such as the rel-me microformat I demonstrated earlier. Typically, elementals are used as building blocks for compound microformats.

Compound microformats, such as hCard, are slightly more involved and are comprised of properties and subproperties.

Properties and subproperties

Each compound microformat has a root property, which is assigned to the root markup element containing the content. An example of a root property is the class="vcard" assigned to markup containing contact information (as in my previous example).

Root properties cannot be combined with any other properties. For example, class="vcard fn" would be invalid. Further, root properties are required for each microformat.

In addition to the root property, compound microformats have properties, some of which are required, some of which are optional. The only required property for hCard, for example, is class="fn" to indicate the person’s formatted name. All other properties, such as class="url", are optional.

Compound microformats also have subproperties. In a sense, these are like children of properties. For example, the adr property, which indicates a person’s address, has several subproperties to give even more semantic detail:

And there are other adr subproperties I didn’t include in this example. But subproperties are entirely optional. If you have the content to support them all, then use them all. No limits. But if you don’t, no worries.

However, you do have to use at least one of the subproperties.

A few final points about properties and subproperties. First, they cannot be combined. So, for example, in hCard, class="adr street-address" is incorrect.

And, second, all properties and subproperties are case sensitive, as are all class names in HTML.

XMDP

All microformats have an associated XMDP (XHTML Metadata Profile), which defines the metadata and classes that are specified in the given microformat. And each profile has a unique URI (Uniform Resource Identifier) that is used for referencing it on web pages containing the microformat it defines.

For example, the profile URI for XFN is http://gmpg.org/xfn/11, while the profile URI for hCalendar is http://microformats.org/profile/hcalendar/.

Referencing profiles

To reference a profile on your web page, you simply add the profile attribute to your page’s <head> element:

<head profile="http://gmpg.org/xfn/11">

And if you are using more than one microformat on your page, the W3C allows multiple profile values, separated by a white space. For example, if you have both XFN and hCalendar on your page, you would use this:

<head profile="http://gmpg.org/xfn/11 http://microformats.
org/profile/hcalendar/">

There is also work on a combined profile URI for all microformat specifications. So if you are using more than one stable, formal microformat on your web page, you can use this combined profile, rather than listing all of the individual profiles for each microformat.

For draft microformats, you need to specify the profile for that particular microformat. If you are referencing both draft microformats and stable specifications, you can use the combined profile URI along with the profiles for drafts.

Referencing these profiles in pages that contain microformats is recommended, but not required. This could change in the future, though, so I personally recommend including them by default.

Also, the profile URIs, themselves, are subject to change. In fact, I have it on good authority that some of them will be changing soon. The profiles referenced here and in other chapters reflect the profiles that are valid as of this writing. By the time you are reading this, they could change. So please be diligent and check http://microformats.org/profile/ to see what the most current profile URIs are. Sorry, I can’t see into the future.

Drafts and specifications

I’ve mentioned drafts and specifications a few times already. I suppose it might be helpful to explain these to you.

Formal specifications

What I’ve referred to as microformat specifications are those that are formal and stable. These aren’t going to change. Use them without concern of having to revisit your markup.

An added bonus of using formal microformat specifications is there tends to be much more development of tools to leverage these microformats. This is because they are stable. Developers can write to them without concern of change.

Drafts

Draft microformats, meanwhile, are those that are relatively far along in the specification process but haven’t been formally completed. And that means these can (and probably will) change to some degree before becoming a formal specification.

As such, there can be challenges in implementing drafts:

• Less information about the properties and subproperties of drafts may be available, making comprehension and implementation comparatively more difficult.

• Open, unresolved issues can affect how a draft is implemented, making revisiting markup more likely.

• Fewer tools, such as generators and parsers, are available for drafts. This makes sense, though: why develop a tool when the specification isn’t finalized? Just means more work for the developers.

• What tools are available may not be as up-to-date as the draft itself, making those tools less useful.

What to use

There’s no doubt that you should embrace the formal specifications. But should you use drafts? Personally, I say absolutely! I subscribe to the notion that web technologies are, inherently, moving targets. Maybe slow-moving targets, but subject to change nonetheless. Just consider HTML 4, XHTML, and HTML5.

Specifications evolve to meet changing needs and technologies. Yet that doesn’t mean I won’t implement something in which I strongly believe, like microformats. But that’s me. You decide for yourself.

But at least consider that, to stay ahead in today’s web field, being able to understand and adapt to new and changing technologies separates the wheat from the chaff. You don’t want to be chaff, do you?

Combining microformats

One of the best things about microformats is that they can be easily combined. As long as it makes contextual sense, you should combine microformats whenever possible. This adds more semantic value to your content and gives machines even more data that can be extracted and made available to your users.

In one of my earlier examples, I combined rel-me and hCard. A more involved example combines hCard with hCalendar:

This example describes an event with a time and a date, but I also include content about its location: a restaurant name and address. As such, it makes contextual sense to add hCard information to describe the venue.

Design patterns

The building blocks of microformats are design patterns you use across different specifications. Before diving into specific microformats, you should first understand these patterns. And I’m happy to take you on this exciting, educational journey.

Class design pattern

The class design pattern is the core of microformats. It is the pattern of assigning the requisite class value (property or subproperty) to a semantic element.

That’s it. And you’ve already seen it:

<p class="vcard"><a href="http://www.ablognotlimited.com"
rel="me" class="fn url">Emily Lewis</a></p>

Just in case it is necessary to point out, you can use multiple class values as I’ve done in the above example.

Rel design pattern

Another common pattern is the rel design pattern, which you use to indicate the meaning of hyperlinks. (I’m calling this a pattern, but it’s actually simply using the rel attribute as it was defined in the HTML 4 specification.)

And, just like the class design pattern, you’ve already seen this one in my previous examples:

<a href="http://www.ablognotlimited.com" rel="me">A Blog Not
Limited</a>

That’s all there is to it. Nuff said.

Abbr design pattern

The abbr design pattern takes advantage of the <abbr> element, which, as part of the HTML 4 specification, is used to expand abbreviated content. As part of microformats, <abbr> is frequently applied to short human-readable content for which you want an expanded abbreviation that not only provides more precise human-readable information, but is also useful for machines. To do this, you contain the content with the <abbr> element and define the machine data as the title attribute value, such as for country abbreviations:

<abbr title="United States of America">USA</abbr>

However, microformats discourage the use of the abbr design pattern simply to add more human-friendly content. The logic is that if someone doesn’t want to make his content visible, adding the content “invisibly” shouldn’t be encouraged. Here’s an example:

<abbr title="Emily Lewis">Emily</abbr>

The microformats initiative believes that invisible metadata is unreliable metadata (a lesson learned from the historical failure of <meta> keywords).

Include design pattern

The include design pattern allows you to include a portion of data from one area of a page into another area of the same page. This means you can reuse the content without having to repeat the information.

This pattern is primarily used in the hResume format, which often references multiple hCards for the same person. By utilizing the include design pattern, you don’t have to repeat a person’s name information for every hCard reference, which would go against the accepted and expected content format for résumés.

Here’s how it works in hResume. For the first hCard instance, you assign an id (which, I hope I don’t have to tell you, must be a unique value):

<div class="vcard" id="emily">

Then, in later hCard instances, you add a link assigned class="include" with an href value equal to the id value:

<a class="include" href="#emily">Emily Lewis</a>

The only caveat to this include design pattern is that the link displays in the browser. This isn’t what one would expect to see in a résumé: multiple links of a person’s name. I usually address this problem with CSS to hide the content (via display:none) so that the link doesn’t appear multiple times.

Hiding content via CSS is, generally speaking, a no-no in my book because I feel if the content is there, it should be visible. But there are exceptions to every rule, and I’m nothing if not flexible.

Regardless, this is the recommended include design pattern for micro-formats. There is an alternative approach that utilizes <object>. However, since the <object> include pattern isn’t recommended (due to browser display inconsistencies), I won’t go into detail about it. Go look it up if you must.

Value class pattern

The value class pattern is one of the new patterns in microformats. It is used when only a part of an element’s content is intended as the value of a microformat property. For example, the telephone property in hCard:

<p class="tel"><span class="type">Work</span>: <span
class="value">555-123-4567</span></p>

In this example, class="value" is applied to the segment of content that is the intended machine value for tel.

The value class pattern can also be used when an element’s human-readable content needs to be split up to provide valid machine data, such as localized telephone numbers:

In this example, the content displayed to users includes a 0 to indicate local dialing. However, including the 0 in the machine data makes the number invalid. The solution? Contain the necessary machine data in <span class="value"> elements, and machines know to concatenate the inner text of those elements into a single data string.

Value-title subset

In discussing the datetime design pattern (which uses <abbr> for dates and times), I mentioned some accessibility issues. The primary accessibility concern with the use of <abbr> for dates and times is how screen readers expand title values: sometimes (depending on the screen reader, how it is configured, and so on) they read the full ISO 8601 value, which can be confusing to screen reader users. So, the value class pattern offers the value-title subset for authors who want an alternative to using <abbr> for date and time information.

With the value-title subset, you contain your date and time information with <span class="value-title"> (instead of an <abbr>) which is then assigned an ISO 8601 title value. Parsers can then extract the machine data from the title, not the inner text:

<p class="dtstart"><span class="value-title" title="2009-05-
18T13:00:00">May 18, 2009 at 1pm</span></p>

However, ISO 8601 data in the title attribute of any element displays as a tooltip on browsers. This is a usability challenge for folks who have no idea what ISO 8601 is or why the tooltip is there. Remember, microformats should be invisible to the user.

So another option for the value-title subset relies on an empty <span class="value-title"> assigned the ISO 8601 title value:

Note that the <span> isn’t actually empty. It contains a single space character, but no other content. This eliminates the display of any tooltip on the browser, but machines still get the ISO 8601 data.

Also note that in this empty value-title implementation, the empty <span> immediately follows the parent element, appearing before the human-readable content and without any additional nesting.

And this value-title subset isn’t limited to date-time information. It is also useful for localization purposes, such as telephone types in hCard.

In this example, mobile is displayed to the user, while machines will recognize the requisite hCard property value of cell for the telephone type.

The value class pattern is the most flexible of all microformats patterns because it allows authors to choose which method is ideal for their content and sites.

Furthermore, all of my examples have used <span>s, but that markup element isn’t tied to the value class pattern (or the value-title subset). You can use any element that makes semantic sense, whether it is <strong>, <em>, <p>, etc.

A word of (slight) caution

It is important to realize that this brand-spanking-new pattern is only somewhat supported by machines, though it is gaining traction every day in existing transformers like Optimus (http://microformatique.com/optimus/) and X2V (http://suda.co.uk/projects/X2V/). The rules for parsing this pattern are not completely finalized, nor is the current documentation. However, they are fairly solid.

Still, you should use this pattern with the awareness that future changes to documentation and parsing rules may affect the pages on which you implement it.

Also note that the value class pattern is, perhaps, the most complicated in microformats. The above was just a cursory review. I will go into further detail as it applies to various microformat implementations. Don’t worry, you’ll get this if you haven’t already. Plus, how else am I to ensure that you’ll keep reading?

Global Benefits

I’ve covered a lot about microformats thus far, but I’ve yet to go into much detail about the benefits. Let’s do that now.

While each microformat has its own specific benefits, there are global benefits to microformats in general.

SEO

During my earlier discussion of semantics, I briefly mentioned SEO (search engine optimization). Since this is one area of the web in which many companies are deeply invested, it is worth mentioning again.

Organic SEO can be challenging. It depends on a wide range of factors, not the least of which is quality content. But if you have quality content, you can add even more value with the semantics inherent in microformats.

Let’s consider rel-me and Google. Google likes the extra semantic hook of rel="me" on links because it indicates that the link destination references a page about a person. I use rel-me on my blog, as well as on my design portfolio. And most, if not all, of the social networks I use also assign rel-me to my profile links.

What this tells Google is that all of these pages are about me. So when I search for my name on Google, the sites using rel-me on links to pages about me have a potentially higher page rank than others. And I stress potentially. Page rank is determined by more than just a single semantic addition. But it certainly helps, especially when used with POSH.

And there is no doubt that the two biggest search engines out there, Google and Yahoo!, are embracing microformats to enhance their search results. Google’s Rich Snippets supports microformats and RDFa for content about people (hCard) and reviews (hReview) to provide more information in their search results.

Similarly, Yahoo! SearchMonkey encourages site developers and owners to add microformats to certain content in order to provide enhanced search results in Yahoo! Search Gallery.

Frankly, I think you would be remiss if you didn’t implement (at least) the specific microformats Yahoo! and Google are using to improve their search results.

Extensible data publishing

With microformats, you are essentially publishing your content for multiple uses.

Content by itself supports user access. Adding POSH to the equation gives search engines the semantic value it needs to evaluate that content. Throw microformats into the mix and search engines get even more semantic value. And your users get a potentially unlimited number of ways to utilize that content.

How so? Through the myriad parsers and extractors available that can take microformatted content and convert it to XML (Extensible Markup Language), JSON (JavaScript Object Notation), RSS (Really Simple Syndication), and so on—whatever format in which you want to publish your data. Yet you only have to write the content once.

For example, by using hCard with contact information, you automatically make it possible for that information to be converted into a downloadable vCard, which can then be used by programs such as Microsoft’s Outlook and Apple’s Address Book.

Standards

Microformats encourage standards. And not just today’s web standards regarding semantics and separation of content from presentation, but standards in terms of design and development processes.

Consider a large, and possibly distributed, web team working on an expansive corporate site. If that team uses microformats, they don’t need to discuss how to mark up content. Further, with consistent markup, CSS development is easier and faster. Even better, that team can then extract microformatted content for custom web applications on the site, such as an employee directory that can be downloaded directly from web content.

All of this combined leads to more efficient use of time and resources, which leads to more cost-effective development.

And I’ll say it again: following standards is, at least in my opinion, the benchmark of a true professional who cares about the quality of his work.

Simplicity

I hope I’ve made it apparent already how simple microformats are. If I haven’t, I promise to prove it in the following chapters. For now, take my word for it. They are simple.

But what is the value of this simplicity? Basically, anyone can implement microformats as long as they have a fundamental understanding of XHTML. In fact, you don’t even need to know CSS; you just have to understand the application of class values in markup.

Simplicity also means that microformats have a minimal learning curve, so it doesn’t take a lot of time to grok them and start implementing right away.

Styling hooks

While this may not be a typical “business case” benefit, it is one I think any web designer or front-end developer would appreciate (if it isn’t apparent to them already). Because microformats rely on classes and attributes, they are perfectly suited for easier styling.

How? Microformats already have their own classes (properties and subproperties). You don’t need to create new classes for styling your content; you just use the ones defined in your microformat. Less time is required to think about (semantic) class names, leaving you more time to focus on the styles themselves.

But that doesn’t mean you are restricted to only the classes from microformats. The W3C allows combining class selectors, so you can add as many classes as you like to your microformatted content.

And if you like to define your CSS rules based on elements, rather than declaring rules for specific classes, microformats don’t prohibit you from doing so.

Even better, because several microformats take advantage of XHTML attributes, you can also use CSS attribute selectors to define specific styles based on attributes.

For example, via CSS, you can add an icon to the beginning of links with rel="license", rather than applying a class or, worst case (and perhaps bad practice), adding that icon inline with your markup.

Here’s what that might look like in your CSS:

a[rel~="license"]:before {content: url(copyright.png);}

All of today’s standards-compliant browsers support CSS attribute selectors. Which, obviously, means Microsoft Internet Explorer (IE) 6—the crap browser of the web world—doesn’t. But it is 2009, people. Embrace progressive enhancement and screw IE 6.

Challenges

With the good comes the not-so-good. Despite their simplicity and benefits, microformats have faced some challenges.

Usability and accessibility concerns

When I detailed the datetime design pattern, I mentioned that, historically, it posed one of the arguments against microformats. In fact, the British Broadcasting Company (BBC), which had adopted microformats early on, decided to drop microformats that used this datetime design pattern.

The pattern had two problems. Used in conjunction with the abbr design pattern, the machine-readable ISO 8601 date-time information defined in the title attribute displays as a browser tooltip when users hover over the content. Not everyone understands this ISO 8601 information, so this can pose a usability issue.

And because screen readers read/speak title attribute values, in a screen reader set to expand abbreviations, <abbr title="2008-09-30"> would be read aloud as “two thousand eight dash zero nine dash thirty.” In 2007, the Web Standards Project dubbed this problem “hAccessibility.”

Another common usability concern was related to a lack of localization in the property values used by some microformats. For example, the hCard subproperty values for indicating telephone type (for example, home, cell, work, and so on) are localized for American-English.

If I were to list my cell phone number in my hCard, I would use <span class="type">cell</span>. That is appropriate, since I’m American and that value has meaning to me.

However, British-English refers to cell phones as mobile phones. Yet mobile isn’t a valid value for hCard telephone types, and thus can cause confusion to users.

The good news

With the recent release of the value class pattern, these issues are largely addressed. As developers update their tools and markup to recognize this new pattern, these problems will likely go the way of the dodo bird.

Unnecessary markup?

During my foray into the wonderful world of microformats, I discovered many people blogging and commenting that microformats require unnecessary and excessive markup This is a misperception, although it’s one I think was unintentionally propagated by less-than-ideal examples of microformats.

Case in point is the Microformats Wiki (http://microformats.org/wiki), which is a fount of useful information—but sometimes also a fount of microformat examples that don’t use POSH, instead relying on nonsemantic <div>s and <span>s—markup diseases known as “divitis” and “spanitis.”

The reality is, and I will demonstrate it throughout this book, that microformats can and should rely on clean, semantic markup that is appropriate to the content. <div> and <span> elements are not required for microformats. They work, just like any markup would work, but they are not part of the specifications and are not required.

As for the argument of excessive classes, I think some people (wrongly) believe that the defined class values for microformats can’t be used as CSS hooks, necessitating the use of additional class values. I’ve already explained that they can and should be. No new classes are needed for styling microformats.

All that said, though, there are situations when an extra <span> or <div> may be needed. But that happens in markup development, regardless of the presence of microformats. Can you say <div class="wrap">? It is just a reality of our current markup specifications. Sometimes you need non-semantic elements to achieve presentational goals.

So, if you’re OK with adding a few <div>s or <span>s for presentation, how can you argue intelligently against adding them for semantic richness?

Adoption

The last challenge that I see facing microformats is slow adoption. Personally, I think part of the problem is lack of awareness, but also there aren’t enough tools available that take advantage of microformats. As of this writing, most browsers require plugins or extensions to provide a nice microformats user experience (although both Firefox and Opera have some native support).

These browser plug-ins, scripts, extractors, and parsers, are great tools. But they are mainly known about by geeks—and a comparatively small number of geeks at that. Unfortunately, most everyday users don’t know about or take advantage of browser plug-ins, much less seek custom applications.

What’s the solution? I like to think that if more folks implemented micro-formats on their sites, then browser developers would see the advantage of offering native tools for discovering and working with microformats.

Also, as more people publish microformats, developers have even more structured data to work with and create tools to help publishing and consumption. In fact, this is already happening, with Microsoft’s Oomph Microformats Toolkit (http://visitmix.com/Lab/oomph/).

And as search engines take more and more advantage of the extra semantics microformats offer, they deliver better and more relevant results. This benefits search engine users (which is pretty much everyone), so publishers would be remiss to pass up on an opportunity to make their content more searchable and usable.

This future-gazing isn’t unrealistic. It isn’t even a distant reality. Which is one of the many reasons I choose to implement microformats wherever possible. Maybe by the time you finish this book, you’ll agree with me. And then we can form a club. And get T-shirts.

Why a Book on Microformats?

Yeah, I know, you want to get to the meat of microformats. I get it, I’m impatient too. Go ahead and skip to the next chapter if you just can’t wait any longer. Or, you can indulge me in my explanation of why I wanted to write a book on microformats. Your call, but you will hurt my feelings if you ignore this part.

Microformats are inherently simple. I’ve said it a dozen times already and, by the end of this book, I’ll probably have said it a hundred times. But despite the fact of this simplicity, microformats continue to stump some folks.

Too techy

Why? I think the biggest suspect is that most available information about microformats makes them seem intimidating.

I’ve already touched on the abundance of less-than-ideal examples of microformats on the wiki (I’d normally call them crap examples, but I’m trying to be diplomatic here). But another problem that plagues the wiki is technical jargon.

Every page on the wiki is filled with tons of great information. But the information is described in language that I know I find challenging to comprehend even when my brain is fully functioning (which, sadly, is not often enough).

Lest I sound too negative about the wiki, the community is actively working on interative improvements to the content and examples. So, maybe by the time you read this, many of these criticisms will be addressed (fingers crossed!)

More conversational

Since microformats are so simple, the language used to explain them should be as well. And I’m aiming to do that with this book.

As I hope I’ve already demonstrated, microformats can be explained using conversational, easy-to-understand language and practical examples. And I throw in a bit of humor—ahem, my pathetic attempt at humor—because even I can admit that microformats aren’t necessarily sexy, so discussions about them might need a little extra something to keep your attention.

Practical examples

I also believe that a key to encouraging broader use of microformats is to show the different ways they can be implemented. This book will not only explain each microformat, but also show multiple examples for each using different context and content.

And, of course, all examples will use POSH.

Diplomacy and new developments

Another reason for this book is to talk about microformats diplomatically. Yes, I do love them, but that doesn’t mean that I don’t recognize their issues and limitations. And I believe that talking about these issues and limitations is essential for moving forward and encouraging broader acceptance of microformats.

I also wanted to write about the new developments in microformats that address historical accessibility and usability concerns, namely the value class pattern that I’ve already shared with you.

Finally, I wanted to cover several draft microformats. Even though they aren’t formal specifications, they are invaluable in demonstrating all the different types of content that can benefit from microformats.

I heart microformats

And if you haven’t guessed it by now, I love microformats. They use what I already know. They are easy to implement. They add semantics to my content. They have potential for future technologies. What’s not to love?

So since I love microformats, why not write a book about them? Share my love with the world. Wait, that sounds wrong . . . well, you catch my drift, right?

And that brings us to the end of this chapter. Thanks for sticking around. Now let’s dive into the heart of microformats with some great POSHy examples.