* '''<code>u-in-reply-to</code>''' - the URL which the h-entry is considered reply to (i.e. doesn’t make sense without context, could show up in comment thread), optionally an embedded [[h-cite]] ([http://indiewebcamp.com/reply-context reply-context]) ([http://waterpigs.co.uk/notes/4V2DjG/ example])

-

The following experimental properties are in use in the wild (published and consumed) but are not yet part of the spec:

+

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

* '''<code>p-comment</code>''' - optionally embedded (or nested?) [[h-cite]](s), each of which is a comment on/reply to the parent h-entry. See [[comment-brainstorming]] ([http://waterpigs.co.uk/notes/4V2DjG/ example])

* '''<code>p-comment</code>''' - optionally embedded (or nested?) [[h-cite]](s), each of which is a comment on/reply to the parent h-entry. See [[comment-brainstorming]] ([http://waterpigs.co.uk/notes/4V2DjG/ example])

* '''<code>u-in-reply-to</code>''' - the URL which the h-entry is considered reply to (i.e. doesn’t make sense without context, could show up in comment thread), optionally an embedded [[h-cite]] ([http://indiewebcamp.com/reply-context reply-context]) ([http://waterpigs.co.uk/notes/4V2DjG/ example])

* '''<code>u-like-of</code>''' - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded [[h-cite]] ([http://barryfrost.com/posts/11 example])

* '''<code>u-like-of</code>''' - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded [[h-cite]] ([http://barryfrost.com/posts/11 example])

* '''<code>u-repost-of</code>''' - the URL which the h-entry is considered a “repost” of. Optionally an embedded [[h-cite]].

* '''<code>u-repost-of</code>''' - the URL which the h-entry is considered a “repost” of. Optionally an embedded [[h-cite]].

* '''<code>u-photo</code>''' - one or more photos that is/are considered the primary content of the entry, unless there is a <code>p-location h-card</code>, which is still considered a "checkin" (i.e. with a photo). Otherwise the presence of a u-photo means the name of the entry should be interpreted as a caption on the photo, and the summary/content should be interpreted as a description of the photo.

* '''<code>u-photo</code>''' - one or more photos that is/are considered the primary content of the entry, unless there is a <code>p-location h-card</code>, which is still considered a "checkin" (i.e. with a photo). Otherwise the presence of a u-photo means the name of the entry should be interpreted as a caption on the photo, and the summary/content should be interpreted as a description of the photo.

-

The following properties are proposed additions based on various existing link preview markup conventions which are ''not'' yet commonly used in the wild (Related: [[link-preview-brainstorming]])

+

=== Proposed Additions ===

+

The following properties are proposed additions based on various use-cases, such as existing [[link-preview-brainstorming|link preview]] markup conventions, but are ''not'' yet used in multiple sites in the wild.

Revision as of 19:19, 31 October 2014

h-entry is a simple, open format for episodic or datestamped 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 draft standards suitable for embedding data in HTML/HTML5.

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 2018-03-19, the editors have made this specification available under the Open Web Foundation Agreement Version 1.0.

Example

Here is a simple blog post example:

<article class="h-entry"><h1class="p-name">Microformats are amazing</h1><p>Published by <aclass="p-author h-card"href="http://example.com">W. Developer</a>
on <time class="dt-published"datetime="2013-06-13 12:00:00">13<sup>th</sup> June 2013</time><pclass="p-summary">In which I extoll the virtues of using microformats.</p><divclass="e-content"><p>Blah blah blah</p></div></article>

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":"<p>Blah blah blah</p>"}]}}]}

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.

u-like-of - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded h-cite (example)

u-repost-of - the URL which the h-entry is considered a “repost” of. Optionally an embedded h-cite.

u-photo - one or more photos that is/are considered the primary content of the entry, unless there is a p-location h-card, which is still considered a "checkin" (i.e. with a photo). Otherwise the presence of a u-photo means the name of the entry should be interpreted as a caption on the photo, and the summary/content should be interpreted as a description of the photo.

Proposed Additions

The following properties are proposed additions based on various use-cases, such as existing link preview markup conventions, but are not yet used in multiple sites in the wild.

u-audio - special u- parsing rules for <audio src> & <source src>

u-video - special u- parsing rules for <video src> & <source src>

The following interpretation is also proposed addition:

if the p-location is also an embedded h-card, the entry is treated as a "checkin".

There is a use-case that has no property yet (or used to but it was repurposed in the wild):

*-* - a representative photo or image for the entry, e.g. primary photo for an article or subject-cropped photo, suitable for use in a link-preview.

p-location

FAQ

p-name of a note

same as the title element on the note permalink post page. When publishing a note on its own permalink post page, the contents of the note are likely abbreviated for the title of the page. The same abbreviation can be used for the p-name.

first sentence of the p-content/e-content property. It may be better for syndication and link-preview purposes to provide just the first sentence of the note as the p-name. Similarly if only a portion of the content is syndicated to other sites, that portion can be marked up as the p-summary.

venue an entry was posted from

How do you indicate a named venue where an entry was posted from? Like a restaurant or park.

address an entry was posted from

How do you indicate the address where an entry was posted from? Like a restaurant or park.

If the address is just part of a named venue, see above, use an h-card

Otherwise use an embedded h-adr microformat on a p-location property value.

lat long an entry was posted from

How do you indicate the latitude and longitude of where an entry was posted from?

If the location has a name in addition to latitude and longitude, see above, use an h-card

Otherwise if there is an address in addition to latitude and longitude, see above, use an h-adr

Otherwise use an embedded h-geo microformat on a p-location property value.

dt-published property and HTML5 time element

Does the dt-published property need to be a time element?

The dt-published property should be a <time> element so that you can take advantage of HTML5's "datetime" property.

This lets you specify a human-readable date in the value of the attribute, and the ISO8601 machine-readable date in the "datetime" property.

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:

name (can be implied)

url (can be implied)

published

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:

content (or summary at least) - especially for structured content. For a plain text note, the content/summary (whichever is used) should be the same as the name, otherwise it will be implied from the text content of the root element.

name - for explicitly named/titled entries. Otherwise the entry is assumed to be a "title-less" note (like a tweet).

Michiel de Jong marks up his profile and notes with h-entry and h-card on michielbdejong.com

Mike Taylor marks up his profile and blog posts with h-card and h-entry on bear.im

Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on erinjo.is

Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on jeena.net

Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on andysylvester.com (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --bw 14:44, 13 March 2014 (UTC))

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:

rel by typically* document scoped in HTML5 - thus making it inappropriate for use in microformats that are aggregated, e.g. a collection of posts on a home page or in monthly archives.

it is easier to always use class names for properties. When formats use two (or more!) attributes in HTML to specify properties, confusion results in lower data quality (of the markup and thus the stuff that is marked up). Thus per the microformats principle of simplicity, in microformats2 we only use class names for properties.

* even though rel=bookmark in particular is article-element / sectioning scoped in HTML5[1], 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.