Chris Cressman’s blog

On August 22, 2009 at Refresh Doylestown 11, I presented Elemental microformats, part 2. If you missed it, view my presentation slides.

On July 18, 2009 at Refresh Doylestown 10, I presented Elemental microformats, part 1. The following article summarizes that presentation.

Elements & compounds

In a presentation from 2005, Tantek Çelik introduced the concept of HTML compounds, markup patterns composed of more than one HTML element. That terminology has since been extended to microformats. Compound microformats are those that use more than one HTML element, while elemental microformats use only one. At Refresh Doylestown 10, I presented an introduction to elemental microformats.

Extending HTML

Microformats extend HTML using HTML’s built in extension mechanisms. These mechanisms are the META element (in conjunction with the @name and @content attributes) and the @rel, @rev, and @class attributes. Microformats avoid the use of the META element due to problems associated with invisible data. Also, I’m going to leave @class for another discussion, so let’s look at @rel and @rev.

@rel and @rev are used with the A and LINK elements and define relationships between documents. @rel defines the relationship of the linked document (the document indicated by the @href value) to the current document. Consider the following example, which should look familiar.

<link rel="stylesheet" type="text/css" href="styles.css">

In the example above, styles.css is the stylesheet for the current document.

@rev, on the other hand, defines the relationship in the opposite direction—the relationship of the current document to the linked document. Consider the example below.

<link rev="markup" type="text/css" href="styles.css">

This example states that the current document is the markup for styles.css. This example may seem a bit unusual, and in fact, the use of @rev is uncommon. Partly for this reason, @rev has been removed in the current draft of HTML5.

So let’s take a closer look at @rel instead. HTML 4.01 includes several predefined link types (values for @rel and @rev). A brief aside: The authors of HTML 4.01 intended for browsers to discover these link types in use and use them to aid navigation. Personally, I think this could have been a useful feature of HTML, but implementation has been very poor. As far as I know, only Opera will display these links to the user, using the Opera navigation bar.

Returning to microformats, the part of the spec that is of most interest is the following:

“Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details.”

In other words, authors are not limited to the predefined values in the specification. Instead, authors may use any value to describe the relationship of one document to another. The specification suggests using a profile to define author-created values. Although most microformats include such a profile, most authors do not find it necessary to use them.

rel-license

rel-license is a simple microformat that uses a custom @rel value to indicate the license of a web page.

Many web pages already contain a link to a license, typically in the footer. For example:

<p>Licensed under a <a href="http://creativecommons.org/licenses/by/3.0/">Creative Commons Attribution 3.0 license</a>.

The rel-license microformats involves nothing more than adding a @rel attribute set to the value of “license.”

<p>Licensed under a <a rel="license" href="http://creativecommons.org/licenses/by/3.0/">Creative Commons Attribution 3.0 license</a>.

The document you are linking to is now semantically marked up as the license for your web page. So why would anyone want to mark up a license? Well, adding extra semantics to your web pages is generally a good thing. As we make our web pages richer and smarter, clever developers will continue to find ways to leverage the added semantics. However, if you’re using a Creative Commons license, you will benefit from an immediate advantage: improved findabililty of your content for those searching for Creative Commons works.

Creative Commons Search allows users to search Google, Yahoo, Flickr, and other services specifically for resources that are Creative Commons licensed. This is a nice immediate benefit and may just be a precurser to even more SEO and findability improvements to come in the future.

The argument to not use rel-license is harder to make. It’s so easy to add this attribute to your markup, why not do it?

A few additional notes

rel-license is scoped to the page unless it has been rescoped by its container. This means that when you mark up a page with rel-license, you are indicating that the linked license applies to the whole current page (not a portion of the page, nor your entire website). However, there are are certain containers, such as hReview and the HTML 5 SECTION element, that re-scope rel-license to apply to only a portion of the page. This is particularly important for aggregators and feed readers that my display multiple reviews from different sources within one page. Each review should maintain its own license.

Also note that a page may have multiple licenses. Just link to each license, and add rel="license" to each.

Not covered here

I covered a few more details in my original presentation that I will not cover here.

• We reviewed the microformats principles and discussed how rel-license conforms with each.
• I briefly discussed Creative Commons licensing and how to choose a license.
• I covered some HTML and microformats validation tools. See Tantek’s favelets page for some cool validators.
• We discussed how to style rel-license with CSS. View source on example 1 and example 2 for some ideas.

On June 13, 2009 at Refresh Doylestown 9, I presented Introduction to microformats. The following article is the last in a series that summarizes that presentation.

Microformats arose partially as a reaction to the expensive and slow standards process of the W3C and other standards bodies. The microformats community formed to extend HTML by agreeing on a new process that would codify existing markup patterns on the web and solve specific problems that needed immediate solutions.

It is therefore no surprise that the microformats community is a primary resource to first learn microformats and later participate in the development process.

Microformats community

Microformats.org is the microformats community website, featuring a blog, event listings, FAQs, the official microformat specifications, code examples, and links to other resources. The site also links to and explains the primary communication channels: the wiki, the mailing lists, Twitter, and IRC.

The website and wiki are a community effort and have been criticized for not being user friendly (especially to beginners). Fortunately, microformats are a distributed effort, and you can find microformats resources all over the web.

Microformats tags

To find those resources, I recommend viewing or subscribing to microformats tags. For blog posts and other online resources, view the microformats tags on Technorati or Delicious. Find microformats photos on Flickr, and microformats events on Upcoming. Look for a microformats tag for each service you use (and please post them in the comments here) to follow the microformats conversation across the web.

My favorites

I also have a few favorite resources that I’d like to recommend.

Two early and influential books are Microformats by John Allsopp and Using Microformats (PDF only) by Brian Suda. Both are excellent resources that cover specific microformats as well as microformats principles and benefits. Both are excellent beginner’s guides, just be sure to catch up on the value-class-pattern, which was developed after each book was published.

Another great resource for microformats is Andy Clarke. Andy’s blog, For a beautiful web, is currently my favorite destination for web design advice and inspiration. I’ve been learning so much from Andy, including how to best mark up content and use microformats. I’m anxiously looking forward to Andy’s upcoming DVD, Designing with microformats.

Andy’s blog introduced me to Emily Lewis, an excellent writer and microformats advocate. Her Getting Semantic Series has become one of the most well known and recommended tutorials to learn particular microformats. Her clear explanations are particularly helpful for those trying to grasp microformat concepts for the first time. I’m also eagerly awaiting her upcoming microformats book.

Of course, if you are reading this, please consider me a microformats resource as well. Please use the comments below, or get in touch any time.

More

• Part 1
• Part 2: principles
• Part 3: adoption

On June 13, 2009 at Refresh Doylestown 9, I presented Introduction to microformats. The following article is the third in a series that summarizes that presentation.

The web is still new. Microformats are very new. However, microformats have been steadily gaining adoption since 2005, and the community has recently announced several significant gains. As adoption grows, value increases.

Let’s look at email by comparison. If I were the only person with an email address, email would be useless. However, if a few friends started using email, its value to me increases. As more and more people adopt email, it continues to become more useful. Eventually, we reach a point where email is so ubiquitous that it becomes detrimental not to use email. Microformats—or at least some of them—will likely reach a tipping point where adoption increases drastically and their use becomes expected.

Search & browsers

Particularly important to adoption are search and browsers. Semantic markup grew in popularity as authors discovered it would benefit SEO and findability. As microformats continue to provide benefits to SEO and findability, they will grow in the same way. Additionally, microformats will benefit greatly from native browser support. Current browsers require addons or user styles to highlight and/or manipulate microformatted content. It seems inevitable however, that future browsers will natively support microformats in their user interfaces. When this occurs, awareness (and therefore adoption) of microformats will increase.

Current implementations

View a current list of tools and services that produce or consume microformats on the implementations page of the microformats wiki.

More

• Part 1
• Part 2: principles
• Part 4: community & resources

On June 13, 2009 at Refresh Doylestown 9, I presented Introduction to microformats. The following article is the second in a series that summarizes that presentation.

Each microformat is researched, designed, and developed around a set of principles that is central to the microformats ideology. Microformats:

Solve a specific problem.

Microformats are not theoretical or philosophical. They exist to solve real world problems right now.

Start as simple as possible.

Solve simple problems first (with simple solutions). Use a small vocabulary. Microformats must be easy to author and won’t solve all problems. See also the Pareto principle (the 80-20 rule).

Are designed for humans first, machines second.

Don’t change the way we write and present content and data on the web. Keep it human readable. Keep data visible (don’t hide it in the document head or with CSS).

Reuse building blocks from widely adopted standards.

Use standards and conventions that are already in place (hCard properties, for example, are taken directly from the vCard standard).

Are modular and ebeddable.

Simpler (elemental) microformats can be used within more complex (compound) microformats.

Enable and encourage decentralized development, content, and services.

See part 1 for a thorough explanation of how microformats enable distributed services.

More

• Part 1
• Part 3: adoption
• Part 4: community & resources

On June 13, 2009 at Refresh Doylestown 9, I presented Introduction to microformats. The following article is the first in a series that summarizes that presentation.

At Refresh Doylestown 9, we looked at some specific scenarios on today’s web:

• We found information and photos about skateboarding that are free to use and share using Creative Commons Search.
• We found content from all around the web that authors have tagged “skateboarding” using Technorati tags.
• We saw how a browser add-on will let us extract the names and contact information from a list of speakers and add them to our desktop address book.
• We viewed a BarCamp schedule that allowed us to subscribe and sync with our desktop calendar application.
• We talked about increasing the visibility of our reviews on Google.
• We looked at a desktop feed reader that can subscribe directly to an HTML page, rather than a duplicate XML feed.

Each of these scenarios is made possible in part by microformats. Specifically, these examples use (in order) rel-license, rel-tag, hCard, hCalendar, hReview, and hAtom. In each example, microformats help computers understand what has been published.

Definition

HTML allows us to mark up basic structures such as headings, paragraphs, and lists. However, there are many other structures and data types common to the web—names, contact information, and calendar events, to name a few—that are written and marked up in many different ways by many different authors. Microformats are a community, a process, and a set of technologies working together to standardize the way we mark up data and content on the web.

Benefits

Standardizing markup across the web makes our code more human friendly, since particular data and patterns will be easier for developers to recognize, maintain, and manipulate (with CSS and JavaScript, for example). Perhaps more importantly though, standardizing our markup will make our web pages more machine friendly, allowing computers and developers to find, understand, extract, aggregate, and mash up data from different websites across the web.

Using microformats, web data suddenly becomes interoperable with desktop applications. I’ve already mentioned how we can import contact details from the web into our desktop address book app and how we can sync a web calendar with our desktop calendar. This applies to web applications as well. We can mark up locations with hCard to easily plot them on a Google Map. Microformats act as a read-only API that allows developers to mash up data from websites with web and desktop applications.

Another benefit of microformats is distributed services. Instead of relying on centralized services, content creators can publish and maintain their own data on their own websites (to maintain ownership and control). Data can then be discovered and aggregated by a third party. Imagine a service that automatically creates business directories sorted by location or business type. Using microformats, businesses could each mark up their business name and location (hCard) and business type (rel-tag). Software could then crawl the web, recognize those patterns, extract the data, and aggregate it to create the directory. The same process could be applied to distributed reviews, bookmarking services, and classified ads.

Cost

You may realize there are other technologies that could produce benefits similar to microformats. So why would we choose microformats over other solutions? Simple: microformats are inexpensive and work right now.

Microformats produce a high return on investment, because they are very easy to implement. Microformats are nothing more than semantic HTML. Therefore, no special software or technology is required. Developers can leverage their existing skills. Furthermore, everything works now, in current browsers. Other attempts to add more semantics to the web (XML, RDF, the Semantic Web) require developers to learn new technologies and/or wait years for browsers to catch up. Microformats can quickly and easily be retrofitted into existing markup or applied to new projects.

More

• Part 2: principles
• Part 3: adoption
• Part 4: community & resources