I tend to fixate on little details and can't move on till I find the answer. The latest cause was trying to understand the meaning of the h-prefix in h-cards and other class names in microformats.

The documentation has this to say about prefixing conventions:

• h-* for root class names (e.g. h-card)
• p-* for plain text properties (e.g. p-name)
• u-* for URL properties (e.g. u-photo)
• dt-* for date/time properties (e.g. dt-bday)
• e-* for embedded markup properties (e.g. e-note)

All of the prefixes made sense to me except for h-. Why h- for root and not r-? I'm sure it's in there somewhere, but I couldn't find an explanation in the documention on the microformats website. So, naturally, I turned to that old reliable source of genuine and generally well-edited material: a book.

A lot has changed between microformats and microformats2, one of the big ones being the introduction of the above prefixes, and if I couldn't figure out where the h- came from, I might find it in the original book on the subject by one of the founders of the spec: Brian Suda. And, sure enough, he explains it very clearly:

We took the vCard spec (RFC2426) and mapped it 1 to 1 to properties that could be placed into the HTML class attribute. Since this was in HTML, it made sense to call this new format hCard, "h" for HTML.

So hCard was the original name, and namely an HTML analogue for (and a direct adaptation of) vCard. H stands for HTML.

And in the microformats2 spec, the prefixes are meant to wrangle and make sense of so much that was difficult to remember and parse.

So h- represents the HTML element that serves as the root of the named data type: h-card is the root element for a card containing contact information, h-entry is the root element for an entry in a blog or the like, und so weiter.

An h-card is essentially a block of HTML containing a business card.

There's a lot more to dive into, but that clears up one of those little things that tends to block me from making progress.