h-entry - Microformats Wiki (original) (raw)

h-entry is a simple, open format for content on the web. h-entry is often used with content intended to be syndicated, e.g. blog posts. h-entry is one of several open microformat standards suitable for embedding data in HTML.

h-entry is the microformats2 update to hAtom, in particular its "hentry" root class which itself was based on Atom's "entry" element. For an update to "hfeed" see h-feed.

Status

This is a Living Specification yet mature enough to encourage additional implementations and feedback. This specification has portions that are stable, draft, and proposed. Features are stable unless explicitly labeled draft or proposed, or in draft or proposed sections. Draft and proposed features are likely to change substantively. While substantive changes to stable features are unexpected, it is a living specification subject to substantive change by issues and errata filed in response to implementation experience, requiring consensus among participating implementers as part of an explicit change control process.

Participate

Open Issues

Resolved issues before 2012-246

IRC

Advance the spec by following explicit change control process

License

Per CC0, to the extent possible under law, the editors have waived all copyright and related or neighboring rights to this work. In addition, as of 2025-04-27, the editors have made this specification available under the Open Web Foundation Agreement Version 1.0.

Example

Here is a simple blog post example:

Microformats are amazing

Published by W. Developer on

In which I extoll the virtues of using microformats.

Blah blah blah

Parsed JSON:

{ "items": [ { "type": [ "h-entry" ], "properties": { "name": [ "Microformats are amazing" ], "author": [ { "value": "W. Developer", "type": [ "h-card" ], "properties": { "name": [ "W. Developer" ], "url": [ "http://example.com" ] } } ], "published": [ "2013-06-13 12:00:00" ], "summary": [ "In which I extoll the virtues of using microformats." ], "content": [ { "value": "Blah blah blah", "html": "

Blah blah blah

" } ] } } ] }

Get started

The class h-entry is a root class name that indicates the presence of an h-entry.

p-name, p-author, dt-published and the other h-entry property classnames listed below define properties of the h-entry.

Note: The purpose of an entry is to place it around both the explicitly written content (in the content property or in other specific properties for non-textual content or responses) and whatever else is the context for that content, including properties for when it was published and/or updated, who created it, tags or categorization, and links to what the content is a response to (perhaps with a quoted excerpt) and/or links to syndicated copies.

Properties

h-entry properties, inside an element with class h-entry. All properties are both optional and may have multiple instances, e.g. multiple name, url, photo etc. properties.

Core Properties

The following core h-entry properties have broad consensus and are broadly interoperably published and consumed:

Draft Properties

The following draft properties are in use in the wild (published and consumed), and are under strong consideration, but are not yet part of the core:

Proposed Additions

The following properties are proposed additions based on various use-cases, such as existing link preview markup conventions, but are awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:

The following interpretation is also proposed addition:

Note: As h-entry usage grows to express and consume different kinds of content, we expect additional properties may be proposed and iterated as demonstrated by real-world needs, usage, and interoperability.

Proposing and upgrading

How do you add proposed properties and then upgrade them to draft and then core properties?

See: change control

Property Details

This section is a stub.

p-location

p-location has been re-used from h-event.

FAQ

p-name of a note

venue an entry was posted from

address an entry was posted from

lat long an entry was posted from

dt-published property and HTML5 time element

what is the bare minimum list of required properties on an h-entry

What is the bare minimum list of required properties on an h-entry?

No properties are explicitly required, but in practice a h-entry should have the following properties at a minimum for consumers:

What properties should an h-entry have in addition to the bare minimum?

Beyond the bare minimum, a typical h-entry should have the following as well:

Examples in the wild

Real world in the wild examples of sites and services that publish or consume h-entry:

offline

Validating

Test and validate microformats2 markup in general with:

Implementations

Software implementations that publish or consume h-entry, including themes, plugins, or extensions:

(This section is a stub that needs expansion! In practice, nearly every CMS on every indie web site supports publishing h-entry by default.)

When adding an implementation, please provide and link to its home page and open source repo if any.

Backward Compatibility

Publisher Compatibility

For backward compatibility with legacy hAtom consuming implementations, use hAtom classnames (or rel values) in addition to the more future-proof h-entry properties, for example:

A Tale Of Two Tags

It was the best of visible tags, it was the alternative invisible tags.

The a tag is perhaps the best of HTML, yet its corresponding invisible link tag has uses too.

General

ℹ️ Note: Note: you may use any valid HTML5 elements. The article h1 address time elements are used in the example as semantically richer suggestions, however in general div span work fine too. The time element is special though in that its datetime attribute provides a more author/user friendly way of separating a machine readable ISO8601 datetime from a human readable summary.

The list of equivalent hAtom classnames and rel values is provided below.

Parser Compatibility

Microformats parsers SHOULD detect classic properties only if a classic root class name is found and parse them as microformats2 properties.

If an "h-entry" is found, don't look for an "hentry" on the same element.

Compat root class name: hentry
Properties: (parsed as p- plain text unless otherwise specified):

Proposed: (follow-up in issue #7)

Compat FAQ

What about rel bookmark

Also asked as: Why use an h-entry u-url u-uid for permalinks when I have rel=bookmark?

A: tl;dr: use class="u-url u-uid" instead of rel=bookmark for post permalinks because it's simpler (fewer attributes), and works better across contexts (permalink page, recent posts on home page, collection of posts on archive pages).

rel=bookmark was the old hAtom way of marking up permalinks. Since then two factors have contributed to reducing use of rel inside microformats:

* even though rel=bookmark in particular is article-element / sectioning scoped in HTML5[5], it's a detail that typical authors are not going to remember, and thus it's not good to depend on it for any kind of format.

Why rename entry-title entry-summary entry-content

The entry-* classnames in classic hAtom were prefixed as such due to concerns about vocabulary overlap with the title (as in job title, completely separate semantic) property in hCard and the summary property in hCalendar (see: hAtom FAQ).

Following the simplicity principle, in microformats2, the aforementioned vagueness of title is dealt with by removing it. As name is now used consistently across all vocabularies as the property which “names” the microformat, it makes sense to use it to mark up the name of a post.

Likewise, adding entry- to summary doesn’t add any useful information, and in practice there have been no problems with blog post summaries overlapping with entry summaries, so it makes sense to simplify to summary. The same applies to entry-content simplified to content.

See also: 2012-08-30 IRC conversation.

Work that re-uses or builds upon h-entry:

Background

This work is based on the existing hAtom microformat, and extensive selfdogfooding in the indie web camp community.

change control

Minor editorial changes (e.g. fixing minor typos or punctuation) that do not change and preferably clarify the structure and existing intended meaning may be done by anyone without filing issues, requiring only a sufficient "Summary" description field entry for the edit. More than minor but still purely editorial changes may be made by an editor. Anyone may question such editorial changes by undoing corresponding edits without filing an issue. Any further reversion or iteration on such an editorial change must be done by filing an issue.

For the stable features of this document, substantive issue filing, resolution, and edits may be done by filing an issue and discussing them on the issue and on #microformats IRC with a link to the issue.

Because this is primarily a vocabulary specification, very few issues beyond the list of vocabulary have been filed or required any lengthy discussion. If such a non-trivial issue arises in the future, use the microformats2-parsing change control process to resolve them.

In general, non-vocabulary related features or requirements should be avoided in this specification, e.g. changes to microformats2 syntax must be proposed as microformats2-parsing changes using the microformats2-parsing change control process.

Beyond that, the following requirements must be met for adding or moving features (e.g. properties and values) to proposed, draft, or stable. File an issue to collect necessary citations for the requirements for each property being proposed or upgraded, explain how citations fulfill the requirements for the phase(s), get consensus on both (resolve any implementer objections) in the issue.

Proposed

Proposed features must provide documentation of what specific real world use-cases they are solving, preferably with a link to a step-by-step user scenario, e.g. demonstratable using existing non-standard / single-site / single-implementation tools.

Draft

Draft properties must in addition be published and consumed in the wild on the public web, demonstrate solving the use case for which they were proposed, and should provide citations of real world public web sites publishing and (other sites) consuming them, interoperably.

Stable

Stable features (e.g. Core Properties) must in addition be published and consumed in the wild on multiple sites by multiple implementations (3+ different sites and implementations for publishing and consuming). When a draft property reaches a critical mass of deployment by numerous sites and implementations (far beyond 3+), due to network effects and backward compatibility considerations it effectively becomes stable, since it becomes increasingly difficult to change it in any way and have so many sites and implementations also change.

For creating an entirely new vocabulary, and more details about how to research existing values, properties, document examples in the wild, etc., see the microformats process.

See Also