A Blog Not Limited

to web design, standards & semantics

Getting Semantic With Microformats, Part 5: hAtom

Oct 15, 2008

Published in


Over the course of this series, I've discussed the various microformats I've implemented on A Blog Not Limited: rel-based, XFN, hCard and hCalendar.

Now, it's time to talk about the hAtom microformat, which adds semantics and structure to web content that could be syndicated, such as blog posts or news articles.

The History: Atom

The hAtom microformat is based on the Atom XML syndication format.

Different than the 1:1 representations of hCard and hCalendar to vCard and vCalendar, respectively, the hAtom schema isn't an exact reflection of Atom.

Atom is a robust model that provides much more functionality than that needed for content like blog posts. As such, hAtom uses only the minimal elements needed; more of a subset of Atom.

That said, the hAtom properties and sub-properities are based on corresponding elements in the Atom nomenclature.

Microcontent Not Necessarily Syndication

Though hAtom is based on Atom, hAtom itself is not a syndication format. Author and editor of hAtom, David Janes explains:

… hAtom was never intended to be a "syndication format" nor to compete with Atom or RSS. It's simply designed to describe the microcontent on webpages, such as blog posts. We used Atom because it provides a well-defined nomenclature for describing such elements.

So, hAtom isn't exclusively for web content that could be syndicated. However, for the purposes of this article, I will be talking about blog posts, which are typically syndicated.

The Basics

Before getting into the details of hAtom, let's review some foundational rules (similar to those for hCard and hCalendar):

  • Properties and sub-properties are expressed as class values.
  • Because of the relationship with Atom, the specified hAtom properties and sub-properties reflect the concepts of Atom elements.
  • Property and sub-property names are case-sensitive.
  • The "root" property cannot be combined with any of its properties/sub-properties. Thus, <p class="hfeed author"> is invalid.

And, just as with all microformats, the markup used doesn't matter (though it should be both valid and semantic).

Class values (properties/sub-properties) are what define the hAtom microformat.

The Profile

Update: 04/21/2010

Recently, the microformats community completed updates to the profile URIs for all microformats. The correct values have been updated in this article. See my Microformats Profile URIs Updated post for further details.

If you choose to implement hAtom, you should also reference its profile in the <head> of web pages that include the microformat:

<head profile="http://purl.org/uF/hAtom/0.1/http://microformats.org/profile/hatom">

For both hCard and hCalendar, I mentioned the use of the combined profile, which covers all non-draft microformats:

<head profile="http://purl.org/uF/2008/03/http://microformats.org/profile/specs">

However, hAtom is a draft specification and its profile isn't covered in the combined profile. As such, you need to specify its profile explicitly.

If you are also referencing the combined profile, you simply add the hAtom profile (W3C allows multiple profile values, separated by white space):

<head profile="http://purl.org/uF/2008/03/http://microformats.org/profile/specs http://purl.org/uF/hAtom/0.1/http://microformats.org/profile/hatom">

Example: Single Post

Okay, enough of the background. Here's how I'm implementing hAtom on my full article content page:

  1. <div class="hentry">
  2.       <h3 class="entry-title">Web Accessibility Is Important</h3>
  3.       <abbr class="published" title="2008-08-28T13:14:37-07:00">Aug 28, 2008</abbr>
  4.       <p class="category"><a href="http://www.ablognotlimited.com/articles/category/commentaries/" rel="tag">Commentaries</a></p>
  5.       <p><a href="#commentForm" title="Post your own comment">Got something to say?</a></p>
  6.       <div class="entry-content">
  7.             <p>The National Federation of the Blind v. Target lawsuit was settled this past Wednesday on the following key terms:</p>
  8.             …
  9.       </div>
  10.       <dl>
  11.             <dt>Tags:</dt>
  12.                   <dd><a href="http://www.ablognotlimited.com/articles/tag/accessibility/" rel="tag">accessibility</a></dd>
  13.                   <dd><a href="http://www.ablognotlimited.com/articles/tag/standards/" rel="tag">standards</a></dd>
  14.                   <dd><a href="http://www.ablognotlimited.com/articles/tag/web+design/" rel="tag">web design</a></dd>
  15.       </dl>
  16. </div>
Root Property: hfeed

The root of hAtom is hfeed, which can contain one or more entries (in this example, entries are blog posts).

This root property is optional. If it is not included, it is assumed on the page itself, which is what I have done (or rather not done) in the above example.

A given page can have multiple hfeeds, if necessary.

Required Property: hentry

Each entry must be contained by the hentry property. As I mentioned, there can be one or more (unlimited) hentry properties applied.

For this example, there is only one hentry because this implementation is on a page with the full content of a single blog post. I discuss multiple entries later in this article.

Th hentry property contains all of the information about the entry.

Required Sub-Property: entry-title

One of the required sub-properties is entry-title, which indicates the title of the entry.

In my example, I've applied entry-title to an <h3> because, as a title, it makes semantic sense to contain it in a heading.

Required Sub-Property: author

Another required sub-property is author, which indicates the author of the entry.

According to the spec., the content contained by the author sub-property must also be marked up with hCard applied to an <address> element.

Caveat: Don't Display Author Name

However, there are instances, my blog included, where publishers don't care to list the author name.

The spec. accommodates for this situation and allows for it to be excluded from the hentry if the page itself contains hCard information in an <address> element assigned class="author".

This alternative is also explained in the hAtom FAQ.

Because I have this hCard configuration in the footer of all my pages, I exclude author from my hAtom implementations and they are still, technically, valid.

For blogs with multiple authors that do not wish to display author name, there currently isn't a valid alternative. The author content must be in the hentry.

I would imagine a CSS solution to suppress visual display (display:none) in these cases could be acceptable.

Caveat: address With hCard

Yet this brings up another issue: the use of <address> for hCard.

As I mentioned in Part 3, the use of <address> for an hCard is only valid if the hCard is for the document owner. The hCard FAQ further advises against using <address> for hCards other than the document owner.

Therefore, if hAtom entries are authored by someone other than the document owner, <address> wouldn't be the appropriate semantic element to use.

This particular issue is currently being discussed. What has been proposed is to eliminate the <address> requirement.

Required Sub-Property: updated

The updated sub-property is also required, and it indicates the date/time the entry was last updated.

Yet there is a caveat to updated: if this sub-property is not defined, the sub-property published is used to indicate the date/time of entry update.

In my example, you will note I do not include an updated sub-property. I do, however, include published.

Which brings me to …

Optional Sub-Property: published

The optional published sub-property is almost identical to updated in the sense that it reflects date/time information for the entry.

The primary difference, however is that published is specific to the when the entry was first published, whereas updated could be the date of publish or it could subsequent date/times when the entry had been updated.

It is also acceptable to include both published and updated to describe a single element containing date/time information:

<abbr class="published updated" title="2008-08-28T13:14:37-07:00">Aug 28, 2008</abbr>

In my implementations, published alone is acceptable for my purposes (and more semantic, as far as I'm concerned), so that is the sub-property I chose to specify.

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.

For both updated and published, date/time information for hAtom is recommended to be expressed using the datetime design pattern:

<abbr class="published" title="2008-08-28T13:14:37-07:00">Aug 28, 2008</abbr>

This pattern specifies that the containing element is an <abbr> which has a title attribute value that reflects "machine-readable" date/time information while the contained information (and what displays in the browsers) is "human-readable" date/time information.

Further, the datetime design pattern specifies that the title value should be expressed in ISO 8601 format.

Finally, as I've addressed previously, there are accessibility concerns surrounding the datetime design pattern.

To date, these issues have not been addressed, though the microformats community is working towards that goal.

Optional Sub-Property: entry-summary

The entry-summary sub-property is optional. It indicates a summary or extract of the entry. This sub-property can be used an unlimited number of times within hentry.

On my blog I don't create summaries for my articles, so I don't include this sub-property in my hAtom implementations.

Optional Sub-Property: entry-content

Another optional sub-property is entry-content which indicates the full entry content.

In my example, all of my article content is contained by a single <div class="entry-content">. However, the entry-content sub-property can be used an unlimited number of times within an hentry.

Optional: rel-bookmark

hAtom also specifies a rel attribute value to indicate the permalink of the entry: bookmark.

In Part 1 of this series, I talked about rel-based microformats, which are used to indicate the relationship of links (<a>) to the document destination (href).

rel-bookmark is just another example of describing the relationship of a link, however, it is not a microformat on its own. It exists only as part of hAtom to describe the permalink.

In case you aren't aware, permalink is the permanent link/URL for a blog post/article/entry.

With hAtom, you simply add rel="bookmark" to the entry's permalink:

<a href="http://www.ablognotlimited.com/articles/web-accessibility-is-important/" rel="bookmark">Web Accessibility Is Important</a>

You may notice, I don't have a permalink in my first example. This is because I generally follow the rule–of–thumb to not provide an active link to the current page (Nielsen's #10 of the Ten Most Violated Homepage Design Guidelines).

And because rel-bookmark is optional, my hAtom is still technically valid.

If an hentry does not have a permalink indicated, the URL of the page is used. Further, if the hentry has an id attribute defined, that value is appended to the URL to identify individual entries.

Categories by Combining Microformats

I also mentioned the rel-tag microformat in Part 1.

It is added to links (<a>) that indicate what a page — or part of that page — is about. Basically, organization/categorization through "tagging," which is broadly used in blogs.

hAtom takes advantage of rel-tag information (the beauty of combining microformats) that is contained within both hfeed and hentry:

  • Links assigned rel="tag" that appear within an hfeed (remember, this can be excluded and is assumed on the page) but outside of hentry are considered "feed categories."
  • Links assigned rel="tag" that are contained by hentry are considered "entry categories."

In my example, I include rel-tag links within my hentry for both the "Category" link and my "Tags" links:

<p class="category"><a href="http://www.ablognotlimited.com/articles/category/commentaries/" rel="tag">Commentaries</a></p>

<dd><a href="http://www.ablognotlimited.com/articles/tag/web+design/" rel="tag">web design</a></dd>

Note that the rel-tag specification requires that the link destination (href) includes the actual value of the "tag" as the final segment of the URL value. This is known as the "tagspace."

Example: Multiple Posts

Now that I've covered the details of hAtom, I thought I'd also show an example of how it could be implemented beyond a single entry.

On my blog, I've also added hAtom to my home page, which features my three most recent articles:

  1. <div class="hentry">
  2.       <h3 class="entry-title"><a href="http://www.ablognotlimited.com/articles/web-accessibility-is-important/" rel="bookmark">Web Accessibility Is Important</a></h3>
  3.       <abbr class="published" title="2008-08-28T13:14:37-07:00">Aug 28, 2008</abbr>
  4.       <p class="category"><a href="http://www.ablognotlimited.com/articles/category/commentaries/" rel="tag">Commentaries</a></p>
  5.       <div class="entry-content">
  6.             <p>The National Federation of the Blind v. Target lawsuit was settled this past Wednesday on the following key terms:</p>
  7.             …
  8.       </div>
  9.       <p><a href="http://www.ablognotlimited.com/articles/web-accessibility-is-important/" rel="bookmark">Continue Reading</a></p>
  10.       <dl>
  11.             <dt>Tags:</dt>
  12.                   <dd><a href="http://www.ablognotlimited.com/articles/tag/accessibility/" rel="tag">accessibility</a></dd>
  13.                   <dd><a href="http://www.ablognotlimited.com/articles/tag/standards/" rel="tag">standards</a></dd>
  14.                   <dd><a href="http://www.ablognotlimited.com/articles/tag/web+design/" rel="tag">web design</a></dd>
  15.       </dl>
  16. </div>
  17. <div class="hentry">
  18.       <h3 class="entry-title"><a href="http://www.ablognotlimited.com/articles/plateau/" rel="bookmark">Plateau</a></h3>
  19.       <abbr class="published" title="2008-08-27T13:59:51-07:00">Aug 27, 2008</abbr>
  20.       <p class="category"><a href="http://www.ablognotlimited.com/articles/category/commentaries/" rel="tag">Commentaries</a></p>
  21.       <div class="entry-content">
  22.             <p>As I posted previously, I'm doing the one hundred push ups challenge: a six-week program designed to get me able to do 100 consecutive push ups. I am now on my seventh week.</p>
  23.       </div>
  24.       <p><a href="http://www.ablognotlimited.com/articles/plateau/" rel="bookmark">Continue Reading</a></p>
  25.       <dl>
  26.             <dt>Tags:</dt>
  27.                   <dd><a href="http://www.ablognotlimited.com/articles/tag/exercise/" rel="tag">exercise</a></dd>
  28.                   <dd><a href="http://www.ablognotlimited.com/articles/tag/fitness/" rel="tag">fitness</a></dd>
  29.                   <dd><a href="http://www.ablognotlimited.com/articles/tag/push+ups/" rel="tag">push ups</a></dd>
  30.       </dl>
  31. </div>
  32. <div class="hentry">
  33.       <h3 class="entry-title"><a href="http://www.ablognotlimited.com/articles/getting-semantic-with-microformats-introduction/" rel="bookmark">Getting Semantic With Microformats, Introduction</a></h3>
  34.       <abbr class="published" title="2008-09-05T07:05:34-07:00">Sep 5, 2008</abbr>
  35.       <p class="category"><a href="http://www.ablognotlimited.com/articles/category/commentaries/" rel="tag">Commentaries</a></p>
  36.       <div class="entry-content">
  37.             <p>I'm an organizer with a sometimes frustrating need to pay attention to the smallest details.</p>
  38.             …
  39.       </div>
  40.       <p><a href="http://www.ablognotlimited.com/articles/getting-semantic-with-microformats-introduction/" rel="bookmark">Continue Reading</a></p>
  41.       <dl>
  42.             <dt>Tags:</dt>
  43.                   <dd><a href="http://www.ablognotlimited.com/articles/tag/French+translation/" rel="tag">French translation</a></dd>
  44.                   <dd><a href="http://www.ablognotlimited.com/articles/tag/hAtom/" rel="tag">hAtom</a></dd>
  45.                   <dd><a href="http://www.ablognotlimited.com/articles/tag/hCalendar/" rel="tag">hCalendar</a></dd>
  46.                   …
  47.       </dl>
  48. </div>

Notice in this example, that I'm using multiple instances of hentry; one for each individual article.

Also note, I indicate permalinks for each entry (in the links for title and "Continue Reading") since they aren't links to the current page.

Other than those two differences, hAtom is implemented the same as in my first example.

Potential Implementations

Beyond the two examples I've provided here, there are many other possibilities for implementing hAtom:

  • A list of entries that appears on an archive page
  • Search results for entries
  • Bulletin board
  • Comments

I'm considering implementing hAtom on my own archive and search results pages (and maybe even comments, because they need hCard anyway) once I get some free time to modify my markup.

Draft Status

Of all the microformats I've covered in this series, hAtom has been the most difficult. I, personally, suspect this is due to the fact that it is a draft specification.

Basically, the challenges I've encountered are minimal, but slightly frustrating:

  • There's a lot less information available about the specifics of hAtom and its properties/sub-properties.
  • There are several open issues being discussed that make it challenging to implement hAtom (i.e. use of <address>).
  • There are far fewer hAtom tools/resources available, as compared to other microformats.
  • The available hAtom generators and parsers don't appear (to me) to be as up–to–date as the spec. itself. As such, they don't appear to take into account the caveats I've mentioned (i.e. excluding author and rel-bookmark).

Yet, from my perspective, this is to all be expected from a draft specification. It is still being modified, worked on, discussed.

I do not, however, think this means you shouldn't implement hAtom or, at a minimum, become familiar with it. Instead, give it a try and just be aware that the specification is in some state of (relatively minimal) flux.

Tools & Resources

Though I mentioned there are comparatively fewer hAtom tools and resources available, there are some out there:

In the Wild

Even though hAtom is a draft specification, it is being embraced:

And there are still more hAtom examples in the wild.


(X)HTML Syndication

I think one of the coolest benefits of hAtom is its potential for XHTML syndication.

In the list of tools and resources, I mention a couple transformers. These utilize XSLT to transform XHTML with hAtom into XML for an Atom or RSS feed.

This means no need to create or maintain a separate Atom or RSS XML files for syndication. Simply by utilizing hAtom and one of these transformers, the syndication XML is automatically generated.

Try it yourself. All you do is prepend the URL of a page that contains hAtom (i.e. http://www.ablognotlimited.com/) with the URL of one of the transformers (http://transformr.co.uk/hatom/):

<a href="http://transformr.co.uk/hatom/http://www.ablognotlimited.com/">Atom feed for A Blog Not Limited</a>

The subsequent link creates the Atom XML and users select it to subscribe:

Google Reader subscription page for A Blog Not Limited using hAtom transformer

Personally, I've not yet implemented this option on my site, as I have customized RSS feeds for which I don't care to lose the customization. Not to mention, I've yet to even add Atom feeds.

However, these transformations are definitely on my list of functionality to explore for this blog.


You didn't think I'd forget this, did you? Of course not.

By leveraging existing standards (XHTML elements and attributes), microformats add semantic value to web content. And semantics help both humans and machines process, search and understand the web.

Microformats also encourage web standards … standard approaches to marking up content, applying class information, even processes for development.

Semantics are good. Standards are good. Microformats are good.

Coming in Part 6

That concludes my "coverage" of the hAtom draft microformat.

In Getting Semantic With Microformats, Part 6, I will discuss the hResume microformat for résumé and CV information.

Stay tuned!

Update: 12/07/2008

Jan Sládek has translated this article in Czech: Kódujme sémanticky s mikroformáty: hAtom.

Jia Mi has translated this article in Chinese: 使用微格式来丰富网站语义:hAtom.

I don't read Czech or Chinese, so I can't attest for the translations. But the intentions are good, so I'm promoting them.

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

Virginia's Gravatar

Virginia opines:


Mentioned your microformats series on BlogHer.

Emily's Gravatar

Emily responds:


@Virginia - Thank you so much. Truly honored.

And a great post, by the way.

Dan Gayle's Gravatar

Dan Gayle opines:


This is the best basic tutorial on blog microformats markup that I’ve seen. Very well done, and I expect that it will be a standard part of my design repertoire from now on!

Edward Horton's Gravatar

Edward Horton opines:


Due to your great tutorial which was really helpful to me (I tried many, downloaded by <a > rapidshare SE </a> but none made it as clear as yours: I’m not exaggerating!), microformat works extremely well with all my web applications, especially when using firefox operator add-on. It makes it so easy to export data, and bridge applications. Hope to find lots of useful information here in the future!

Brad Graham's Gravatar

Brad Graham opines:


I’m curious if hfeed’s can be nested? For example if you had your “Multiple Posts” content within the entry-content of “Single Post”.

My gut instinct is that you would have to also wrap and hfeed container around each.

Emily's Gravatar

Emily responds:


@Brad - I’m not sure I understand the scenario you are suggesting where it would even make sense to nest hfeeds. However, a quick test shows me that it generates errors in the Optimus validator. So, nope, don’t nest them.

Brad Graham's Gravatar

Brad Graham opines:


@Emily - Let me see if I can clarify. Say you’re on an article detail page and at the bottom of the article you have a list of related articles. For example on this page just after “Spread the Word” you want to list 3 related articles displayed in a similar manner as they are on your homepage.

[div#content]—[div.hfeed] - if I could nest I wouldn’t need this extra div I could merge it with div#content——-[div.hentry] - pages main content—[div.hfeed]——-[div.hentry] - related news——-[div.hentry]——-[div.hentry]

I assume you would need to create a new hfeed context, correct?

Brad Graham's Gravatar

Brad Graham opines:


oops, that didn’t get formatted how as I thought it would. Do I dare risk trying again?

Emily's Gravatar

Emily responds:


@Brad - If I understand your example correctly, I don’t think I would, personally, use hAtom for those related entries. That doesn’t mean you couldn’t, but you would have to accommodate for all the required values (like author, updated/published) and, to me, that just wouldn’t make sense within the context of a blog post.  So, not only would I not nest them (which would be invalid), I wouldn’t take the approach you are describing.

That doesn’t mean you couldn’t if you could really come up with a valid, semantic reasoning for doing so, but you are correct that you can’t nest them.

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!