The History: Atom

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 Janesexplains:

“… 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:

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.

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 bothpublished and updated to describe a single element containing date/time information:

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.

Potential Implementations

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:

WordPress Sandbox theme is a "skeleton" theme that can be used as the foundation for custom WP themes and it supports hAtom.

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 - 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.

@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]

@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.

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.