Microformats Wiki - User contributions [en]

h-entry

2023-11-24T20:53:03Z

Dshanske: /* Properties */

{{DISPLAYTITLE:h-entry}}
<dfn style="font-style:normal;font-weight:bold">h-entry</dfn> 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 [[microformats|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]].

;<span id="status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [[h-entry-issues|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|change control]] process.
;<span id="participate">Participate</span>
:[https://github.com/microformats/h-entry/issues Open Issues]
:[[h-entry-issues|Resolved issues before 2012-246]]
:[[IRC]]
:Advance the spec by following explicit [[#change_control|change control]] process
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
<span style="float:right">__TOC__</span>

== Example ==
Here is a simple blog post example:

<syntaxhighlight lang="html">
<article class="h-entry">
<h1 class="p-name">Microformats are amazing</h1>
<p>Published by <a class="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></p>

<p class="p-summary">In which I extoll the virtues of using microformats.</p>

<div class="e-content">
<p>Blah blah blah</p>
</div>
</article>
</syntaxhighlight>

Parsed JSON:
<syntaxhighlight lang="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>"
}
]
}
}
]
}
</syntaxhighlight>

== Get started ==
The class '''<code>h-entry</code>''' 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 optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

=== Core Properties ===
The following ''core'' h-entry properties have broad consensus and are broadly interoperably published and consumed:
* '''<code>p-name</code>''' - entry name/title
* '''<code>p-summary</code>''' - short entry summary
* '''<code>e-content</code>''' - full content of the entry
* '''<code>dt-published</code>''' - when the entry was published
* '''<code>dt-updated</code>''' - when the entry was updated
* '''<code>p-author</code>''' - who wrote the entry, optionally embedded [[h-card]](s)
* '''<code>p-category</code>''' - entry categories/tags
* '''<code>u-url</code>''' - entry permalink URL
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical entry URL
* '''<code>p-location</code>''' - location the entry was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code id="u-syndication">u-syndication</code>''' - URL(s) of syndicated copies of this post. The property equivalent of [[rel-syndication]] ([http://erinjo.is/2014/checked-into-rockit-colabs-23 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]) ([https://kartikprabhu.com/notes/re-citizen-of-indieweb example])
* '''<code id="p-rsvp">p-rsvp</code>''' (enum, use <data> element or [[value-class-pattern]])
** "yes", "no", "maybe", "interested". Case-insensitive values, normalized to lowercase. Examples:
** <code><nowiki>... <data class="p-rsvp" value="YES">is going</data> to ...</nowiki></code>, or
** <code><nowiki>... <data class="p-rsvp" value="Maybe">might go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="no">unable to go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="interested">am interested/tracking/watching</data> ...</nowiki></code>
* '''<code id="u-like-of">u-like-of</code>''' - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded [[h-cite]]
* '''<code id="u-repost-of">u-repost-of</code>''' - the URL which the h-entry is considered a “repost” of. Optionally an embedded [[h-cite]].

=== 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 id="p-comment">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])
** [https://github.com/microformats/h-entry/issues/20 Issue 20]
* '''<code id="u-photo">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.
** [https://github.com/microformats/h-entry/issues/4 Issue 4: u-photo draft->core bc way more than 3+ pub and consuming impls/sites]
*** depends on: [https://github.com/microformats/h-entry/issues/24 Issue 24: Update Definition of Draft Property u-photo]
*** depends on: [https://github.com/microformats/h-entry/issues/23 Issue 23: E-Content Overlaps with u-photo and similar properties]
** Proposed (issue TBF): A <code>u-photo</code> property MUST be on an element that provides a text description for the image (e.g. <code><img alt=""></code>) UNLESS the image is already described inside the contents a text property such as <code>p-name</code>, <code>p-summary</code>, or <code>e-content</code>
* '''<code id="u-video">u-video</code>''' - special u- parsing rules for <code><video src> & <source src></code>
** [https://github.com/microformats/h-entry/issues/5 Issue 5]

=== 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 awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:
* '''<code>u-audio</code>''' - special u- parsing rules for <code><audio src> & <source src></code>. Examples: [http://transportini.com/ Transportini],[https://indieweb.org/podcast#How_to_podcast_with_h-feed possibly more]
** [https://github.com/microformats/h-entry/issues/6 Issue 6]
* '''<code>u-like</code>''' - similar to p-comment, URL to a like post of the current post, e.g. in a responses list or facepile.
** [https://github.com/microformats/h-entry/issues/31 Issue 32]
* '''<code>u-repost</code>''' - similar to u-like, URL to a repost of the current post, e.g. in a responses list or facepile.
** [https://github.com/microformats/h-entry/issues/30 Issue 30]
* '''<code>u-bookmark-of</code>''' - indicates this h-entry is a bookmark of another URL. Optionally an [[h-cite]]. See [https://indieweb.org/bookmark indieweb.org/bookmark] for examples in the wild.
** [https://github.com/microformats/h-entry/issues/12 Issue 12]
* '''<code>u-featured</code>''' - 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]].
** +1 sknebel: https://github.com/microformats/h-entry/issues/14
* Location Properties - https://github.com/microformats/h-entry/issues/29
** '''<code>p-latitude</code>''' - latitude of the location of the entry
** '''<code>p-longitude</code>''' - longitude of the location of the entry
** '''<code>p-altitude</code>''' - altitude of the location of the entry
* '''<code>p-duration</code>''' - duration of an audio or video file in the entry. https://indieweb.org/duration Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
** [https://github.com/microformats/h-entry/issues/21 Issue 21]
* '''<code>p-size</code>''' - size in bytes of an audio or video file in the entry. https://indieweb.org/size Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>u-listen-of</code>''' - also known as a 'scrobble', indicates this h-entry is a listen of another URL. Optionally an h-cite. https://github.com/microformats/h-entry/issues/11
* '''<code>u-watch-of</code>''' - indicates this h-entry is a watch of another URL, a visual version of the scrobble. Optionally an h-cite. https://github.com/microformats/h-entry/issues/17
* '''<code>p-read-of</code>''' - indicates this h-entry is a read post of some written work (book or other document). The value can be the title of the work or an h-cite. Proposal also mentions <code>u-read-of</code>, where the value would be a URL to the written work or a representative citation page. https://github.com/microformats/h-entry/issues/10
* '''<code>u-translation-of</code>''' - indicates this h-entry is a translation of the linked URL into another language. Can be used in the same way as the existing <code>u-like-of</code> and <code>u-repost-of</code> properties, with just the URL to the original h-entry, or (optionally) contain an embedded <code>h-cite</code>. https://github.com/microformats/h-entry/issues/26
* '''<code>u-checkin</code>''' - the URL of the venue/location h-card which the h-entry is considered a “checkin” of. Optionally an embedded h-card. https://github.com/microformats/h-entry/issues/15
* '''<code>u-review-of</code>''' - the URL which the h-entry is considered a review of, optionally an embedded h-cite, h-card, h-event, or h-item. This could allow retirement of the h-review as unnecessary, in theory.
** [https://github.com/microformats/h-entry/issues/32 Issue 32]

The following interpretation is also proposed addition:
* if the <code>p-location</code> is also an embedded [[h-card]], the entry is treated as a "checkin".
** -1 [[User:Aaronpk|Aaronpk]] 14:22, 19 January 2017 (UTC) [https://aaronparecki.com/2017/01/13/21/ this post] is not a checkin, but has an h-card as the p-location property.

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: [[h-entry#change_control|change control]]

== Property Details ==
This section is a stub.
=== p-location ===
'''<code>p-location</code>''' has been re-used from [[h-event]].

== FAQ ==
=== p-name of a note ===
<div class="discussion">
* '''What is the <code>p-name</code> of a [https://indieweb.org/note note]?'''
** You probably should avoid adding <code>p-name</code> to notes. See https://indieweb.org/note for more discussion of the topic.
</div>

=== venue an entry was posted from ===
<div class="discussion">
* '''How do you indicate a named venue where an entry was posted from? Like a restaurant or park.'''
** Use an embedded [[h-card]] microformat on a <code>p-location</code> property value.
</div>

=== address an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== lat long an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== dt-published property and HTML5 time element ===
<div class="discussion">
* '''Does the dt-published property need to be a time element?'''
** The <code>dt-published</code> property should be a <code><time></code> 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.
</div>

=== 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:
:* <code>url</code>
:* <code>published</code> — if there is no "published" date for the "entry", then reconsider whether it is correct (or worth) marking it up as an entry.

; 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:
:* <code>content</code> (or <code>summary</code> at least) - especially for structured content. For a plain text note, the content/summary (whichever is used) should be the same as the <code>name</code>, otherwise it will be implied from the text content of the root element.
:* <code>name</code> - for explicitly named/titled entries like blog posts and articles. Otherwise the entry is assumed to be a "title-less" [https://indieweb.org/note note] (like a tweet).
:* <code>author</code> - including a nested <code>[[h-card]]</code> with author details like name, photo, url.

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

* ... add uses of h-entry you see in the wild here.
* ind.ie mark up their [https://ind.ie/blog blog] listing and [https://ind.ie/blog/autumn-events-2014/ permalink] pages with h-entry
* David John Mead marks up his profile, blog posts and comments with h-card, h-entry and h-cite on [http://davidjohnmead.com davidjohnmead.com]
* [[User:Brian|Brian Suda]] marks up his blog posts up with h-entry and h-card on [http://optional.is/required/ optional.is]
* Ashton McAllen marks up his blog posts, reposts, comments and likes with h-entry, h-card and h-cite on [http://acegiak.net/ acegiak.net]
* Emma Kuo marks up her blog posts and notes with h-entry and h-card on [http://notenoughneon.com/ notenoughneon.com]
* Scott Jenson marks up his blog posts with h-entry and h-card on [http://jenson.org/ jenson.org]
* Emily McAllen marks up her blog posts with h-entry and h-card on [http://blackwoolholiday.com/ blackwoolholiday.com]
* Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on [https://snarfed.org/ snarfed.org]
* Barry Frost marks up his notes with h-entry, h-card and h-cite on [http://barryfrost.com/ barryfrost.com]
* Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on [http://caseorganic.com/ caseorganic.com]
* Johannes Ernst marks up his blog posts with h-entry on [http://upon2020.com/blog/ upon2020.com]
* Michiel de Jong marks up his profile and notes with h-entry and h-card on [https://michielbdejong.com/ michielbdejong.com]
* Mike Taylor marks up his profile and blog posts with h-card and h-entry on [https://bear.im/bearlog/ bear.im]
* Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on [http://erinjo.is/ erinjo.is]
* Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on [https://jeena.net/ jeena.net]
* Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on [http://andysylvester.com/2014/03/01/howto-setting-up-the-selfoss-feed-reader-with-microformats-support/ andysylvester.com] (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --[[User:Barnabywalters|bw]] 14:44, 13 March 2014 (UTC))
* Chloe Weil marks up her blog posts with h-entry on [http://chloeweil.com/blog chloeweil.com]
* Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on [http://christopheducamp.com/ christopheducamp.com]
* Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on [http://glennjones.net/ glennjones.net]
* Marcus Povey marks up his blog posts and profile with h-entry and h-card on [http://www.marcus-povey.co.uk/ marcus-povey.co.uk]
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* Kyle Mahan marks up his profile and notes with h-card and h-entry on [http://kylewm.com/ kylewm.com]
* Okinawan-lyrics marks up his posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* App.net marks up profile pages and permalink pages with h-entry as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* The Twitter archive browser UI uses h-entry and h-card internally, unfortunately it’s not exposed as HTML in static files anywhere
* Brett Comnes marks up his posts with h-entry and h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like ([http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his posts up with h-card and h-entry, as well as draft u-in-reply-to and experimental u-like properties ([http://sandeep.io/101 example])
* Laurent Eschenauer marks up his posts with h-entry ([http://eschnou.com/entry/first-autonomous-flight-of-my-nodecopter-62-24992.html example])
* Tom Morris marks up his posts using h-entry ([http://tommorris.org/posts/8417 example])
* Numerous newer W3C specs, e.g.
** [http://www.w3.org/TR/2013/CR-css3-values-20130404/ CSS Values and Units Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/CR-css3-conditional-20130404/ CSS Conditional Rules Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/WD-css3-page-20130314/ CSS Paged Media Module Level 3 - 2013-03-14]
** [http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/ CSS Counter Styles Level 3 - 2013-02-21]
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry.
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Aaron Parecki uses h-entry to mark up notes, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-entry on his home page, as well as h-entry on all post permalinks, e.g. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], with [[rel-prev]]/[[rel-next]] (if applicable) to indicate prev/next posts
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-entry on all notes and articles, as well as nested within notes as reply contexts [http://waterpigs.co.uk/notes/1468/ example] and comments [http://waterpigs.co.uk/notes/1482/ example].

=== offline ===
* spreadly marks up share permalink pages with h-entry, as well as minimal h-cards and experimental p-like properties

== Validating ==
* '''[http://indiewebify.me/validate-h-entry/ indiewebify.me h-entry validator]''' parses [[h-entry]] markup, finds common errors and makes suggestions for things to add, with code samples
* '''[http://shrewdness.waterpigs.co.uk/test/ Shrewdness h-entry/h-feed validator]''' shows how shrewdness interprets+displays h-entries, with original source and interim formats, works for single h-entries and feed pages

{{h-spec-section-validating}}

== 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 [https://indieweb.org/ 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.
* [https://gnu.io/social/ GNUsocial] [https://git.gnu.io/gnu/gnu-social/ source code]
* [https://hubzilla.org/hubzilla/ Hubzilla] [https://github.org/redmatrix/hubzilla source code]
* [http://friendica.com/ Friendica] [https://github.org/friendica/friendica source code]
* [http://github.com/dissolve/inkblot InkBlot]
* ...

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

<syntaxhighlight lang="html">
<article class="h-entry hentry">
<h1 class="p-name entry-title">A Tale Of Two Tags</h1>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="e-content entry-content">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
<p>The a tag is perhaps the best of HTML, yet its corresponding invisible link tag has uses too.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>
</syntaxhighlight>

{{note|Note: you may use any valid HTML5 elements. The <code>article h1 address time</code> elements are used in the example as semantically richer suggestions, however in general <code>div span</code> work fine too. The <code>time</code> element is special though in that its <code>datetime</code> 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: <code id="hentry">hentry</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

* <code>entry-title</code> - parse as '''<code>p-name</code>'''
* <code>entry-summary</code> - parse as '''<code>p-summary</code>'''
* <code>entry-content</code> - parse as '''<code>e-content</code>'''
* <code>published</code> - parse as '''dt-'''
* <code>updated</code> - parse as '''dt-'''
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>category</code>
* <code>rel=bookmark</code> - parse as '''<code>u-url</code>'''. While not a class name nor typical microformats property, rel=bookmark was the only way to indicate an hentry permalink. Thus parsers should look for rel=bookmark hyperlinks inside an hentry, and take their "href" value as a value for a '''<code>u-url</code>''' property, including handling any relative URL resolution.
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hentry. Thus parsers should look for rel=tag hyperlinks inside an hentry, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

Proposed: ([https://github.com/microformats/h-entry/issues/7 follow-up in issue #7])
* <code>time.entry-date[datetime]</code> - in the absence of <code>published</code>, parse as '''<code>dt-published</code>'''. parse for the first <code><time></code> element with class name of <code>entry-date</code> and non-empty <code>datetime</code> attribute inside an hentry, if there is no <code>published</code> property, use that time element's <code>datetime</code> attribute value for the <code>dt-published</code> property. Evidence: default WordPress themes 2011-2014([https://wp-themes.com/twentyeleven/][https://wp-themes.com/twentytwelve/][https://wp-themes.com/twentythirteen/][https://wp-themes.com/twentyfourteen/]).
* <code>rel=author</code> - in the absence of <code>author</code>, parse as '''<code>u-author</code>'''. While not a class name nor typical microformats property, rel=author was commonly used to link to an author's URL. Thus parsers should look for rel=author hyperlinks inside an hentry (or even on the same page, preceding the hentry), use the absolute version of it as a value for the '''<code>u-author</code>''' property if there is no "author" property. (citations to "hentry" examples in the wild that <em>depend</em> on rel=author needed to accepted this proposal. Note: default WordPress themes twentyeleven, twentytwelve, twentythirteen, twentyfourteen all use rel=author but only inside class="author vcard", and thus rel=author can be ignored since authorship is already picked up by existing <code>author</code> backcompat parsing.)

=== 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|rel=bookmark]]?''

A: tl;dr: use <code>class="u-url u-uid"</code> instead of <code>rel=bookmark</code> 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.

<nowiki>*</nowiki> even though rel=bookmark in particular is article-element / sectioning scoped in HTML5[http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-bookmark], 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 <code>entry-*</code> 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#Could_hAtom_instead_use_title_content_and_summary|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: [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-128 2012-08-30 IRC conversation].

== Related Work ==
Work that re-uses or builds upon h-entry:
* [https://mailpile.pagekite.me:8080/p/Open_Message_Format Mailpile Open Message Format] is using h-entry with structured properties, e.g. p-author h-card.

== Background ==
This work is based on the existing [[hAtom]] microformat, and extensive selfdogfooding in the [http://indiewebcamp.com 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 [[h-entry-issues|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|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|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_Additions|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|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|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 ==
* [[h-feed]]
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-geo]]
* [[hCard]]

[[Category:Specifications]]

h-recipe

2022-10-06T02:12:11Z

Dshanske: /* Properties */

{{DISPLAYTITLE:h-recipe}}
<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-recipe</dfn> is a simple, open format for publishing recipes on the web. h-recipe is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-recipe is the [[microformats2]] update to [[hRecipe]].

{{cc0-owfa-license}}

== Example ==
Here is a simple minimal recipe example:

<source lang=html4strict>
<article class="h-recipe">
<h1 class="p-name">Bagels</h1>

<ul>
<li class="p-ingredient">Flour</li>
<li class="p-ingredient">Sugar</li>
<li class="p-ingredient">Yeast</li>
</ul>

<p>Takes <time class="dt-duration" datetime="1H">1 hour</time>,
serves <data class="p-yield" value="4">four people</data>.</p>

<div class="e-instructions">
<ol>
<li>Start by mixing all the ingredients together.</li>
</ol>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-recipe"
],
"properties": {
"name": [
"Bagels"
],
"ingredient": [
"Flour",
"Sugar",
"Yeast"
],
"yield": [
"4"
],
"instructions": [
{
"value": "Start by mixing all the ingredients together.",
"html": "<ol> <li>Start by mixing all the ingredients together.</li> </ol>"
}
]
}
}
]
}
</source>

=== Get started ===
The class '''<code>h-recipe</code>''' is a ''root class name'' that indicates the presence of an h-recipe.

'''p-name''', '''e-instructions''', '''p-ingredient''' and the other property classnames listed below define elements as ''properties'' of the h-recipe.

See [[microformats-2-parsing]] to learn more about property classnames.

== Properties ==

=== Core Properties ===

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

h-recipe properties, inside an element with class '''h-recipe''':

* '''<code>p-name</code>''' - the name of the recipe
* '''<code>p-ingredient</code>''' - describes one or more ingredients used in the recipe.
* '''<code>p-yield</code>''' - Specifies the quantity produced by the recipe, like how many persons it satisfyies
* '''<code>e-instructions</code>''' - the method of the recipe.
* '''<code>dt-duration</code>''' - the time it takes to prepare the meal described by the recipe.
* '''<code>u-photo</code>''' - an accompanying image

=== Experimental properties with wide adoption ===
* '''<code>p-summary</code>''' - provides a short summary or introduction
* '''<code>p-author</code>''' - person who wrote the recipe, optionally embedded with <code>h-card</code> {{main|h-card}}
* '''<code>dt-published</code>''' - the date the recipe was published
* '''<code>p-nutrition</code>''' - nutritional information like calories, fat, dietary fiber etc.
* '''<code>p-category</code>''' - recipe categories/tags
* ...

=== Proposed properties ===

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

* '''<code id="u-remix-of">u-remix-of</code>''' - the URL which the h-entry is considered a “remix” of. Optionally an embedded [[h-cite]]. The purpose of this in an h-recipe is to identify that this recipe is a remix, or based on another recipe, and giving appropriate citation to that individual. In theory, if this was an exact copy, the u-repost-of used in h-entry would apply.

== Status ==

'''h-recipe''' is a microformats.org draft specification. Public discussion on h-recipe takes place on [[h-recipe-feedback]] and the #microformats [[irc]] channel on irc.freenode.net.

h-recipe is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-recipes up with classic [[hRecipe]] classnames.

== Property Details ==

(stub, add any property explanations here)

'''dt-duration''' should be marked up using the [http://developers.whatwg.org/common-microsyntaxes.html#durations duration] microsyntax defined in HTML5. TODO: add more examples

[[hRecipe]] has a number of experimental properties which have real world adoption due to [[Google]] recipe search support of hRecipe. These are: summary, author, published and nutrition.

== Examples in the Wild ==
* [http://www.eliduke.com Eli Duke] has posted some h-[http://www.eliduke.com/recipes recipes] on his site:
** http://www.eliduke.com/recipes/kale-salad
** http://www.eliduke.com/recipes/hummus
** http://www.eliduke.com/recipes/wacky-cake
** http://www.eliduke.com/recipes/vegan-mac-and-cheese

* [https://cleverdevil.io Jonathan LaCour] has created several h-[http://cleverdevil.io/content/recipes recipes] using his Known plugin on his site:
** https://cleverdevil.io/2015/kentucky-maid-cocktail

* [https://makeitperfectly.com Perfect Company] marks up their recipes with h-recipe:
** https://makeitperfectly.com/drink/recipes/1a1913f6-6ba2-11e5-a3ed-f372faffcfa4
** https://makeitperfectly.com/bake/recipes/194a6cea-6ba2-11e5-a3ed-8367b69ac326

* [https://aaronparecki.com/recipes Aaron Parecki] has several recipes on his website
** https://aaronparecki.com/2020/06/01/19/banana-bread
** https://aaronparecki.com/2018/12/25/8/habanero-sauce

== Validating ==
{{h-spec-section-validating}}

== Implementations ==
This section is '''informative'''.

Tools for generating and consuming h-recipe. When it gets too big we can move it to a separate page like [[h-recipe-implementations]].

Consuming h-recipe (sites and tools that consume and do something with h-recipe)
* [https://developers.pinterest.com/docs/rich-pins/recipes/ Pinterest] supports h-recipe to create "rich pins"
* ... (stub)

Generating h-recipe (sites and tools that help produce and publish h-recipe)
* [https://github.com/cleverdevil/Known-Recipes Recipe post generator for Known CMS] by [https://cleverdevil.io Jonathan LaCour].

Advocacy - open source and other implementations which would benefit from h-recipe support or some degree of support has been requested - feel free to help implement these.
* OpenRecipes [https://github.com/fictivekin/openrecipes/issues/198 issue 198] feature request: update spider to parse for the original hRecipe microformat, and the new h-recipe microformats2 update

== Backward Compatibility ==
=== Publisher Compatibility ===
(stub)
=== 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-recipe" is found, don't look for an "hrecipe" on the same element.

compat root class name: <code id="hrecipe">hrecipe</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>ingredient</code>
* <code>yield</code>
* <code>instructions</code> - parse as '''e-'''
* <code>duration</code> - parse as '''dt-'''
* <code>photo</code> - parse as '''u-'''
* <code>summary</code>
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>nutrition</code>
* <code>category</code>
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hrecipe. Thus parsers should look for rel=tag hyperlinks inside an hrecipe, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

== Background ==
h-recipe is based on the existing [[hRecipe]] specification.

== See Also ==

* [[h-recipe-feedback]]
* [[microformats-2]]
* [[h-card]] can be embedded in h-recipe
* [[hRecipe]] is the classic microformat replaced by h-recipe

[[Category:Draft Specifications]]

h-recipe

2022-10-06T02:11:10Z

Dshanske: /* Proposed Properties */

{{DISPLAYTITLE:h-recipe}}
<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-recipe</dfn> is a simple, open format for publishing recipes on the web. h-recipe is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-recipe is the [[microformats2]] update to [[hRecipe]].

{{cc0-owfa-license}}

== Example ==
Here is a simple minimal recipe example:

<source lang=html4strict>
<article class="h-recipe">
<h1 class="p-name">Bagels</h1>

<ul>
<li class="p-ingredient">Flour</li>
<li class="p-ingredient">Sugar</li>
<li class="p-ingredient">Yeast</li>
</ul>

<p>Takes <time class="dt-duration" datetime="1H">1 hour</time>,
serves <data class="p-yield" value="4">four people</data>.</p>

<div class="e-instructions">
<ol>
<li>Start by mixing all the ingredients together.</li>
</ol>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-recipe"
],
"properties": {
"name": [
"Bagels"
],
"ingredient": [
"Flour",
"Sugar",
"Yeast"
],
"yield": [
"4"
],
"instructions": [
{
"value": "Start by mixing all the ingredients together.",
"html": "<ol> <li>Start by mixing all the ingredients together.</li> </ol>"
}
]
}
}
]
}
</source>

=== Get started ===
The class '''<code>h-recipe</code>''' is a ''root class name'' that indicates the presence of an h-recipe.

'''p-name''', '''e-instructions''', '''p-ingredient''' and the other property classnames listed below define elements as ''properties'' of the h-recipe.

See [[microformats-2-parsing]] to learn more about property classnames.

== Properties ==
h-recipe properties, inside an element with class '''h-recipe''':
* '''<code>p-name</code>''' - the name of the recipe
* '''<code>p-ingredient</code>''' - describes one or more ingredients used in the recipe.
* '''<code>p-yield</code>''' - Specifies the quantity produced by the recipe, like how many persons it satisfyies
* '''<code>e-instructions</code>''' - the method of the recipe.
* '''<code>dt-duration</code>''' - the time it takes to prepare the meal described by the recipe.
* '''<code>u-photo</code>''' - an accompanying image

Experimental properties with wide adoption
* '''<code>p-summary</code>''' - provides a short summary or introduction
* '''<code>p-author</code>''' - person who wrote the recipe, optionally embedded with <code>h-card</code> {{main|h-card}}
* '''<code>dt-published</code>''' - the date the recipe was published
* '''<code>p-nutrition</code>''' - nutritional information like calories, fat, dietary fiber etc.
* '''<code>p-category</code>''' - recipe categories/tags
* ...

Proposed properties

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

* '''<code id="u-remix-of">u-remix-of</code>''' - the URL which the h-entry is considered a “remix” of. Optionally an embedded [[h-cite]]. The purpose of this in an h-recipe is to identify that this recipe is a remix, or based on another recipe, and giving appropriate citation to that individual. In theory, if this was an exact copy, the u-repost-of used in h-entry would apply.

== Status ==

'''h-recipe''' is a microformats.org draft specification. Public discussion on h-recipe takes place on [[h-recipe-feedback]] and the #microformats [[irc]] channel on irc.freenode.net.

h-recipe is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-recipes up with classic [[hRecipe]] classnames.

== Property Details ==

(stub, add any property explanations here)

'''dt-duration''' should be marked up using the [http://developers.whatwg.org/common-microsyntaxes.html#durations duration] microsyntax defined in HTML5. TODO: add more examples

[[hRecipe]] has a number of experimental properties which have real world adoption due to [[Google]] recipe search support of hRecipe. These are: summary, author, published and nutrition.

== Examples in the Wild ==
* [http://www.eliduke.com Eli Duke] has posted some h-[http://www.eliduke.com/recipes recipes] on his site:
** http://www.eliduke.com/recipes/kale-salad
** http://www.eliduke.com/recipes/hummus
** http://www.eliduke.com/recipes/wacky-cake
** http://www.eliduke.com/recipes/vegan-mac-and-cheese

* [https://cleverdevil.io Jonathan LaCour] has created several h-[http://cleverdevil.io/content/recipes recipes] using his Known plugin on his site:
** https://cleverdevil.io/2015/kentucky-maid-cocktail

* [https://makeitperfectly.com Perfect Company] marks up their recipes with h-recipe:
** https://makeitperfectly.com/drink/recipes/1a1913f6-6ba2-11e5-a3ed-f372faffcfa4
** https://makeitperfectly.com/bake/recipes/194a6cea-6ba2-11e5-a3ed-8367b69ac326

* [https://aaronparecki.com/recipes Aaron Parecki] has several recipes on his website
** https://aaronparecki.com/2020/06/01/19/banana-bread
** https://aaronparecki.com/2018/12/25/8/habanero-sauce

== Validating ==
{{h-spec-section-validating}}

== Implementations ==
This section is '''informative'''.

Tools for generating and consuming h-recipe. When it gets too big we can move it to a separate page like [[h-recipe-implementations]].

Consuming h-recipe (sites and tools that consume and do something with h-recipe)
* [https://developers.pinterest.com/docs/rich-pins/recipes/ Pinterest] supports h-recipe to create "rich pins"
* ... (stub)

Generating h-recipe (sites and tools that help produce and publish h-recipe)
* [https://github.com/cleverdevil/Known-Recipes Recipe post generator for Known CMS] by [https://cleverdevil.io Jonathan LaCour].

Advocacy - open source and other implementations which would benefit from h-recipe support or some degree of support has been requested - feel free to help implement these.
* OpenRecipes [https://github.com/fictivekin/openrecipes/issues/198 issue 198] feature request: update spider to parse for the original hRecipe microformat, and the new h-recipe microformats2 update

== Backward Compatibility ==
=== Publisher Compatibility ===
(stub)
=== 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-recipe" is found, don't look for an "hrecipe" on the same element.

compat root class name: <code id="hrecipe">hrecipe</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>ingredient</code>
* <code>yield</code>
* <code>instructions</code> - parse as '''e-'''
* <code>duration</code> - parse as '''dt-'''
* <code>photo</code> - parse as '''u-'''
* <code>summary</code>
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>nutrition</code>
* <code>category</code>
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hrecipe. Thus parsers should look for rel=tag hyperlinks inside an hrecipe, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

== Background ==
h-recipe is based on the existing [[hRecipe]] specification.

== See Also ==

* [[h-recipe-feedback]]
* [[microformats-2]]
* [[h-card]] can be embedded in h-recipe
* [[hRecipe]] is the classic microformat replaced by h-recipe

[[Category:Draft Specifications]]

h-recipe

2022-10-06T02:09:08Z

Dshanske: /* Propose a property to identify a recipe that was derived from/based on another recipe. */

{{DISPLAYTITLE:h-recipe}}
<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-recipe</dfn> is a simple, open format for publishing recipes on the web. h-recipe is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-recipe is the [[microformats2]] update to [[hRecipe]].

{{cc0-owfa-license}}

== Example ==
Here is a simple minimal recipe example:

<source lang=html4strict>
<article class="h-recipe">
<h1 class="p-name">Bagels</h1>

<ul>
<li class="p-ingredient">Flour</li>
<li class="p-ingredient">Sugar</li>
<li class="p-ingredient">Yeast</li>
</ul>

<p>Takes <time class="dt-duration" datetime="1H">1 hour</time>,
serves <data class="p-yield" value="4">four people</data>.</p>

<div class="e-instructions">
<ol>
<li>Start by mixing all the ingredients together.</li>
</ol>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-recipe"
],
"properties": {
"name": [
"Bagels"
],
"ingredient": [
"Flour",
"Sugar",
"Yeast"
],
"yield": [
"4"
],
"instructions": [
{
"value": "Start by mixing all the ingredients together.",
"html": "<ol> <li>Start by mixing all the ingredients together.</li> </ol>"
}
]
}
}
]
}
</source>

=== Get started ===
The class '''<code>h-recipe</code>''' is a ''root class name'' that indicates the presence of an h-recipe.

'''p-name''', '''e-instructions''', '''p-ingredient''' and the other property classnames listed below define elements as ''properties'' of the h-recipe.

See [[microformats-2-parsing]] to learn more about property classnames.

== Properties ==
h-recipe properties, inside an element with class '''h-recipe''':
* '''<code>p-name</code>''' - the name of the recipe
* '''<code>p-ingredient</code>''' - describes one or more ingredients used in the recipe.
* '''<code>p-yield</code>''' - Specifies the quantity produced by the recipe, like how many persons it satisfyies
* '''<code>e-instructions</code>''' - the method of the recipe.
* '''<code>dt-duration</code>''' - the time it takes to prepare the meal described by the recipe.
* '''<code>u-photo</code>''' - an accompanying image

Experimental properties with wide adoption
* '''<code>p-summary</code>''' - provides a short summary or introduction
* '''<code>p-author</code>''' - person who wrote the recipe, optionally embedded with <code>h-card</code> {{main|h-card}}
* '''<code>dt-published</code>''' - the date the recipe was published
* '''<code>p-nutrition</code>''' - nutritional information like calories, fat, dietary fiber etc.
* '''<code>p-category</code>''' - recipe categories/tags
* ...

Proposed properties
* '''<code id="u-remix-of">u-remix-of</code>''' - the URL which the h-entry is considered a “remix” of. Optionally an embedded [[h-cite]]. The purpose of this in an h-recipe is to identify that this recipe is a remix, or based on another recipe, and giving appropriate citation to that individual. In theory, if this was an exact copy, the u-repost-of used in h-entry would apply.

== Status ==

'''h-recipe''' is a microformats.org draft specification. Public discussion on h-recipe takes place on [[h-recipe-feedback]] and the #microformats [[irc]] channel on irc.freenode.net.

h-recipe is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-recipes up with classic [[hRecipe]] classnames.

== Property Details ==

(stub, add any property explanations here)

'''dt-duration''' should be marked up using the [http://developers.whatwg.org/common-microsyntaxes.html#durations duration] microsyntax defined in HTML5. TODO: add more examples

[[hRecipe]] has a number of experimental properties which have real world adoption due to [[Google]] recipe search support of hRecipe. These are: summary, author, published and nutrition.

== Examples in the Wild ==
* [http://www.eliduke.com Eli Duke] has posted some h-[http://www.eliduke.com/recipes recipes] on his site:
** http://www.eliduke.com/recipes/kale-salad
** http://www.eliduke.com/recipes/hummus
** http://www.eliduke.com/recipes/wacky-cake
** http://www.eliduke.com/recipes/vegan-mac-and-cheese

* [https://cleverdevil.io Jonathan LaCour] has created several h-[http://cleverdevil.io/content/recipes recipes] using his Known plugin on his site:
** https://cleverdevil.io/2015/kentucky-maid-cocktail

* [https://makeitperfectly.com Perfect Company] marks up their recipes with h-recipe:
** https://makeitperfectly.com/drink/recipes/1a1913f6-6ba2-11e5-a3ed-f372faffcfa4
** https://makeitperfectly.com/bake/recipes/194a6cea-6ba2-11e5-a3ed-8367b69ac326

* [https://aaronparecki.com/recipes Aaron Parecki] has several recipes on his website
** https://aaronparecki.com/2020/06/01/19/banana-bread
** https://aaronparecki.com/2018/12/25/8/habanero-sauce

== Validating ==
{{h-spec-section-validating}}

== Implementations ==
This section is '''informative'''.

Tools for generating and consuming h-recipe. When it gets too big we can move it to a separate page like [[h-recipe-implementations]].

Consuming h-recipe (sites and tools that consume and do something with h-recipe)
* [https://developers.pinterest.com/docs/rich-pins/recipes/ Pinterest] supports h-recipe to create "rich pins"
* ... (stub)

Generating h-recipe (sites and tools that help produce and publish h-recipe)
* [https://github.com/cleverdevil/Known-Recipes Recipe post generator for Known CMS] by [https://cleverdevil.io Jonathan LaCour].

Advocacy - open source and other implementations which would benefit from h-recipe support or some degree of support has been requested - feel free to help implement these.
* OpenRecipes [https://github.com/fictivekin/openrecipes/issues/198 issue 198] feature request: update spider to parse for the original hRecipe microformat, and the new h-recipe microformats2 update

== Backward Compatibility ==
=== Publisher Compatibility ===
(stub)
=== 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-recipe" is found, don't look for an "hrecipe" on the same element.

compat root class name: <code id="hrecipe">hrecipe</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>ingredient</code>
* <code>yield</code>
* <code>instructions</code> - parse as '''e-'''
* <code>duration</code> - parse as '''dt-'''
* <code>photo</code> - parse as '''u-'''
* <code>summary</code>
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>nutrition</code>
* <code>category</code>
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hrecipe. Thus parsers should look for rel=tag hyperlinks inside an hrecipe, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

== Background ==
h-recipe is based on the existing [[hRecipe]] specification.

== See Also ==

* [[h-recipe-feedback]]
* [[microformats-2]]
* [[h-card]] can be embedded in h-recipe
* [[hRecipe]] is the classic microformat replaced by h-recipe

[[Category:Draft Specifications]]

h-entry

2022-08-13T17:36:36Z

Dshanske: /* Proposed Additions */

{{DISPLAYTITLE:h-entry}}
<dfn style="font-style:normal;font-weight:bold">h-entry</dfn> 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 [[microformats|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]].

;<span id="status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [[h-entry-issues|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|change control]] process.
;<span id="participate">Participate</span>
:[https://github.com/microformats/h-entry/issues Open Issues]
:[[h-entry-issues|Resolved issues before 2012-246]]
:[[IRC]]
:Advance the spec by following explicit [[#change_control|change control]] process
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__

== Example ==
Here is a simple blog post example:

<source lang=html4strict>
<article class="h-entry">
<h1 class="p-name">Microformats are amazing</h1>
<p>Published by <a class="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></p>

<p class="p-summary">In which I extoll the virtues of using microformats.</p>

<div class="e-content">
<p>Blah blah blah</p>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"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>"
}
]
}
}
]
}
</source>

== Get started ==
The class '''<code>h-entry</code>''' 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 optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

=== Core Properties ===
The following ''core'' h-entry properties have broad consensus and are broadly interoperably published and consumed:
* '''<code>p-name</code>''' - entry name/title
* '''<code>p-summary</code>''' - short entry summary
* '''<code>e-content</code>''' - full content of the entry
* '''<code>dt-published</code>''' - when the entry was published
* '''<code>dt-updated</code>''' - when the entry was updated
* '''<code>p-author</code>''' - who wrote the entry, optionally embedded [[h-card]](s)
* '''<code>p-category</code>''' - entry categories/tags
* '''<code>u-url</code>''' - entry permalink URL
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical entry URL
* '''<code>p-location</code>''' - location the entry was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code id="u-syndication">u-syndication</code>''' - URL(s) of syndicated copies of this post. The property equivalent of [[rel-syndication]] ([http://erinjo.is/2014/checked-into-rockit-colabs-23 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]) ([https://kartikprabhu.com/notes/re-citizen-of-indieweb example])
* '''<code id="p-rsvp">p-rsvp</code>''' (enum, use <data> element or [[value-class-pattern]])
** "yes", "no", "maybe", "interested". Case-insensitive values, normalized to lowercase. Examples:
** <code><nowiki>... <data class="p-rsvp" value="YES">is going</data> to ...</nowiki></code>, or
** <code><nowiki>... <data class="p-rsvp" value="Maybe">might go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="no">unable to go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="interested">am interested/tracking/watching</data> ...</nowiki></code>
* '''<code id="u-like-of">u-like-of</code>''' - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded [[h-cite]]
* '''<code id="u-repost-of">u-repost-of</code>''' - the URL which the h-entry is considered a “repost” of. Optionally an embedded [[h-cite]].

=== 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 id="p-comment">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])
** [https://github.com/microformats/h-entry/issues/20 Issue 20]
* '''<code id="u-photo">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.
** [https://github.com/microformats/h-entry/issues/4 Issue 4: u-photo draft->core bc way more than 3+ pub and consuming impls/sites]
** [https://github.com/microformats/h-entry/issues/24 Issue 24: Update Definition of Draft Property u-photo]
* '''<code id="u-video">u-video</code>''' - special u- parsing rules for <code><video src> & <source src></code>
** [https://github.com/microformats/h-entry/issues/5 Issue 5]

=== 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 awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:
* '''<code>u-audio</code>''' - special u- parsing rules for <code><audio src> & <source src></code>. Examples: [http://transportini.com/ Transportini],[https://indieweb.org/podcast#How_to_podcast_with_h-feed possibly more]
** [https://github.com/microformats/h-entry/issues/6 Issue 6]
* '''<code>u-like</code>''' - similar to p-comment, URL to a like post of the current post, e.g. in a responses list or facepile.
* '''<code>u-repost</code>''' - similar to u-like, URL to a repost of the current post, e.g. in a responses list or facepile.
* '''<code>u-bookmark-of</code>''' - indicates this h-entry is a bookmark of another URL. Optionally an [[h-cite]]. See [https://indieweb.org/bookmark indieweb.org/bookmark] for examples in the wild.
** [https://github.com/microformats/h-entry/issues/12 Issue 12]
* '''<code>u-featured</code>''' - 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]].
** +1 sknebel: https://github.com/microformats/h-entry/issues/14
* Location Properties - https://github.com/microformats/h-entry/issues/29
** '''<code>p-latitude</code>''' - latitude of the location of the entry
** '''<code>p-longitude</code>''' - longitude of the location of the entry
** '''<code>p-altitude</code>''' - altitude of the location of the entry
* '''<code>p-duration</code>''' - duration of an audio or video file in the entry. https://indieweb.org/duration Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
** [https://github.com/microformats/h-entry/issues/21 Issue 21]
* '''<code>p-size</code>''' - size in bytes of an audio or video file in the entry. https://indieweb.org/size Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>u-listen-of</code>''' - also known as a 'scrobble', indicates this h-entry is a listen of another URL. Optionally an h-cite. https://github.com/microformats/h-entry/issues/11
* '''<code>u-watch-of</code>''' - indicates this h-entry is a watch of another URL, a visual version of the scrobble. Optionally an h-cite. https://github.com/microformats/h-entry/issues/17
* '''<code>p-read-of</code>''' - indicates this h-entry is a read post of some written work (book or other document). The value can be the title of the work or an h-cite. Proposal also mentions <code>u-read-of</code>, where the value would be a URL to the written work or a representative citation page. https://github.com/microformats/h-entry/issues/10
* '''<code>u-translation-of</code>''' - indicates this h-entry is a translation of the linked URL into another language. Can be used in the same way as the existing <code>u-like-of</code> and <code>u-repost-of</code> properties, with just the URL to the original h-entry, or (optionally) contain an embedded <code>h-cite</code>. https://github.com/microformats/h-entry/issues/26
* '''<code>u-checkin</code>''' - the URL of the venue/location h-card which the h-entry is considered a “checkin” of. Optionally an embedded h-card. https://github.com/microformats/h-entry/issues/15

The following interpretation is also proposed addition:
* if the <code>p-location</code> is also an embedded [[h-card]], the entry is treated as a "checkin".
** -1 [[User:Aaronpk|Aaronpk]] 14:22, 19 January 2017 (UTC) [https://aaronparecki.com/2017/01/13/21/ this post] is not a checkin, but has an h-card as the p-location property.

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: [[h-entry#change_control|change control]]

== Property Details ==
This section is a stub.
=== p-location ===
'''<code>p-location</code>''' has been re-used from [[h-event]].

== FAQ ==
=== p-name of a note ===
<div class="discussion">
* '''What is the <code>p-name</code> of a [https://indieweb.org/note note]?'''
** You probably should avoid adding <code>p-name</code> to notes. See https://indieweb.org/note for more discussion of the topic.
</div>

=== venue an entry was posted from ===
<div class="discussion">
* '''How do you indicate a named venue where an entry was posted from? Like a restaurant or park.'''
** Use an embedded [[h-card]] microformat on a <code>p-location</code> property value.
</div>

=== address an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== lat long an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== dt-published property and HTML5 time element ===
<div class="discussion">
* '''Does the dt-published property need to be a time element?'''
** The <code>dt-published</code> property should be a <code><time></code> 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.
</div>

=== 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:
:* <code>url</code>
:* <code>published</code> — if there is no "published" date for the "entry", then reconsider whether it is correct (or worth) marking it up as an entry.

; 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:
:* <code>content</code> (or <code>summary</code> at least) - especially for structured content. For a plain text note, the content/summary (whichever is used) should be the same as the <code>name</code>, otherwise it will be implied from the text content of the root element.
:* <code>name</code> - for explicitly named/titled entries like blog posts and articles. Otherwise the entry is assumed to be a "title-less" [https://indieweb.org/note note] (like a tweet).
:* <code>author</code> - including a nested <code>[[h-card]]</code> with author details like name, photo, url.

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

* ... add uses of h-entry you see in the wild here.
* ind.ie mark up their [https://ind.ie/blog blog] listing and [https://ind.ie/blog/autumn-events-2014/ permalink] pages with h-entry
* David John Mead marks up his profile, blog posts and comments with h-card, h-entry and h-cite on [http://davidjohnmead.com davidjohnmead.com]
* [[User:Brian|Brian Suda]] marks up his blog posts up with h-entry and h-card on [http://optional.is/required/ optional.is]
* Ashton McAllen marks up his blog posts, reposts, comments and likes with h-entry, h-card and h-cite on [http://acegiak.net/ acegiak.net]
* Emma Kuo marks up her blog posts and notes with h-entry and h-card on [http://notenoughneon.com/ notenoughneon.com]
* Scott Jenson marks up his blog posts with h-entry and h-card on [http://jenson.org/ jenson.org]
* Emily McAllen marks up her blog posts with h-entry and h-card on [http://blackwoolholiday.com/ blackwoolholiday.com]
* Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on [https://snarfed.org/ snarfed.org]
* Barry Frost marks up his notes with h-entry, h-card and h-cite on [http://barryfrost.com/ barryfrost.com]
* Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on [http://caseorganic.com/ caseorganic.com]
* Johannes Ernst marks up his blog posts with h-entry on [http://upon2020.com/blog/ upon2020.com]
* Michiel de Jong marks up his profile and notes with h-entry and h-card on [https://michielbdejong.com/ michielbdejong.com]
* Mike Taylor marks up his profile and blog posts with h-card and h-entry on [https://bear.im/bearlog/ bear.im]
* Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on [http://erinjo.is/ erinjo.is]
* Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on [https://jeena.net/ jeena.net]
* Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on [http://andysylvester.com/2014/03/01/howto-setting-up-the-selfoss-feed-reader-with-microformats-support/ andysylvester.com] (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --[[User:Barnabywalters|bw]] 14:44, 13 March 2014 (UTC))
* Chloe Weil marks up her blog posts with h-entry on [http://chloeweil.com/blog chloeweil.com]
* Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on [http://christopheducamp.com/ christopheducamp.com]
* Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on [http://glennjones.net/ glennjones.net]
* Marcus Povey marks up his blog posts and profile with h-entry and h-card on [http://www.marcus-povey.co.uk/ marcus-povey.co.uk]
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* Kyle Mahan marks up his profile and notes with h-card and h-entry on [http://kylewm.com/ kylewm.com]
* Okinawan-lyrics marks up his posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* App.net marks up profile pages and permalink pages with h-entry as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* The Twitter archive browser UI uses h-entry and h-card internally, unfortunately it’s not exposed as HTML in static files anywhere
* Brett Comnes marks up his posts with h-entry and h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like ([http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his posts up with h-card and h-entry, as well as draft u-in-reply-to and experimental u-like properties ([http://sandeep.io/101 example])
* Laurent Eschenauer marks up his posts with h-entry ([http://eschnou.com/entry/first-autonomous-flight-of-my-nodecopter-62-24992.html example])
* Tom Morris marks up his posts using h-entry ([http://tommorris.org/posts/8417 example])
* Numerous newer W3C specs, e.g.
** [http://www.w3.org/TR/2013/CR-css3-values-20130404/ CSS Values and Units Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/CR-css3-conditional-20130404/ CSS Conditional Rules Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/WD-css3-page-20130314/ CSS Paged Media Module Level 3 - 2013-03-14]
** [http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/ CSS Counter Styles Level 3 - 2013-02-21]
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry.
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Aaron Parecki uses h-entry to mark up notes, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-entry on his home page, as well as h-entry on all post permalinks, e.g. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], with [[rel-prev]]/[[rel-next]] (if applicable) to indicate prev/next posts
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-entry on all notes and articles, as well as nested within notes as reply contexts [http://waterpigs.co.uk/notes/1468/ example] and comments [http://waterpigs.co.uk/notes/1482/ example].

=== offline ===
* spreadly marks up share permalink pages with h-entry, as well as minimal h-cards and experimental p-like properties

== Validating ==
* '''[http://indiewebify.me/validate-h-entry/ indiewebify.me h-entry validator]''' parses [[h-entry]] markup, finds common errors and makes suggestions for things to add, with code samples
* '''[http://shrewdness.waterpigs.co.uk/test/ Shrewdness h-entry/h-feed validator]''' shows how shrewdness interprets+displays h-entries, with original source and interim formats, works for single h-entries and feed pages

{{h-spec-section-validating}}

== 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 [https://indieweb.org/ 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.
* [https://gnu.io/social/ GNUsocial] [https://git.gnu.io/gnu/gnu-social/ source code]
* [https://hubzilla.org/hubzilla/ Hubzilla] [https://github.org/redmatrix/hubzilla source code]
* [http://friendica.com/ Friendica] [https://github.org/friendica/friendica source code]
* [http://github.com/dissolve/inkblot InkBlot]
* ...

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

<source lang=html4strict>
<article class="h-entry hentry">
<h1 class="p-name entry-title">A Tale Of Two Tags</h1>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="e-content entry-content">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
<p>The a tag is perhaps the best of HTML, yet its corresponding invisible link tag has uses too.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>
</source>

{{note|Note: you may use any valid HTML5 elements. The <code>article h1 address time</code> elements are used in the example as semantically richer suggestions, however in general <code>div span</code> work fine too. The <code>time</code> element is special though in that its <code>datetime</code> 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: <code id="hentry">hentry</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

* <code>entry-title</code> - parse as '''<code>p-name</code>'''
* <code>entry-summary</code> - parse as '''<code>p-summary</code>'''
* <code>entry-content</code> - parse as '''<code>e-content</code>'''
* <code>published</code> - parse as '''dt-'''
* <code>updated</code> - parse as '''dt-'''
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>category</code>
* <code>rel=bookmark</code> - parse as '''<code>u-url</code>'''. While not a class name nor typical microformats property, rel=bookmark was the only way to indicate an hentry permalink. Thus parsers should look for rel=bookmark hyperlinks inside an hentry, and take their "href" value as a value for a '''<code>u-url</code>''' property, including handling any relative URL resolution.
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hentry. Thus parsers should look for rel=tag hyperlinks inside an hentry, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

Proposed: ([https://github.com/microformats/h-entry/issues/7 follow-up in issue #7])
* <code>time.entry-date[datetime]</code> - in the absence of <code>published</code>, parse as '''<code>dt-published</code>'''. parse for the first <code><time></code> element with class name of <code>entry-date</code> and non-empty <code>datetime</code> attribute inside an hentry, if there is no <code>published</code> property, use that time element's <code>datetime</code> attribute value for the <code>dt-published</code> property. Evidence: default WordPress themes 2011-2014([https://wp-themes.com/twentyeleven/][https://wp-themes.com/twentytwelve/][https://wp-themes.com/twentythirteen/][https://wp-themes.com/twentyfourteen/]).
* <code>rel=author</code> - in the absence of <code>author</code>, parse as '''<code>u-author</code>'''. While not a class name nor typical microformats property, rel=author was commonly used to link to an author's URL. Thus parsers should look for rel=author hyperlinks inside an hentry (or even on the same page, preceding the hentry), use the absolute version of it as a value for the '''<code>u-author</code>''' property if there is no "author" property. (citations to "hentry" examples in the wild that <em>depend</em> on rel=author needed to accepted this proposal. Note: default WordPress themes twentyeleven, twentytwelve, twentythirteen, twentyfourteen all use rel=author but only inside class="author vcard", and thus rel=author can be ignored since authorship is already picked up by existing <code>author</code> backcompat parsing.)

=== 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|rel=bookmark]]?''

A: tl;dr: use <code>class="u-url u-uid"</code> instead of <code>rel=bookmark</code> 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.

<nowiki>*</nowiki> even though rel=bookmark in particular is article-element / sectioning scoped in HTML5[http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-bookmark], 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 <code>entry-*</code> 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#Could_hAtom_instead_use_title_content_and_summary|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: [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-128 2012-08-30 IRC conversation].

== Related Work ==
Work that re-uses or builds upon h-entry:
* [https://mailpile.pagekite.me:8080/p/Open_Message_Format Mailpile Open Message Format] is using h-entry with structured properties, e.g. p-author h-card.

== Background ==
This work is based on the existing [[hAtom]] microformat, and extensive selfdogfooding in the [http://indiewebcamp.com 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 [[h-entry-issues|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|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|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_Additions|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|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|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 ==
* [[h-feed]]
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-geo]]
* [[hCard]]

[[Category:Specifications]]

h-geo

2022-08-13T17:29:24Z

Dshanske: /* Status */

{{DISPLAYTITLE:h-geo}}
<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-geo</dfn> is a simple, open format for publishing [http://en.wikipedia.org/wiki/WGS84 WGS84] geographic coordinates. h-geo is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-geo is the [[microformats2]] update to [[geo]]. It is most commonly used as part of an [[h-card]] or [[h-event]].

{{cc0-owfa-license}}

== Example ==
Here is a simple h-geo example:

<source lang=html4strict>
<p class="h-geo">
<span class="p-latitude">-27.116667</span>,
<span class="p-longitude">-109.366667</span>
</p>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-geo"
],
"properties": {
"latitude": [
"-27.116667"
],
"longitude": [
"-109.366667"
],
"name": [
"-27.116667, -109.366667"
]
}
}
]
}
</source>

=== Get started ===
The class '''<code>h-geo</code>''' is a ''root class name'' that indicates the presence of an h-geo.

'''p-latitude''', '''p-longitude''' and '''p-altitude''' classnames define an element as a ''property'' of the h-geo.

See [[microformats2-parsing]] to learn more about property classnames.

== Properties ==
h-geo properties, inside an element with class '''h-geo''':
* '''<code>p-latitude</code>''' - decimal latitude
* '''<code>p-longitude</code>''' - decimal longitude
* '''<code>p-altitude</code>''' - decimal altitude

All properties are optional.

== Status ==

'''h-geo''' is a microformats.org draft specification. Public discussion on h-geo takes place on [[h-geo-feedback]] and the #microformats [[irc]] channel on libera.chat.

h-geo is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-geos up with classic [[geo]] classnames.

== Property Details ==

'''p-altitude''' refers to the distance in metres from the nominal sea level along the tangent of the earth’s curve, i.e. the geoid height. For more information refer to the [http://en.wikipedia.org/wiki/WGS84 WGS84] specification and the [https://en.wikipedia.org/wiki/Geo_URI_scheme geo URI scheme].

== FAQ ==

'''How should I mark up lat/long coordinates without them looking messy and confusing?'''

Unless your content is targeted at an audience with a high leg authoring '''p-latitude''' and '''p-longitude''' as plain numbers on a webpage may not be the best approach. In addition to this there may be accessibility issues due to the potentially long strings of numbers being read out.

You could present the coordinates in a more human-readable form, retaining the decimal coordinates inside data value attributes:

<source lang=html4strict>
<p class="h-geo">
<data class="p-longitude" value="-27.116667">27° 7′ 0″ S</data>,
<data class="p-latitude" value="-109.366667">109° 22′ 0″ W</data>
</p>
</source>

Alternatively you could not show coordinates at all and simply show a human-readable representation of the location, with the lat/long in value attributes of empty data elements.

== Examples in the Wild ==
* … add any h-geo examples you find in the wild

== Validating ==
{{h-spec-section-validating}}

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[geo]] classnames in addition to the more future-proof h-geo properties, for example:

<source lang=html4strict>
<p class="h-geo geo">
<span class="p-latitude latitude">-27.116667</span>,
<span class="p-longitude longitude">-109.366667</span>
</p>
</source>

=== 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-geo" is found, don't look for an "geo" on the same element.

Compatibility root class name: geo

Properties: (parsed as p- plain text unless otherwise specified)

* latitude
* longitude

== Background ==

h-geo is based on the [http://en.wikipedia.org/wiki/WGS84 WGS84] standard, as well as existing [[geo]] specification, which was extracted from [[hCard]] in order to allow it to be used for applications other than contact information.

== See Also ==
* [[microformats2]]
* [[h-card]] and [[h-event]] often contain h-geo
* [[h-adr]] is used to mark up human-readable structured addresses

[[Category:Draft Specifications]]

h-entry

2022-08-13T17:21:47Z

Dshanske:

{{DISPLAYTITLE:h-entry}}
<dfn style="font-style:normal;font-weight:bold">h-entry</dfn> 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 [[microformats|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]].

;<span id="status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [[h-entry-issues|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|change control]] process.
;<span id="participate">Participate</span>
:[https://github.com/microformats/h-entry/issues Open Issues]
:[[h-entry-issues|Resolved issues before 2012-246]]
:[[IRC]]
:Advance the spec by following explicit [[#change_control|change control]] process
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__

== Example ==
Here is a simple blog post example:

<source lang=html4strict>
<article class="h-entry">
<h1 class="p-name">Microformats are amazing</h1>
<p>Published by <a class="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></p>

<p class="p-summary">In which I extoll the virtues of using microformats.</p>

<div class="e-content">
<p>Blah blah blah</p>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"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>"
}
]
}
}
]
}
</source>

== Get started ==
The class '''<code>h-entry</code>''' 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 optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

=== Core Properties ===
The following ''core'' h-entry properties have broad consensus and are broadly interoperably published and consumed:
* '''<code>p-name</code>''' - entry name/title
* '''<code>p-summary</code>''' - short entry summary
* '''<code>e-content</code>''' - full content of the entry
* '''<code>dt-published</code>''' - when the entry was published
* '''<code>dt-updated</code>''' - when the entry was updated
* '''<code>p-author</code>''' - who wrote the entry, optionally embedded [[h-card]](s)
* '''<code>p-category</code>''' - entry categories/tags
* '''<code>u-url</code>''' - entry permalink URL
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical entry URL
* '''<code>p-location</code>''' - location the entry was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code id="u-syndication">u-syndication</code>''' - URL(s) of syndicated copies of this post. The property equivalent of [[rel-syndication]] ([http://erinjo.is/2014/checked-into-rockit-colabs-23 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]) ([https://kartikprabhu.com/notes/re-citizen-of-indieweb example])
* '''<code id="p-rsvp">p-rsvp</code>''' (enum, use <data> element or [[value-class-pattern]])
** "yes", "no", "maybe", "interested". Case-insensitive values, normalized to lowercase. Examples:
** <code><nowiki>... <data class="p-rsvp" value="YES">is going</data> to ...</nowiki></code>, or
** <code><nowiki>... <data class="p-rsvp" value="Maybe">might go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="no">unable to go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="interested">am interested/tracking/watching</data> ...</nowiki></code>
* '''<code id="u-like-of">u-like-of</code>''' - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded [[h-cite]]
* '''<code id="u-repost-of">u-repost-of</code>''' - the URL which the h-entry is considered a “repost” of. Optionally an embedded [[h-cite]].

=== 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 id="p-comment">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])
** [https://github.com/microformats/h-entry/issues/20 Issue 20]
* '''<code id="u-photo">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.
** [https://github.com/microformats/h-entry/issues/4 Issue 4: u-photo draft->core bc way more than 3+ pub and consuming impls/sites]
** [https://github.com/microformats/h-entry/issues/24 Issue 24: Update Definition of Draft Property u-photo]
* '''<code id="u-video">u-video</code>''' - special u- parsing rules for <code><video src> & <source src></code>
** [https://github.com/microformats/h-entry/issues/5 Issue 5]

=== 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 awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:
* '''<code>u-audio</code>''' - special u- parsing rules for <code><audio src> & <source src></code>. Examples: [http://transportini.com/ Transportini],[https://indieweb.org/podcast#How_to_podcast_with_h-feed possibly more]
** [https://github.com/microformats/h-entry/issues/6 Issue 6]
* '''<code>u-like</code>''' - similar to p-comment, URL to a like post of the current post, e.g. in a responses list or facepile.
* '''<code>u-repost</code>''' - similar to u-like, URL to a repost of the current post, e.g. in a responses list or facepile.
* '''<code>u-bookmark-of</code>''' - indicates this h-entry is a bookmark of another URL. Optionally an [[h-cite]]. See [https://indieweb.org/bookmark indieweb.org/bookmark] for examples in the wild.
** [https://github.com/microformats/h-entry/issues/12 Issue 12]
* '''<code>u-featured</code>''' - 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]].
** +1 sknebel: https://github.com/microformats/h-entry/issues/14
* '''<code>p-latitude</code>''' - latitude of the location of the entry
* '''<code>p-longitude</code>''' - longitude of the location of the entry
* '''<code>p-duration</code>''' - duration of an audio or video file in the entry. https://indieweb.org/duration Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
** [https://github.com/microformats/h-entry/issues/21 Issue 21]
* '''<code>p-size</code>''' - size in bytes of an audio or video file in the entry. https://indieweb.org/size Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>u-listen-of</code>''' - also known as a 'scrobble', indicates this h-entry is a listen of another URL. Optionally an h-cite. https://github.com/microformats/h-entry/issues/11
* '''<code>u-watch-of</code>''' - indicates this h-entry is a watch of another URL, a visual version of the scrobble. Optionally an h-cite. https://github.com/microformats/h-entry/issues/17
* '''<code>p-read-of</code>''' - indicates this h-entry is a read post of some written work (book or other document). The value can be the title of the work or an h-cite. Proposal also mentions <code>u-read-of</code>, where the value would be a URL to the written work or a representative citation page. https://github.com/microformats/h-entry/issues/10
* '''<code>u-translation-of</code>''' - indicates this h-entry is a translation of the linked URL into another language. Can be used in the same way as the existing <code>u-like-of</code> and <code>u-repost-of</code> properties, with just the URL to the original h-entry, or (optionally) contain an embedded <code>h-cite</code>. https://github.com/microformats/h-entry/issues/26
* '''<code>u-checkin</code>''' - the URL of the venue/location h-card which the h-entry is considered a “checkin” of. Optionally an embedded h-card. https://github.com/microformats/h-entry/issues/15

The following interpretation is also proposed addition:
* if the <code>p-location</code> is also an embedded [[h-card]], the entry is treated as a "checkin".
** -1 [[User:Aaronpk|Aaronpk]] 14:22, 19 January 2017 (UTC) [https://aaronparecki.com/2017/01/13/21/ this post] is not a checkin, but has an h-card as the p-location property.

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: [[h-entry#change_control|change control]]

== Property Details ==
This section is a stub.
=== p-location ===
'''<code>p-location</code>''' has been re-used from [[h-event]].

== FAQ ==
=== p-name of a note ===
<div class="discussion">
* '''What is the <code>p-name</code> of a [https://indieweb.org/note note]?'''
** You probably should avoid adding <code>p-name</code> to notes. See https://indieweb.org/note for more discussion of the topic.
</div>

=== venue an entry was posted from ===
<div class="discussion">
* '''How do you indicate a named venue where an entry was posted from? Like a restaurant or park.'''
** Use an embedded [[h-card]] microformat on a <code>p-location</code> property value.
</div>

=== address an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== lat long an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== dt-published property and HTML5 time element ===
<div class="discussion">
* '''Does the dt-published property need to be a time element?'''
** The <code>dt-published</code> property should be a <code><time></code> 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.
</div>

=== 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:
:* <code>url</code>
:* <code>published</code> — if there is no "published" date for the "entry", then reconsider whether it is correct (or worth) marking it up as an entry.

; 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:
:* <code>content</code> (or <code>summary</code> at least) - especially for structured content. For a plain text note, the content/summary (whichever is used) should be the same as the <code>name</code>, otherwise it will be implied from the text content of the root element.
:* <code>name</code> - for explicitly named/titled entries like blog posts and articles. Otherwise the entry is assumed to be a "title-less" [https://indieweb.org/note note] (like a tweet).
:* <code>author</code> - including a nested <code>[[h-card]]</code> with author details like name, photo, url.

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

* ... add uses of h-entry you see in the wild here.
* ind.ie mark up their [https://ind.ie/blog blog] listing and [https://ind.ie/blog/autumn-events-2014/ permalink] pages with h-entry
* David John Mead marks up his profile, blog posts and comments with h-card, h-entry and h-cite on [http://davidjohnmead.com davidjohnmead.com]
* [[User:Brian|Brian Suda]] marks up his blog posts up with h-entry and h-card on [http://optional.is/required/ optional.is]
* Ashton McAllen marks up his blog posts, reposts, comments and likes with h-entry, h-card and h-cite on [http://acegiak.net/ acegiak.net]
* Emma Kuo marks up her blog posts and notes with h-entry and h-card on [http://notenoughneon.com/ notenoughneon.com]
* Scott Jenson marks up his blog posts with h-entry and h-card on [http://jenson.org/ jenson.org]
* Emily McAllen marks up her blog posts with h-entry and h-card on [http://blackwoolholiday.com/ blackwoolholiday.com]
* Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on [https://snarfed.org/ snarfed.org]
* Barry Frost marks up his notes with h-entry, h-card and h-cite on [http://barryfrost.com/ barryfrost.com]
* Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on [http://caseorganic.com/ caseorganic.com]
* Johannes Ernst marks up his blog posts with h-entry on [http://upon2020.com/blog/ upon2020.com]
* Michiel de Jong marks up his profile and notes with h-entry and h-card on [https://michielbdejong.com/ michielbdejong.com]
* Mike Taylor marks up his profile and blog posts with h-card and h-entry on [https://bear.im/bearlog/ bear.im]
* Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on [http://erinjo.is/ erinjo.is]
* Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on [https://jeena.net/ jeena.net]
* Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on [http://andysylvester.com/2014/03/01/howto-setting-up-the-selfoss-feed-reader-with-microformats-support/ andysylvester.com] (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --[[User:Barnabywalters|bw]] 14:44, 13 March 2014 (UTC))
* Chloe Weil marks up her blog posts with h-entry on [http://chloeweil.com/blog chloeweil.com]
* Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on [http://christopheducamp.com/ christopheducamp.com]
* Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on [http://glennjones.net/ glennjones.net]
* Marcus Povey marks up his blog posts and profile with h-entry and h-card on [http://www.marcus-povey.co.uk/ marcus-povey.co.uk]
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* Kyle Mahan marks up his profile and notes with h-card and h-entry on [http://kylewm.com/ kylewm.com]
* Okinawan-lyrics marks up his posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* App.net marks up profile pages and permalink pages with h-entry as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* The Twitter archive browser UI uses h-entry and h-card internally, unfortunately it’s not exposed as HTML in static files anywhere
* Brett Comnes marks up his posts with h-entry and h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like ([http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his posts up with h-card and h-entry, as well as draft u-in-reply-to and experimental u-like properties ([http://sandeep.io/101 example])
* Laurent Eschenauer marks up his posts with h-entry ([http://eschnou.com/entry/first-autonomous-flight-of-my-nodecopter-62-24992.html example])
* Tom Morris marks up his posts using h-entry ([http://tommorris.org/posts/8417 example])
* Numerous newer W3C specs, e.g.
** [http://www.w3.org/TR/2013/CR-css3-values-20130404/ CSS Values and Units Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/CR-css3-conditional-20130404/ CSS Conditional Rules Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/WD-css3-page-20130314/ CSS Paged Media Module Level 3 - 2013-03-14]
** [http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/ CSS Counter Styles Level 3 - 2013-02-21]
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry.
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Aaron Parecki uses h-entry to mark up notes, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-entry on his home page, as well as h-entry on all post permalinks, e.g. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], with [[rel-prev]]/[[rel-next]] (if applicable) to indicate prev/next posts
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-entry on all notes and articles, as well as nested within notes as reply contexts [http://waterpigs.co.uk/notes/1468/ example] and comments [http://waterpigs.co.uk/notes/1482/ example].

=== offline ===
* spreadly marks up share permalink pages with h-entry, as well as minimal h-cards and experimental p-like properties

== Validating ==
* '''[http://indiewebify.me/validate-h-entry/ indiewebify.me h-entry validator]''' parses [[h-entry]] markup, finds common errors and makes suggestions for things to add, with code samples
* '''[http://shrewdness.waterpigs.co.uk/test/ Shrewdness h-entry/h-feed validator]''' shows how shrewdness interprets+displays h-entries, with original source and interim formats, works for single h-entries and feed pages

{{h-spec-section-validating}}

== 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 [https://indieweb.org/ 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.
* [https://gnu.io/social/ GNUsocial] [https://git.gnu.io/gnu/gnu-social/ source code]
* [https://hubzilla.org/hubzilla/ Hubzilla] [https://github.org/redmatrix/hubzilla source code]
* [http://friendica.com/ Friendica] [https://github.org/friendica/friendica source code]
* [http://github.com/dissolve/inkblot InkBlot]
* ...

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

<source lang=html4strict>
<article class="h-entry hentry">
<h1 class="p-name entry-title">A Tale Of Two Tags</h1>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="e-content entry-content">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
<p>The a tag is perhaps the best of HTML, yet its corresponding invisible link tag has uses too.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>
</source>

{{note|Note: you may use any valid HTML5 elements. The <code>article h1 address time</code> elements are used in the example as semantically richer suggestions, however in general <code>div span</code> work fine too. The <code>time</code> element is special though in that its <code>datetime</code> 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: <code id="hentry">hentry</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

* <code>entry-title</code> - parse as '''<code>p-name</code>'''
* <code>entry-summary</code> - parse as '''<code>p-summary</code>'''
* <code>entry-content</code> - parse as '''<code>e-content</code>'''
* <code>published</code> - parse as '''dt-'''
* <code>updated</code> - parse as '''dt-'''
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>category</code>
* <code>rel=bookmark</code> - parse as '''<code>u-url</code>'''. While not a class name nor typical microformats property, rel=bookmark was the only way to indicate an hentry permalink. Thus parsers should look for rel=bookmark hyperlinks inside an hentry, and take their "href" value as a value for a '''<code>u-url</code>''' property, including handling any relative URL resolution.
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hentry. Thus parsers should look for rel=tag hyperlinks inside an hentry, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

Proposed: ([https://github.com/microformats/h-entry/issues/7 follow-up in issue #7])
* <code>time.entry-date[datetime]</code> - in the absence of <code>published</code>, parse as '''<code>dt-published</code>'''. parse for the first <code><time></code> element with class name of <code>entry-date</code> and non-empty <code>datetime</code> attribute inside an hentry, if there is no <code>published</code> property, use that time element's <code>datetime</code> attribute value for the <code>dt-published</code> property. Evidence: default WordPress themes 2011-2014([https://wp-themes.com/twentyeleven/][https://wp-themes.com/twentytwelve/][https://wp-themes.com/twentythirteen/][https://wp-themes.com/twentyfourteen/]).
* <code>rel=author</code> - in the absence of <code>author</code>, parse as '''<code>u-author</code>'''. While not a class name nor typical microformats property, rel=author was commonly used to link to an author's URL. Thus parsers should look for rel=author hyperlinks inside an hentry (or even on the same page, preceding the hentry), use the absolute version of it as a value for the '''<code>u-author</code>''' property if there is no "author" property. (citations to "hentry" examples in the wild that <em>depend</em> on rel=author needed to accepted this proposal. Note: default WordPress themes twentyeleven, twentytwelve, twentythirteen, twentyfourteen all use rel=author but only inside class="author vcard", and thus rel=author can be ignored since authorship is already picked up by existing <code>author</code> backcompat parsing.)

=== 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|rel=bookmark]]?''

A: tl;dr: use <code>class="u-url u-uid"</code> instead of <code>rel=bookmark</code> 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.

<nowiki>*</nowiki> even though rel=bookmark in particular is article-element / sectioning scoped in HTML5[http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-bookmark], 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 <code>entry-*</code> 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#Could_hAtom_instead_use_title_content_and_summary|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: [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-128 2012-08-30 IRC conversation].

== Related Work ==
Work that re-uses or builds upon h-entry:
* [https://mailpile.pagekite.me:8080/p/Open_Message_Format Mailpile Open Message Format] is using h-entry with structured properties, e.g. p-author h-card.

== Background ==
This work is based on the existing [[hAtom]] microformat, and extensive selfdogfooding in the [http://indiewebcamp.com 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 [[h-entry-issues|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|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|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_Additions|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|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|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 ==
* [[h-feed]]
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-geo]]
* [[hCard]]

[[Category:Specifications]]

h-entry

2022-08-13T16:20:21Z

Dshanske: /* Draft Properties */

{{DISPLAYTITLE:h-entry}}
<dfn style="font-style:normal;font-weight:bold">h-entry</dfn> 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 [[microformats|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]].

;<span id="status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [[h-entry-issues|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|change control]] process.
;<span id="participate">Participate</span>
:[https://github.com/microformats/h-entry/issues Open Issues]
:[[h-entry-issues|Resolved issues before 2012-246]]
:[[IRC]]
:Advance the spec by following explicit [[#change_control|change control]] process
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__

== Example ==
Here is a simple blog post example:

<source lang=html4strict>
<article class="h-entry">
<h1 class="p-name">Microformats are amazing</h1>
<p>Published by <a class="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></p>

<p class="p-summary">In which I extoll the virtues of using microformats.</p>

<div class="e-content">
<p>Blah blah blah</p>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"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>"
}
]
}
}
]
}
</source>

== Get started ==
The class '''<code>h-entry</code>''' 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 optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

=== Core Properties ===
The following ''core'' h-entry properties have broad consensus and are broadly interoperably published and consumed:
* '''<code>p-name</code>''' - entry name/title
* '''<code>p-summary</code>''' - short entry summary
* '''<code>e-content</code>''' - full content of the entry
* '''<code>dt-published</code>''' - when the entry was published
* '''<code>dt-updated</code>''' - when the entry was updated
* '''<code>p-author</code>''' - who wrote the entry, optionally embedded [[h-card]](s)
* '''<code>p-category</code>''' - entry categories/tags
* '''<code>u-url</code>''' - entry permalink URL
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical entry URL
* '''<code>p-location</code>''' - location the entry was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code id="u-syndication">u-syndication</code>''' - URL(s) of syndicated copies of this post. The property equivalent of [[rel-syndication]] ([http://erinjo.is/2014/checked-into-rockit-colabs-23 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]) ([https://kartikprabhu.com/notes/re-citizen-of-indieweb example])
* '''<code id="p-rsvp">p-rsvp</code>''' (enum, use <data> element or [[value-class-pattern]])
** "yes", "no", "maybe", "interested". Case-insensitive values, normalized to lowercase. Examples:
** <code><nowiki>... <data class="p-rsvp" value="YES">is going</data> to ...</nowiki></code>, or
** <code><nowiki>... <data class="p-rsvp" value="Maybe">might go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="no">unable to go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="iNtEreSTed">am interested/tracking/watching</data> ...</nowiki></code>
* '''<code id="u-like-of">u-like-of</code>''' - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded [[h-cite]]
* '''<code id="u-repost-of">u-repost-of</code>''' - the URL which the h-entry is considered a “repost” of. Optionally an embedded [[h-cite]].

=== 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 id="p-comment">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])
** [https://github.com/microformats/h-entry/issues/20 Issue 20]
* '''<code id="u-photo">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.
** [https://github.com/microformats/h-entry/issues/4 Issue 4: u-photo draft->core bc way more than 3+ pub and consuming impls/sites]
** [https://github.com/microformats/h-entry/issues/24 Issue 24: Update Definition of Draft Property u-photo]
* '''<code id="u-video">u-video</code>''' - special u- parsing rules for <code><video src> & <source src></code>
** [https://github.com/microformats/h-entry/issues/5 Issue 5]

=== 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 awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:
* '''<code>u-audio</code>''' - special u- parsing rules for <code><audio src> & <source src></code>. Examples: [http://transportini.com/ Transportini],[https://indieweb.org/podcast#How_to_podcast_with_h-feed possibly more]
** [https://github.com/microformats/h-entry/issues/6 Issue 6]
* '''<code>u-like</code>''' - similar to p-comment, URL to a like post of the current post, e.g. in a responses list or facepile.
* '''<code>u-repost</code>''' - similar to u-like, URL to a repost of the current post, e.g. in a responses list or facepile.
* '''<code>u-bookmark-of</code>''' - indicates this h-entry is a bookmark of another URL. Optionally an [[h-cite]]. See [https://indieweb.org/bookmark indieweb.org/bookmark] for examples in the wild.
** [https://github.com/microformats/h-entry/issues/12 Issue 12]
* '''<code>u-featured</code>''' - 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]].
** +1 sknebel: https://github.com/microformats/h-entry/issues/14
* '''<code>p-latitude</code>''' - latitude of the location of the entry
* '''<code>p-longitude</code>''' - longitude of the location of the entry
* '''<code>p-duration</code>''' - duration of an audio or video file in the entry. https://indieweb.org/duration Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
** [https://github.com/microformats/h-entry/issues/21 Issue 21]
* '''<code>p-size</code>''' - size in bytes of an audio or video file in the entry. https://indieweb.org/size Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>u-listen-of</code>''' - also known as a 'scrobble', indicates this h-entry is a listen of another URL. Optionally an h-cite. https://github.com/microformats/h-entry/issues/11
* '''<code>u-watch-of</code>''' - indicates this h-entry is a watch of another URL, a visual version of the scrobble. Optionally an h-cite. https://github.com/microformats/h-entry/issues/17
* '''<code>p-read-of</code>''' - indicates this h-entry is a read post of some written work (book or other document). The value can be the title of the work or an h-cite. Proposal also mentions <code>u-read-of</code>, where the value would be a URL to the written work or a representative citation page. https://github.com/microformats/h-entry/issues/10
* '''<code>u-translation-of</code>''' - indicates this h-entry is a translation of the linked URL into another language. Can be used in the same way as the existing <code>u-like-of</code> and <code>u-repost-of</code> properties, with just the URL to the original h-entry, or (optionally) contain an embedded <code>h-cite</code>. https://github.com/microformats/h-entry/issues/26
* '''<code>u-checkin</code>''' - the URL of the venue/location h-card which the h-entry is considered a “checkin” of. Optionally an embedded h-card. https://github.com/microformats/h-entry/issues/15

The following interpretation is also proposed addition:
* if the <code>p-location</code> is also an embedded [[h-card]], the entry is treated as a "checkin".
** -1 [[User:Aaronpk|Aaronpk]] 14:22, 19 January 2017 (UTC) [https://aaronparecki.com/2017/01/13/21/ this post] is not a checkin, but has an h-card as the p-location property.

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: [[h-entry#change_control|change control]]

== Property Details ==
This section is a stub.
=== p-location ===
'''<code>p-location</code>''' has been re-used from [[h-event]].

== FAQ ==
=== p-name of a note ===
<div class="discussion">
* '''What is the <code>p-name</code> of a [https://indieweb.org/note note]?'''
** You probably should avoid adding <code>p-name</code> to notes. See https://indieweb.org/note for more discussion of the topic.
</div>

=== venue an entry was posted from ===
<div class="discussion">
* '''How do you indicate a named venue where an entry was posted from? Like a restaurant or park.'''
** Use an embedded [[h-card]] microformat on a <code>p-location</code> property value.
</div>

=== address an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== lat long an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== dt-published property and HTML5 time element ===
<div class="discussion">
* '''Does the dt-published property need to be a time element?'''
** The <code>dt-published</code> property should be a <code><time></code> 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.
</div>

=== 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:
:* <code>url</code>
:* <code>published</code> — if there is no "published" date for the "entry", then reconsider whether it is correct (or worth) marking it up as an entry.

; 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:
:* <code>content</code> (or <code>summary</code> at least) - especially for structured content. For a plain text note, the content/summary (whichever is used) should be the same as the <code>name</code>, otherwise it will be implied from the text content of the root element.
:* <code>name</code> - for explicitly named/titled entries like blog posts and articles. Otherwise the entry is assumed to be a "title-less" [https://indieweb.org/note note] (like a tweet).
:* <code>author</code> - including a nested <code>[[h-card]]</code> with author details like name, photo, url.

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

* ... add uses of h-entry you see in the wild here.
* ind.ie mark up their [https://ind.ie/blog blog] listing and [https://ind.ie/blog/autumn-events-2014/ permalink] pages with h-entry
* David John Mead marks up his profile, blog posts and comments with h-card, h-entry and h-cite on [http://davidjohnmead.com davidjohnmead.com]
* [[User:Brian|Brian Suda]] marks up his blog posts up with h-entry and h-card on [http://optional.is/required/ optional.is]
* Ashton McAllen marks up his blog posts, reposts, comments and likes with h-entry, h-card and h-cite on [http://acegiak.net/ acegiak.net]
* Emma Kuo marks up her blog posts and notes with h-entry and h-card on [http://notenoughneon.com/ notenoughneon.com]
* Scott Jenson marks up his blog posts with h-entry and h-card on [http://jenson.org/ jenson.org]
* Emily McAllen marks up her blog posts with h-entry and h-card on [http://blackwoolholiday.com/ blackwoolholiday.com]
* Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on [https://snarfed.org/ snarfed.org]
* Barry Frost marks up his notes with h-entry, h-card and h-cite on [http://barryfrost.com/ barryfrost.com]
* Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on [http://caseorganic.com/ caseorganic.com]
* Johannes Ernst marks up his blog posts with h-entry on [http://upon2020.com/blog/ upon2020.com]
* Michiel de Jong marks up his profile and notes with h-entry and h-card on [https://michielbdejong.com/ michielbdejong.com]
* Mike Taylor marks up his profile and blog posts with h-card and h-entry on [https://bear.im/bearlog/ bear.im]
* Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on [http://erinjo.is/ erinjo.is]
* Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on [https://jeena.net/ jeena.net]
* Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on [http://andysylvester.com/2014/03/01/howto-setting-up-the-selfoss-feed-reader-with-microformats-support/ andysylvester.com] (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --[[User:Barnabywalters|bw]] 14:44, 13 March 2014 (UTC))
* Chloe Weil marks up her blog posts with h-entry on [http://chloeweil.com/blog chloeweil.com]
* Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on [http://christopheducamp.com/ christopheducamp.com]
* Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on [http://glennjones.net/ glennjones.net]
* Marcus Povey marks up his blog posts and profile with h-entry and h-card on [http://www.marcus-povey.co.uk/ marcus-povey.co.uk]
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* Kyle Mahan marks up his profile and notes with h-card and h-entry on [http://kylewm.com/ kylewm.com]
* Okinawan-lyrics marks up his posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* App.net marks up profile pages and permalink pages with h-entry as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* The Twitter archive browser UI uses h-entry and h-card internally, unfortunately it’s not exposed as HTML in static files anywhere
* Brett Comnes marks up his posts with h-entry and h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like ([http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his posts up with h-card and h-entry, as well as draft u-in-reply-to and experimental u-like properties ([http://sandeep.io/101 example])
* Laurent Eschenauer marks up his posts with h-entry ([http://eschnou.com/entry/first-autonomous-flight-of-my-nodecopter-62-24992.html example])
* Tom Morris marks up his posts using h-entry ([http://tommorris.org/posts/8417 example])
* Numerous newer W3C specs, e.g.
** [http://www.w3.org/TR/2013/CR-css3-values-20130404/ CSS Values and Units Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/CR-css3-conditional-20130404/ CSS Conditional Rules Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/WD-css3-page-20130314/ CSS Paged Media Module Level 3 - 2013-03-14]
** [http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/ CSS Counter Styles Level 3 - 2013-02-21]
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry.
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Aaron Parecki uses h-entry to mark up notes, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-entry on his home page, as well as h-entry on all post permalinks, e.g. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], with [[rel-prev]]/[[rel-next]] (if applicable) to indicate prev/next posts
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-entry on all notes and articles, as well as nested within notes as reply contexts [http://waterpigs.co.uk/notes/1468/ example] and comments [http://waterpigs.co.uk/notes/1482/ example].

=== offline ===
* spreadly marks up share permalink pages with h-entry, as well as minimal h-cards and experimental p-like properties

== Validating ==
* '''[http://indiewebify.me/validate-h-entry/ indiewebify.me h-entry validator]''' parses [[h-entry]] markup, finds common errors and makes suggestions for things to add, with code samples
* '''[http://shrewdness.waterpigs.co.uk/test/ Shrewdness h-entry/h-feed validator]''' shows how shrewdness interprets+displays h-entries, with original source and interim formats, works for single h-entries and feed pages

{{h-spec-section-validating}}

== 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 [https://indieweb.org/ 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.
* [https://gnu.io/social/ GNUsocial] [https://git.gnu.io/gnu/gnu-social/ source code]
* [https://hubzilla.org/hubzilla/ Hubzilla] [https://github.org/redmatrix/hubzilla source code]
* [http://friendica.com/ Friendica] [https://github.org/friendica/friendica source code]
* [http://github.com/dissolve/inkblot InkBlot]
* ...

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

<source lang=html4strict>
<article class="h-entry hentry">
<h1 class="p-name entry-title">A Tale Of Two Tags</h1>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="e-content entry-content">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
<p>The a tag is perhaps the best of HTML, yet its corresponding invisible link tag has uses too.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>
</source>

{{note|Note: you may use any valid HTML5 elements. The <code>article h1 address time</code> elements are used in the example as semantically richer suggestions, however in general <code>div span</code> work fine too. The <code>time</code> element is special though in that its <code>datetime</code> 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: <code id="hentry">hentry</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

* <code>entry-title</code> - parse as '''<code>p-name</code>'''
* <code>entry-summary</code> - parse as '''<code>p-summary</code>'''
* <code>entry-content</code> - parse as '''<code>e-content</code>'''
* <code>published</code> - parse as '''dt-'''
* <code>updated</code> - parse as '''dt-'''
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>category</code>
* <code>rel=bookmark</code> - parse as '''<code>u-url</code>'''. While not a class name nor typical microformats property, rel=bookmark was the only way to indicate an hentry permalink. Thus parsers should look for rel=bookmark hyperlinks inside an hentry, and take their "href" value as a value for a '''<code>u-url</code>''' property, including handling any relative URL resolution.
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hentry. Thus parsers should look for rel=tag hyperlinks inside an hentry, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

Proposed: ([https://github.com/microformats/h-entry/issues/7 follow-up in issue #7])
* <code>time.entry-date[datetime]</code> - in the absence of <code>published</code>, parse as '''<code>dt-published</code>'''. parse for the first <code><time></code> element with class name of <code>entry-date</code> and non-empty <code>datetime</code> attribute inside an hentry, if there is no <code>published</code> property, use that time element's <code>datetime</code> attribute value for the <code>dt-published</code> property. Evidence: default WordPress themes 2011-2014([https://wp-themes.com/twentyeleven/][https://wp-themes.com/twentytwelve/][https://wp-themes.com/twentythirteen/][https://wp-themes.com/twentyfourteen/]).
* <code>rel=author</code> - in the absence of <code>author</code>, parse as '''<code>u-author</code>'''. While not a class name nor typical microformats property, rel=author was commonly used to link to an author's URL. Thus parsers should look for rel=author hyperlinks inside an hentry (or even on the same page, preceding the hentry), use the absolute version of it as a value for the '''<code>u-author</code>''' property if there is no "author" property. (citations to "hentry" examples in the wild that <em>depend</em> on rel=author needed to accepted this proposal. Note: default WordPress themes twentyeleven, twentytwelve, twentythirteen, twentyfourteen all use rel=author but only inside class="author vcard", and thus rel=author can be ignored since authorship is already picked up by existing <code>author</code> backcompat parsing.)

=== 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|rel=bookmark]]?''

A: tl;dr: use <code>class="u-url u-uid"</code> instead of <code>rel=bookmark</code> 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.

<nowiki>*</nowiki> even though rel=bookmark in particular is article-element / sectioning scoped in HTML5[http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-bookmark], 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 <code>entry-*</code> 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#Could_hAtom_instead_use_title_content_and_summary|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: [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-128 2012-08-30 IRC conversation].

== Related Work ==
Work that re-uses or builds upon h-entry:
* [https://mailpile.pagekite.me:8080/p/Open_Message_Format Mailpile Open Message Format] is using h-entry with structured properties, e.g. p-author h-card.

== Background ==
This work is based on the existing [[hAtom]] microformat, and extensive selfdogfooding in the [http://indiewebcamp.com 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 [[h-entry-issues|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|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|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_Additions|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|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|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 ==
* [[h-feed]]
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-geo]]
* [[hCard]]

[[Category:Specifications]]

h-feed

2021-09-29T03:03:14Z

Dshanske: /* FAQ */

{{DISPLAYTITLE:h-feed}}

<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-feed</dfn> is a simple, open format for publishing a stream or feed of [[h-entry]] posts, like complete posts on a home page or archive pages, or summaries or other brief lists of posts. h-feed is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-feed is the [[microformats2]] update to [[hAtom]], and in particular its "hfeed" root class.

;<span id="status">Status</span>
:'''h-feed''' is a microformats.org draft specification.
:h-feed is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-feed up as a classic [[hAtom]] "hfeed".

;<span id="participate">Participate</span>
:[https://github.com/microformats/h-feed/issues Open Issues]
:[[IRC]]
;License
: {{cc0-owfa-license}}
__TOC__

== Properties ==
h-feed properties, inside an element with class '''h-feed'''. All properties are optional.

root class name: h-feed

=== Core Properties ===
The following ''core'' h-feed properties have broad consensus:
* '''<code>p-name</code>''' - name of the feed
* '''<code>p-author</code>''' - author of the feed, optionally embed an [[h-card]] {{main|h-card}}
* '''<code>u-url</code>''' - URL of the feed
* '''<code>u-photo</code>''' - representative photo / icon for the feed

children:
* nested [[h-entry]] objects representing the items of the feed

=== Draft Properties ===
None currently.

=== Proposed Properties ===
The following properties are proposed additions based on various observed examples in the wild, but are awaiting at least one reader / real world consuming code example to become a draft property:
* '''<code>p-summary</code>''' - based on non-trivial actual content usage of "atom:subtitle" on Blogger and WordPress.com featured blogs's Atom feeds.
* '''<code>p-entry</code>''' - to be more consistent with the cascading of p-author or [http://microformats.org/wiki/comment-brainstorming#Proposal p-comment].

== Proposed Additions ==

* Proposal that h-feed not be limited to h-entry, due use cases for feeds of h-cards or h-events https://github.com/microformats/h-feed/issues/3
* Proposal to add implied h-feed in cases where no h-feed is explicitly marked up. https://github.com/microformats/h-feed/issues/1

== Discovery ==
Implementations may discover one or more h-feeds in several ways:
* If the implementation has already parsed an HTML document, it can look for all elements with a class name of "h-feed" in the DOM tree.
* If the implementation has been given a URL (e.g. from a user entering it) to do h-feed discovery, it may:
** Parse the document per [[microformats2-parsing]] and look in the top level collection of items for those of type "h-feed"
** OR it may also do traditional feed discovery by looking through link elements with a rel value of "alternate", and once it finds one with media type of "[https://indieweb.org/text/mf2%2Bhtml text/mf2+html]", get its href, perform any relative-URL resolution as needed, and then parse the given URL (within a specific element matching a fragment in the URL if any) for microformats2 items, again looking for top-level items (within that fragment element subtree if any) of type "h-feed"

Details:
* Implementations may load public h-feeds without having to pass cookies or any other user-identifying information
* Implementations should parse h-feed documents without executing any scripts (parse as if scripting is disabled or unimplemented)
* If an implementation needs only one h-feed, it should take the first one found in any of the above methods

=== Implied h-feed ===
In the absence of an explicit "h-feed" element, implementations may infer an h-feed of all top level microformats items in the document (as determined by [[microformats2-parsing]] the document).

E.g. if an archive page has a collection of h-entry elements at the top level, implementations may imply an h-feed container for all of them and treat the entire document as a feed.

== Examples in the wild ==

See https://indieweb.org/h-feed#IndieWeb_Examples for examples of h-feed in the wild.

== Consumers ==

See https://indieweb.org/h-feed#Consumers_of_H-Feed for examples of implementations that consume h-feed.

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[hAtom]] classnames in addition to the more future-proof h-feed properties, for example:

<source lang=html4strict>
<div class="h-feed hfeed">
<h1 class="p-name site-title">The Markup Blog</h1>
<p class="p-summary site-description">Stories of elements of their attributes.</p>

<article class="h-entry hentry">
<a class="u-url" rel="bookmark" href="2020/06/22/balanced-divisive-complementary">
<h2 class="p-name entry-title">A Tale Of Two Tags: Part 2</h2>
</a>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-22T09:45:57-07:00">June 21, 2012</time>
<div class="p-summary entry-summary">
<p>From balanced harmony, to divisive misunderstandings, to complementary roles.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>

<article class="h-entry hentry">
<a class="u-url" rel="bookmark" href="2020/06/20/best-visible-alternative-invisible">
<h2 class="p-name entry-title">A Tale Of Two Tags: Part 1</h2>
</a>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="p-summary entry-summary">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>

</div>
</source>

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

The class '''<code>hfeed</code>''' is a ''backward compatible root class name'' that indicates the presence of an [[hAtom]] feed.

Backward compatibility hAtom property class names and rel values are listed 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-feed" is found, don't look for an "hfeed" on the same element.

Compat root class name: <code id="hfeed">hfeed</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

(this section is a stub and needs review and citations to note what real world examples would each of these backcompat parsing rules actually help parse)

* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the defined way to tag an hfeed. Thus parsers should look for rel=tag hyperlinks inside an hfeed, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.
* <code>site-title</code> - parse as '''<code>p-name</code>''' [WordPress (Core? Typical themes?) has this class name by default, and without it buggy parsers may imply p-name as the whole h-feed ([http://microformats.org/wiki/microformats2-parsing#parsing_for_implied_properties implied properties only apply to actual h-x roots, not backcompat]).]
* <code>site-description</code> - parse as '''<code>p-summary</code>''' [WordPress (Core? Typical themes?) has this class name by default]

If no "h-feed" nor "hfeed" element is found, however multiple top-level [[h-entry]] elements (explicit or backcompat) are found, implementations may use:
* top level [[h-entry]] elements as items in a synthetic h-feed.
* <code><title></code> of the page or the URL of the page as '''<code>p-name</code>'''
* https://indieweb.org/authorship on the page to discover default authorship for any h-entry posts lacking explicit parsed <code>author</code> properties.

== FAQ ==
=== How do I avoid duplicating the page title ===
''I want to use the name (title) of my page as the name of my feed, how do I avoid duplicating the page title somewhere invisibly on the page as the feed name?''

If you want re-use the <title> of your page as the name of your feed, you can do so by putting the h-feed root class name on the <html> element, and the p-name property class name on the <title> element, e.g. here's a snippet showing how those tags would look:
<source lang=html4strict>
<html class="h-feed">
…
<title class="p-name">The Markup Blog</title>
…
</source>

== See Also ==
* [[h-entry]]
* [[microformats2]]
* [[hAtom]]

[[Category:Draft Specifications]]

h-feed

2021-09-29T02:31:58Z

Dshanske: /* Implementations */

{{DISPLAYTITLE:h-feed}}

<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-feed</dfn> is a simple, open format for publishing a stream or feed of [[h-entry]] posts, like complete posts on a home page or archive pages, or summaries or other brief lists of posts. h-feed is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-feed is the [[microformats2]] update to [[hAtom]], and in particular its "hfeed" root class.

;<span id="status">Status</span>
:'''h-feed''' is a microformats.org draft specification.
:h-feed is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-feed up as a classic [[hAtom]] "hfeed".

;<span id="participate">Participate</span>
:[https://github.com/microformats/h-feed/issues Open Issues]
:[[IRC]]
;License
: {{cc0-owfa-license}}
__TOC__

== Properties ==
h-feed properties, inside an element with class '''h-feed'''. All properties are optional.

root class name: h-feed

=== Core Properties ===
The following ''core'' h-feed properties have broad consensus:
* '''<code>p-name</code>''' - name of the feed
* '''<code>p-author</code>''' - author of the feed, optionally embed an [[h-card]] {{main|h-card}}
* '''<code>u-url</code>''' - URL of the feed
* '''<code>u-photo</code>''' - representative photo / icon for the feed

children:
* nested [[h-entry]] objects representing the items of the feed

=== Draft Properties ===
None currently.

=== Proposed Properties ===
The following properties are proposed additions based on various observed examples in the wild, but are awaiting at least one reader / real world consuming code example to become a draft property:
* '''<code>p-summary</code>''' - based on non-trivial actual content usage of "atom:subtitle" on Blogger and WordPress.com featured blogs's Atom feeds.
* '''<code>p-entry</code>''' - to be more consistent with the cascading of p-author or [http://microformats.org/wiki/comment-brainstorming#Proposal p-comment].

== Proposed Additions ==

* Proposal that h-feed not be limited to h-entry, due use cases for feeds of h-cards or h-events https://github.com/microformats/h-feed/issues/3
* Proposal to add implied h-feed in cases where no h-feed is explicitly marked up. https://github.com/microformats/h-feed/issues/1

== Discovery ==
Implementations may discover one or more h-feeds in several ways:
* If the implementation has already parsed an HTML document, it can look for all elements with a class name of "h-feed" in the DOM tree.
* If the implementation has been given a URL (e.g. from a user entering it) to do h-feed discovery, it may:
** Parse the document per [[microformats2-parsing]] and look in the top level collection of items for those of type "h-feed"
** OR it may also do traditional feed discovery by looking through link elements with a rel value of "alternate", and once it finds one with media type of "[https://indieweb.org/text/mf2%2Bhtml text/mf2+html]", get its href, perform any relative-URL resolution as needed, and then parse the given URL (within a specific element matching a fragment in the URL if any) for microformats2 items, again looking for top-level items (within that fragment element subtree if any) of type "h-feed"

Details:
* Implementations may load public h-feeds without having to pass cookies or any other user-identifying information
* Implementations should parse h-feed documents without executing any scripts (parse as if scripting is disabled or unimplemented)
* If an implementation needs only one h-feed, it should take the first one found in any of the above methods

=== Implied h-feed ===
In the absence of an explicit "h-feed" element, implementations may infer an h-feed of all top level microformats items in the document (as determined by [[microformats2-parsing]] the document).

E.g. if an archive page has a collection of h-entry elements at the top level, implementations may imply an h-feed container for all of them and treat the entire document as a feed.

== Examples in the wild ==

See https://indieweb.org/h-feed#IndieWeb_Examples for examples of h-feed in the wild.

== Consumers ==

See https://indieweb.org/h-feed#Consumers_of_H-Feed for examples of implementations that consume h-feed.

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[hAtom]] classnames in addition to the more future-proof h-feed properties, for example:

<source lang=html4strict>
<div class="h-feed hfeed">
<h1 class="p-name site-title">The Markup Blog</h1>
<p class="p-summary site-description">Stories of elements of their attributes.</p>

<article class="h-entry hentry">
<a class="u-url" rel="bookmark" href="2020/06/22/balanced-divisive-complementary">
<h2 class="p-name entry-title">A Tale Of Two Tags: Part 2</h2>
</a>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-22T09:45:57-07:00">June 21, 2012</time>
<div class="p-summary entry-summary">
<p>From balanced harmony, to divisive misunderstandings, to complementary roles.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>

<article class="h-entry hentry">
<a class="u-url" rel="bookmark" href="2020/06/20/best-visible-alternative-invisible">
<h2 class="p-name entry-title">A Tale Of Two Tags: Part 1</h2>
</a>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="p-summary entry-summary">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>

</div>
</source>

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

The class '''<code>hfeed</code>''' is a ''backward compatible root class name'' that indicates the presence of an [[hAtom]] feed.

Backward compatibility hAtom property class names and rel values are listed 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-feed" is found, don't look for an "hfeed" on the same element.

Compat root class name: <code id="hfeed">hfeed</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

(this section is a stub and needs review and citations to note what real world examples would each of these backcompat parsing rules actually help parse)

* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the defined way to tag an hfeed. Thus parsers should look for rel=tag hyperlinks inside an hfeed, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.
* <code>site-title</code> - parse as '''<code>p-name</code>''' [WordPress (Core? Typical themes?) has this class name by default, and without it buggy parsers may imply p-name as the whole h-feed ([http://microformats.org/wiki/microformats2-parsing#parsing_for_implied_properties implied properties only apply to actual h-x roots, not backcompat]).]
* <code>site-description</code> - parse as '''<code>p-summary</code>''' [WordPress (Core? Typical themes?) has this class name by default]

If no "h-feed" nor "hfeed" element is found, however multiple top-level [[h-entry]] elements (explicit or backcompat) are found, implementations may use:
* top level [[h-entry]] elements as items in a synthetic h-feed.
* <code><title></code> of the page or the URL of the page as '''<code>p-name</code>'''
* https://indieweb.org/authorship on the page to discover default authorship for any h-entry posts lacking explicit parsed <code>author</code> properties.

== FAQ ==
=== How do I avoid duplicating the page title ===
''I want to use the name (title) of my page as the name of my feed, how do I avoid duplicating the page title somewhere invisibly on the page as the feed name?''

If you want re-use the <title> of your page as the name of your feed, you can do so by putting the h-feed root class name on the <html> element, and the p-name property class name on the <title> element, e.g. here's a snippet showing how those tags would look:
<source lang=html4strict>
<html class="h-feed">
…
<title class="p-name">The Markup Blog</title>
…
</source>

=== What should a subscriber do with a page with multiple feeds ===
''What do I do when a user subscribes to a URL with multiple distinct h-feeds?''

A feed reader should subscribe to the first h-feed it finds at a URL.

Related: http://indiewebcamp.com/reader

== See Also ==
* [[h-entry]]
* [[microformats2]]
* [[hAtom]]

[[Category:Draft Specifications]]

h-feed

2021-09-29T02:21:22Z

Dshanske:

{{DISPLAYTITLE:h-feed}}

<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-feed</dfn> is a simple, open format for publishing a stream or feed of [[h-entry]] posts, like complete posts on a home page or archive pages, or summaries or other brief lists of posts. h-feed is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-feed is the [[microformats2]] update to [[hAtom]], and in particular its "hfeed" root class.

;<span id="status">Status</span>
:'''h-feed''' is a microformats.org draft specification.
:h-feed is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-feed up as a classic [[hAtom]] "hfeed".

;<span id="participate">Participate</span>
:[https://github.com/microformats/h-feed/issues Open Issues]
:[[IRC]]
;License
: {{cc0-owfa-license}}
__TOC__

== Properties ==
h-feed properties, inside an element with class '''h-feed'''. All properties are optional.

root class name: h-feed

=== Core Properties ===
The following ''core'' h-feed properties have broad consensus:
* '''<code>p-name</code>''' - name of the feed
* '''<code>p-author</code>''' - author of the feed, optionally embed an [[h-card]] {{main|h-card}}
* '''<code>u-url</code>''' - URL of the feed
* '''<code>u-photo</code>''' - representative photo / icon for the feed

children:
* nested [[h-entry]] objects representing the items of the feed

=== Draft Properties ===
None currently.

=== Proposed Properties ===
The following properties are proposed additions based on various observed examples in the wild, but are awaiting at least one reader / real world consuming code example to become a draft property:
* '''<code>p-summary</code>''' - based on non-trivial actual content usage of "atom:subtitle" on Blogger and WordPress.com featured blogs's Atom feeds.
* '''<code>p-entry</code>''' - to be more consistent with the cascading of p-author or [http://microformats.org/wiki/comment-brainstorming#Proposal p-comment].

== Proposed Additions ==

* Proposal that h-feed not be limited to h-entry, due use cases for feeds of h-cards or h-events https://github.com/microformats/h-feed/issues/3
* Proposal to add implied h-feed in cases where no h-feed is explicitly marked up. https://github.com/microformats/h-feed/issues/1

== Discovery ==
Implementations may discover one or more h-feeds in several ways:
* If the implementation has already parsed an HTML document, it can look for all elements with a class name of "h-feed" in the DOM tree.
* If the implementation has been given a URL (e.g. from a user entering it) to do h-feed discovery, it may:
** Parse the document per [[microformats2-parsing]] and look in the top level collection of items for those of type "h-feed"
** OR it may also do traditional feed discovery by looking through link elements with a rel value of "alternate", and once it finds one with media type of "[https://indieweb.org/text/mf2%2Bhtml text/mf2+html]", get its href, perform any relative-URL resolution as needed, and then parse the given URL (within a specific element matching a fragment in the URL if any) for microformats2 items, again looking for top-level items (within that fragment element subtree if any) of type "h-feed"

Details:
* Implementations may load public h-feeds without having to pass cookies or any other user-identifying information
* Implementations should parse h-feed documents without executing any scripts (parse as if scripting is disabled or unimplemented)
* If an implementation needs only one h-feed, it should take the first one found in any of the above methods

=== Implied h-feed ===
In the absence of an explicit "h-feed" element, implementations may infer an h-feed of all top level microformats items in the document (as determined by [[microformats2-parsing]] the document).

E.g. if an archive page has a collection of h-entry elements at the top level, implementations may imply an h-feed container for all of them and treat the entire document as a feed.

== Examples in the wild ==

See https://indieweb.org/h-feed#IndieWeb_Examples for examples of h-feed in the wild.

== Implementations ==
=== Readers ===
* [https://github.com/kylewm/woodwind Woodwind]
* [https://github.com/barnabywalters/shrewdness Shrewdness]

=== Proxies ===
* Bridgy

=== Converters ===
* '''[http://unmung.com unmung]''' - will transform an RSS or Atom feed into an [[h-feed]] containing h-entries

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[hAtom]] classnames in addition to the more future-proof h-feed properties, for example:

<source lang=html4strict>
<div class="h-feed hfeed">
<h1 class="p-name site-title">The Markup Blog</h1>
<p class="p-summary site-description">Stories of elements of their attributes.</p>

<article class="h-entry hentry">
<a class="u-url" rel="bookmark" href="2020/06/22/balanced-divisive-complementary">
<h2 class="p-name entry-title">A Tale Of Two Tags: Part 2</h2>
</a>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-22T09:45:57-07:00">June 21, 2012</time>
<div class="p-summary entry-summary">
<p>From balanced harmony, to divisive misunderstandings, to complementary roles.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>

<article class="h-entry hentry">
<a class="u-url" rel="bookmark" href="2020/06/20/best-visible-alternative-invisible">
<h2 class="p-name entry-title">A Tale Of Two Tags: Part 1</h2>
</a>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="p-summary entry-summary">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>

</div>
</source>

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

The class '''<code>hfeed</code>''' is a ''backward compatible root class name'' that indicates the presence of an [[hAtom]] feed.

Backward compatibility hAtom property class names and rel values are listed 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-feed" is found, don't look for an "hfeed" on the same element.

Compat root class name: <code id="hfeed">hfeed</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

(this section is a stub and needs review and citations to note what real world examples would each of these backcompat parsing rules actually help parse)

* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the defined way to tag an hfeed. Thus parsers should look for rel=tag hyperlinks inside an hfeed, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.
* <code>site-title</code> - parse as '''<code>p-name</code>''' [WordPress (Core? Typical themes?) has this class name by default, and without it buggy parsers may imply p-name as the whole h-feed ([http://microformats.org/wiki/microformats2-parsing#parsing_for_implied_properties implied properties only apply to actual h-x roots, not backcompat]).]
* <code>site-description</code> - parse as '''<code>p-summary</code>''' [WordPress (Core? Typical themes?) has this class name by default]

If no "h-feed" nor "hfeed" element is found, however multiple top-level [[h-entry]] elements (explicit or backcompat) are found, implementations may use:
* top level [[h-entry]] elements as items in a synthetic h-feed.
* <code><title></code> of the page or the URL of the page as '''<code>p-name</code>'''
* https://indieweb.org/authorship on the page to discover default authorship for any h-entry posts lacking explicit parsed <code>author</code> properties.

== FAQ ==
=== How do I avoid duplicating the page title ===
''I want to use the name (title) of my page as the name of my feed, how do I avoid duplicating the page title somewhere invisibly on the page as the feed name?''

If you want re-use the <title> of your page as the name of your feed, you can do so by putting the h-feed root class name on the <html> element, and the p-name property class name on the <title> element, e.g. here's a snippet showing how those tags would look:
<source lang=html4strict>
<html class="h-feed">
…
<title class="p-name">The Markup Blog</title>
…
</source>

=== What should a subscriber do with a page with multiple feeds ===
''What do I do when a user subscribes to a URL with multiple distinct h-feeds?''

A feed reader should subscribe to the first h-feed it finds at a URL.

Related: http://indiewebcamp.com/reader

== See Also ==
* [[h-entry]]
* [[microformats2]]
* [[hAtom]]

[[Category:Draft Specifications]]

h-feed

2021-09-29T02:19:11Z

Dshanske: /* Move Examples in the wild out of the spec and cite the IndieWeb wiki */

{{DISPLAYTITLE:h-feed}}

<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-feed</dfn> is a simple, open format for publishing a stream or feed of [[h-entry]] posts, like complete posts on a home page or archive pages, or summaries or other brief lists of posts. h-feed is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-feed is the [[microformats2]] update to [[hAtom]], and in particular its "hfeed" root class.

;<span id="status">Status</span>
:'''h-feed''' is a microformats.org draft specification.
:h-feed is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-feed up as a classic [[hAtom]] "hfeed".

;<span id="participate">Participate</span>
:[https://github.com/microformats/h-feed/issues Open Issues]
:[[IRC]]
;License
: {{cc0-owfa-license}}
__TOC__

== Properties ==
h-feed properties, inside an element with class '''h-feed'''. All properties are optional.

root class name: h-feed

=== Core Properties ===
The following ''core'' h-feed properties have broad consensus:
* '''<code>p-name</code>''' - name of the feed
* '''<code>p-author</code>''' - author of the feed, optionally embed an [[h-card]] {{main|h-card}}
* '''<code>u-url</code>''' - URL of the feed
* '''<code>u-photo</code>''' - representative photo / icon for the feed

children:
* nested [[h-entry]] objects representing the items of the feed

=== Draft Properties ===
None currently.

=== Proposed Properties ===
The following properties are proposed additions based on various observed examples in the wild, but are awaiting at least one reader / real world consuming code example to become a draft property:
* '''<code>p-summary</code>''' - based on non-trivial actual content usage of "atom:subtitle" on Blogger and WordPress.com featured blogs's Atom feeds.
* '''<code>p-entry</code>''' - to be more consistent with the cascading of p-author or [http://microformats.org/wiki/comment-brainstorming#Proposal p-comment].

== Proposed Additions ==

* Proposal that h-feed not be limited to h-entry, due use cases for feeds of h-cards or h-events https://github.com/microformats/h-feed/issues/3
* Proposal to add implied h-feed in cases where no h-feed is explicitly marked up. https://github.com/microformats/h-feed/issues/1

== Discovery ==
Implementations may discover one or more h-feeds in several ways:
* If the implementation has already parsed an HTML document, it can look for all elements with a class name of "h-feed" in the DOM tree.
* If the implementation has been given a URL (e.g. from a user entering it) to do h-feed discovery, it may:
** Parse the document per [[microformats2-parsing]] and look in the top level collection of items for those of type "h-feed"
** OR it may also do traditional feed discovery by looking through link elements with a rel value of "alternate", and once it finds one with media type of "[https://indieweb.org/text/mf2%2Bhtml text/mf2+html]", get its href, perform any relative-URL resolution as needed, and then parse the given URL (within a specific element matching a fragment in the URL if any) for microformats2 items, again looking for top-level items (within that fragment element subtree if any) of type "h-feed"

Details:
* Implementations may load public h-feeds without having to pass cookies or any other user-identifying information
* Implementations should parse h-feed documents without executing any scripts (parse as if scripting is disabled or unimplemented)
* If an implementation needs only one h-feed, it should take the first one found in any of the above methods

=== Implied h-feed ===
In the absence of an explicit "h-feed" element, implementations may infer an h-feed of all top level microformats items in the document (as determined by [[microformats2-parsing]] the document).

E.g. if an archive page has a collection of h-entry elements at the top level, implementations may imply an h-feed container for all of them and treat the entire document as a feed.

== Use Cases ==
* Named feeds
** IndieWeb Readers are consuming home page feeds marked up with h-feed and using the name of the h-feed in their user interfce.

* Generate an Atom feed
** This seems like a legacy use-case, not sufficient to actually justify h-feed.

* Feed per channel of content - needs a name
** "I will have a feed per tag (channel) so I want to name them." - Sandeep Shetty in #indiewebcamp
** It appears there is some desire to create separate feeds for an indieweb site for separate subsets of content, and name them <em>explicitly</em> accordingly. This presents a need for a container object for the h-entry elements, where the container itself can have a name. This is a potential interesting use-case for an explicit 'h-feed'.

== Examples in the wild ==

See https://indieweb.org/h-feed#IndieWeb_Examples for examples of h-feed in the wild.

== Implementations ==
=== Readers ===
* [https://github.com/kylewm/woodwind Woodwind]
* [https://github.com/barnabywalters/shrewdness Shrewdness]

=== Proxies ===
* Bridgy

=== Converters ===
* '''[http://unmung.com unmung]''' - will transform an RSS or Atom feed into an [[h-feed]] containing h-entries

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[hAtom]] classnames in addition to the more future-proof h-feed properties, for example:

<source lang=html4strict>
<div class="h-feed hfeed">
<h1 class="p-name site-title">The Markup Blog</h1>
<p class="p-summary site-description">Stories of elements of their attributes.</p>

<article class="h-entry hentry">
<a class="u-url" rel="bookmark" href="2020/06/22/balanced-divisive-complementary">
<h2 class="p-name entry-title">A Tale Of Two Tags: Part 2</h2>
</a>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-22T09:45:57-07:00">June 21, 2012</time>
<div class="p-summary entry-summary">
<p>From balanced harmony, to divisive misunderstandings, to complementary roles.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>

<article class="h-entry hentry">
<a class="u-url" rel="bookmark" href="2020/06/20/best-visible-alternative-invisible">
<h2 class="p-name entry-title">A Tale Of Two Tags: Part 1</h2>
</a>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="p-summary entry-summary">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>

</div>
</source>

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

The class '''<code>hfeed</code>''' is a ''backward compatible root class name'' that indicates the presence of an [[hAtom]] feed.

Backward compatibility hAtom property class names and rel values are listed 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-feed" is found, don't look for an "hfeed" on the same element.

Compat root class name: <code id="hfeed">hfeed</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

(this section is a stub and needs review and citations to note what real world examples would each of these backcompat parsing rules actually help parse)

* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the defined way to tag an hfeed. Thus parsers should look for rel=tag hyperlinks inside an hfeed, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.
* <code>site-title</code> - parse as '''<code>p-name</code>''' [WordPress (Core? Typical themes?) has this class name by default, and without it buggy parsers may imply p-name as the whole h-feed ([http://microformats.org/wiki/microformats2-parsing#parsing_for_implied_properties implied properties only apply to actual h-x roots, not backcompat]).]
* <code>site-description</code> - parse as '''<code>p-summary</code>''' [WordPress (Core? Typical themes?) has this class name by default]

If no "h-feed" nor "hfeed" element is found, however multiple top-level [[h-entry]] elements (explicit or backcompat) are found, implementations may use:
* top level [[h-entry]] elements as items in a synthetic h-feed.
* <code><title></code> of the page or the URL of the page as '''<code>p-name</code>'''
* https://indieweb.org/authorship on the page to discover default authorship for any h-entry posts lacking explicit parsed <code>author</code> properties.

== FAQ ==
=== How do I avoid duplicating the page title ===
''I want to use the name (title) of my page as the name of my feed, how do I avoid duplicating the page title somewhere invisibly on the page as the feed name?''

If you want re-use the <title> of your page as the name of your feed, you can do so by putting the h-feed root class name on the <html> element, and the p-name property class name on the <title> element, e.g. here's a snippet showing how those tags would look:
<source lang=html4strict>
<html class="h-feed">
…
<title class="p-name">The Markup Blog</title>
…
</source>

=== What should a subscriber do with a page with multiple feeds ===
''What do I do when a user subscribes to a URL with multiple distinct h-feeds?''

A feed reader should subscribe to the first h-feed it finds at a URL.

Related: http://indiewebcamp.com/reader

== See Also ==
* [[h-entry]]
* [[microformats2]]
* [[hAtom]]

[[Category:Draft Specifications]]

faq-template

2021-08-20T05:08:00Z

Dshanske:

<h1> ((FORMAT-OR-SUBJECT-NAME)) FAQ </h1>

This page is for documenting Q&A about ((WIKILINK-TO-FORMAT-OR-SUBJECT)). If you have a new question to ask, please consider first asking your question on the [irc://irc.libera.chat/#microformats microformats irc channel]. New questions and answers should be added to the end of the list. If you have a new question but not an answer, please add it to ((WIKILINK-TO-FORMAT-OR-SUBJECT-issues)).

<h2>Editing this Page</h2>
Please do not use "?" or other punctuation in the headers - it helps to keep the URLs to their fragment identifiers shorter and easier to read, copy/paste etc. See [[how-to-play]] for more wiki editing guidelines.

<h2> Q&A </h2>

=== ((SUMMARY-QUESTION-WITHOUT-PUNCTUATION)) ===
''((COMPLETE-QUESTION))''
* COMPLETE-ANSWER

<h2>Related</h2>
* ((WIKILINK-TO-FORMAT-OR-SUBJECT))
* ((WIKILINK-TO-FORMAT-OR-SUBJECT-issues))

task-brainstorming

2021-08-20T05:06:22Z

Dshanske:

{{warning|Consider this document purely historical, and start any new to do work from the beginning of the process with [[task-research]] and documenting use-cases before re-brainstoring. See '''[[process]]''' for details for how to start that page and join the #microformats [[irc]] channel on Liberachat before proceeding any further.}}

= Task Brainstorming =

== Use Cases ==

To focus the discussion, please add use cases below that will help show what problems the citation microformat will be solving.

== Examples ==

Below please find an example snippet of markup incorporating classes from the proposed task microformat. These classes are woven into a form field for building the overall task output.

<form id="form1" name="form1" method="post" action=""> <br/> <h2> Assign Task</h2> <br/> <p> <br/> <label> <strong> Title:</strong> <br/> <input type="text" name="textfield" /> <br/> </label> <br/> </p> <br/> <p> <br/> <label class="priority"> <strong> Priority:</strong> <br/> <select name="select7"> <br/> <option value="Low"> Low</option> <br/> <option value="Medium" selected="selected"> Medium</option> <br/> <option value="High"> High</option> <br/> </select> <br/> </label> <br/> </p> <br/> <p> <br/> <label class="dtend"> <strong> Due date:</strong> <br/> <br /> <br/> <input name="radiobutton" type="radio" value="radiobutton" checked="checked" /> <br/> <select name="select"> <br/> <option value="January" selected> January</option> <br/> <option value="February"> February</option> <br/> <option value="March"> March</option> <br/> <option value="April"> April</option> <br/> <option value="May"> May</option> <br/> <option value="June"> June</option> <br/> <option value="July"> July</option> <br/> <option value="August"> August</option> <br/> <option value="September"> September</option> <br/> <option value="October"> October</option> <br/> <option value="November"> November</option> <br/> <option value="December"> December</option> <br/> </select> <br/> </label> <br/> <label> <br/> <select name="select2"> <br/> <option value="01"> 01</option> <br/> <option value="02"> 02</option> <br/> <option value="03"> 03</option> <br/> <option value="04"> 04</option> <br/> <option value="05"> 05</option> <br/> <option value="06"> 06</option> <br/> <option value="07"> 07</option> <br/> <option value="08"> 08</option> <br/> <option value="09"> 09</option> <br/> <option value="10"> 10</option> <br/> <option value="11"> 11</option> <br/> <option value="12"> 12</option> <br/> <option value="13"> 13</option> <br/> <option value="14"> 14</option> <br/> <option value="15"> 15</option> <br/> <option value="16"> 16</option> <br/> <option value="17"> 17</option> <br/> <option value="18"> 18</option> <br/> <option value="19"> 19</option> <br/> <option value="20"> 20</option> <br/> <option value="21"> 21</option> <br/> <option value="22"> 22</option> <br/> <option value="23"> 23</option> <br/> <option value="24"> 24</option> <br/> <option value="25"> 25</option> <br/> <option value="26"> 26</option> <br/> <option value="27"> 27</option> <br/> <option value="28"> 28</option> <br/> <option value="29"> 29</option> <br/> <option value="30"> 30</option> <br/> <option value="31"> 31</option> <br/> </select> <br/> </label> <br/> <label> <br/> <select name="select3"> <br/> <option value="2007"> 2007</option> <br/> <option value="2008"> 2008</option> <br/> <option value="2009"> 2009</option> <br/> <option value="2010"> 2010</option> <br/> </select> <br/> </label> <br/> </p> <br/> <p> <br/> <label class="rrule"> <br/> <input name="radiobutton" type="radio" value="radiobutton" /> <br/> Recurs: <br/> </label> <br/> <label class="freq"> <br/> <select name="select9"> <br/> <option value="Daily" selected="selected"> Daily</option> <br/> <option value="Weekly"> Weekly</option> <br/> <option value="Monthly"> Monthly</option> <br/> <option value="Annually"> Annually</option> <br/> </select> <br/> </label> <br/> <label> At: <br/> <select name="select10"> <br/> <option value="Early morning"> Before 7AM</option> <br/> <option value="7:00 AM"> 7:00 AM</option> <br/> <option value="8:00 AM"> 8:00 AM</option> <br/> <option value="9:00 AM" selected> 9:00 AM</option> <br/> <option value="10:00 AM"> 10:00 AM</option> <br/> <option value="11:00 AM"> 11:00 AM</option> <br/> <option value="12:00 PM"> 12:00 PM</option> <br/> <option value="1:00 PM"> 1:00 PM</option> <br/> <option value="2:00 PM"> 2:00 PM</option> <br/> <option value="3:00 PM"> 3:00 PM</option> <br/> <option value="4:00 PM"> 4:00 PM</option> <br/> <option value="5:00 PM"> 5:00 PM</option> <br/> <option value="6:00 PM"> 6:00 PM</option> <br/> <option value="7:00 PM"> 7:00 PM</option> <br/> <option value="Late night"> After 7PM</option> <br/> </select> <br/> </label> <br/> </p> <br/> <p> <br/> <label> <strong> Start date:</strong> <br/> <input name="radiobutton" type="radio" value="radiobutton" checked="checked" /> Today<br/> <input name="radiobutton" type="radio" value="radiobutton" /> <br/> <span class="dtend"> <br/> <select name="select11"> <br/> <option value="January" selected> January</option> <br/> <option value="February"> February</option> <br/> <option value="March"> March</option> <br/> <option value="April"> April</option> <br/> <option value="May"> May</option> <br/> <option value="June"> June</option> <br/> <option value="July"> July</option> <br/> <option value="August"> August</option> <br/> <option value="September"> September</option> <br/> <option value="October"> October</option> <br/> <option value="November"> November</option> <br/> <option value="December"> December</option> <br/> </select> <br/> </span> <br/> <select name="select13"> <br/> <option value="01"> 01</option> <br/> <option value="02"> 02</option> <br/> <option value="03"> 03</option> <br/> <option value="04"> 04</option> <br/> <option value="05"> 05</option> <br/> <option value="06"> 06</option> <br/> <option value="07"> 07</option> <br/> <option value="08"> 08</option> <br/> <option value="09"> 09</option> <br/> <option value="10"> 10</option> <br/> <option value="11"> 11</option> <br/> <option value="12"> 12</option> <br/> <option value="13"> 13</option> <br/> <option value="14"> 14</option> <br/> <option value="15"> 15</option> <br/> <option value="16"> 16</option> <br/> <option value="17"> 17</option> <br/> <option value="18"> 18</option> <br/> <option value="19"> 19</option> <br/> <option value="20"> 20</option> <br/> <option value="21"> 21</option> <br/> <option value="22"> 22</option> <br/> <option value="23"> 23</option> <br/> <option value="24"> 24</option> <br/> <option value="25"> 25</option> <br/> <option value="26"> 26</option> <br/> <option value="27"> 27</option> <br/> <option value="28"> 28</option> <br/> <option value="29"> 29</option> <br/> <option value="30"> 30</option> <br/> <option value="31"> 31</option> <br/> </select> <br/> <select name="select4"> <br/> <option value="2007"> 2007</option> <br/> <option value="2008"> 2008</option> <br/> <option value="2009"> 2009</option> <br/> <option value="2010"> 2010</option> <br/> </select> <br/> </label> <br/> </p> <br/> <p> <br/> <label class="dtrem"> <br/> <input type="checkbox" name="checkbox" value="checkbox" /> <br/> <strong> Alarm:</strong> <br/> <select name="select12"> <br/> <option value="January" selected> January</option> <br/> <option value="February"> February</option> <br/> <option value="March"> March</option> <br/> <option value="April"> April</option> <br/> <option value="May"> May</option> <br/> <option value="June"> June</option> <br/> <option value="July"> July</option> <br/> <option value="August"> August</option> <br/> <option value="September"> September</option> <br/> <option value="October"> October</option> <br/> <option value="November"> November</option> <br/> <option value="December"> December</option> <br/> </select> <br/> <select name="select14"> <br/> <option value="01"> 01</option> <br/> <option value="02"> 02</option> <br/> <option value="03"> 03</option> <br/> <option value="04"> 04</option> <br/> <option value="05"> 05</option> <br/> <option value="06"> 06</option> <br/> <option value="07"> 07</option> <br/> <option value="08"> 08</option> <br/> <option value="09"> 09</option> <br/> <option value="10"> 10</option> <br/> <option value="11"> 11</option> <br/> <option value="12"> 12</option> <br/> <option value="13"> 13</option> <br/> <option value="14"> 14</option> <br/> <option value="15"> 15</option> <br/> <option value="16"> 16</option> <br/> <option value="17"> 17</option> <br/> <option value="18"> 18</option> <br/> <option value="19"> 19</option> <br/> <option value="20"> 20</option> <br/> <option value="21"> 21</option> <br/> <option value="22"> 22</option> <br/> <option value="23"> 23</option> <br/> <option value="24"> 24</option> <br/> <option value="25"> 25</option> <br/> <option value="26"> 26</option> <br/> <option value="27"> 27</option> <br/> <option value="28"> 28</option> <br/> <option value="29"> 29</option> <br/> <option value="30"> 30</option> <br/> <option value="31"> 31</option> <br/> </select> <br/> <select name="select5"> <br/> <option value="2007"> 2007</option> <br/> <option value="2008"> 2008</option> <br/> <option value="2009"> 2009</option> <br/> <option value="2010"> 2010</option> <br/> </select> <br/> <select name="select6"> <br/> <option value="Early morning"> Before 7AM</option> <br/> <option value="7:00 AM"> 7:00 AM</option> <br/> <option value="8:00 AM"> 8:00 AM</option> <br/> <option value="9:00 AM" selected> 9:00 AM</option> <br/> <option value="10:00 AM"> 10:00 AM</option> <br/> <option value="11:00 AM"> 11:00 AM</option> <br/> <option value="12:00 PM"> 12:00 PM</option> <br/> <option value="1:00 PM"> 1:00 PM</option> <br/> <option value="2:00 PM"> 2:00 PM</option> <br/> <option value="3:00 PM"> 3:00 PM</option> <br/> <option value="4:00 PM"> 4:00 PM</option> <br/> <option value="5:00 PM"> 5:00 PM</option> <br/> <option value="6:00 PM"> 6:00 PM</option> <br/> <option value="7:00 PM"> 7:00 PM</option> <br/> <option value="Late night"> After 7PM</option> <br/> </select> <br/> </label> <br/> </p> <br/> <p> <br/> <label class="fn"> <strong> Assigned to:</strong> <br/> <input type="text" name="textfield2" /> <br/> </label> <br/> </p> <br/> <p> <br/> <label class="cc"> <strong> Send a copy to:</strong> <br/> <input type="text" name="textfield22" /> <br/> </label> <br/> </p> <br/> <p> <br/> <label class="enclosure"> <strong> Associate a file URI:</strong> <br/> <input type="text" name="textfield222" /> <br/> </label> <br/> <label rel="enclosure"> </label> <br/> </p> <br/> <p> <br/> <label class="summary"> <strong> Summary:</strong> <br/> <textarea name="textarea"> </textarea> <br/> </label> <br/> </p> <br/> <p> <br/> <input type="submit" name="Submit3" value="Save and Close" /> <br/> </p> <br/> <hr /> <br/> <h3> Advanced Options:</h3> <br/> <p> <br/> <label class="status"> <strong> Status:</strong> <br/> <select name="select8"> <br/> <option value="Active" selected="selected"> Active</option> <br/> <option value="Disabled"> Disabled</option> <br/> <option value="Complete"> Complete</option> <br/> </select> <br/> </label> <br/> </p> <br/> <p> <br/> <label class="privacy"> <strong> Privacy:</strong> <br/> <input name="radiobutton" type="radio" value="radiobutton" checked="checked" /> Public</label> <br/> <label class="privacy"> <br/> <input name="radiobutton" type="radio" value="radiobutton" /> Private<br/> </label> <br/> </p> <br/> <p> <br/> <label class="category"> <strong> Category:</strong> <br/> <input type="text" name="textfield3" /> <br/> </label> <br/> </p> <br/> <p> <br/> <label rel="meta"> <strong> Tags:</strong> <br/> <input type="text" name="textfield4" /> <br/> </label> <br/> </p> <br/> <p> <br/> <label rel="org"> <strong> Group / Team :</strong> <br/> <input type="text" name="textfield32" /> <br/> </label> <br/> </p> <br/> <p> <br/> <label rel="par"> <strong> Parent Task URI:</strong> <br/> <input type="text" name="textfield6" /> <br/> </label> <br/> </p> <br/> <p> <br/> <label rel="dep"> <strong> Dependency Task (Critical Path) URI:</strong> <br/> <input type="text" name="textfield7" /> <br/> </label> <br/> </p> <br/> <p> <br/> <input type="submit" name="Submit32" value="Save and Close" /> <br/>  <br/> <br /> <br/> </p> <br/> </form> <br/>

== Possible Next Steps ==

Perhaps with PHP and/or XSLT:

Step 1: Create an output function that takes the form data entered by the user and compiles it into a flat HTML page when the user clicks "submit"

Step 2: Create a translation function that takes the form data and uses XSLT or PHP to restructure the output into Microsoft's Task format. Add the ability to choose an output type as a drop down menu next to the "'submit" button with options for "HTML" or "Outlook Task Format"

Step 3: Create a translation function that takes the form data and uses XSLT or PHP to restructure the output into Apple's Task format. Add the ability to choose an output type as a drop down menu next to the "'submit" button with options for "HTML", "Outlook Task Format", or "Apple Mail Format"

Step 4: Create a Firefox browser plugin for consuming tasks using the HTML microformat--as well as relating them to one another using URIs?

Step 5: Somehow get MS and Apple to adopt the open-source, universal format for tasks... i.e. the microformat (as opposed to their proprietary formats)

== See Also ==
* [[task|Task Effort]]
* [[task-examples|Task Examples]]
* [[task-formats|Task Formats]]
* [[task-faq|Task FAQ]]

h-feed

2021-08-20T05:05:25Z

Dshanske:

{{DISPLAYTITLE:h-feed}}

<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-feed</dfn> is a simple, open format for publishing a stream or feed of [[h-entry]] posts, like complete posts on a home page or archive pages, or summaries or other brief lists of posts. h-feed is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-feed is the [[microformats2]] update to [[hAtom]], and in particular its "hfeed" root class.

;<span id="status">Status</span>
:'''h-feed''' is a microformats.org draft specification.
:h-feed is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-feed up as a classic [[hAtom]] "hfeed".

;<span id="participate">Participate</span>
:[https://github.com/microformats/h-feed/issues Open Issues]
:[[IRC]]
;License
: {{cc0-owfa-license}}
__TOC__

== Properties ==
h-feed properties, inside an element with class '''h-feed'''. All properties are optional.

root class name: h-feed

=== Core Properties ===
The following ''core'' h-feed properties have broad consensus:
* '''<code>p-name</code>''' - name of the feed
* '''<code>p-author</code>''' - author of the feed, optionally embed an [[h-card]] {{main|h-card}}
* '''<code>u-url</code>''' - URL of the feed
* '''<code>u-photo</code>''' - representative photo / icon for the feed

children:
* nested [[h-entry]] objects representing the items of the feed

=== Draft Properties ===
None currently.

=== Proposed Properties ===
The following properties are proposed additions based on various observed examples in the wild, but are awaiting at least one reader / real world consuming code example to become a draft property:
* '''<code>p-summary</code>''' - based on non-trivial actual content usage of "atom:subtitle" on Blogger and WordPress.com featured blogs's Atom feeds.
* '''<code>p-entry</code>''' - to be more consistent with the cascading of p-author or [http://microformats.org/wiki/comment-brainstorming#Proposal p-comment].

== Proposed Additions ==

* Proposal that h-feed not be limited to h-entry, due use cases for feeds of h-cards or h-events https://github.com/microformats/h-feed/issues/3
* Proposal to add implied h-feed in cases where no h-feed is explicitly marked up. https://github.com/microformats/h-feed/issues/1

== Use Cases ==
* Named feeds
** IndieWeb Readers are consuming home page feeds marked up with h-feed and using the name of the h-feed in their user interfce.

* Generate an Atom feed
** This seems like a legacy use-case, not sufficient to actually justify h-feed.

* Feed per channel of content - needs a name
** "I will have a feed per tag (channel) so I want to name them." - Sandeep Shetty in #indiewebcamp
** It appears there is some desire to create separate feeds for an indieweb site for separate subsets of content, and name them <em>explicitly</em> accordingly. This presents a need for a container object for the h-entry elements, where the container itself can have a name. This is a potential interesting use-case for an explicit 'h-feed'.

== Examples in the wild ==
Add any examples in the wild that you find to the top of this list.
* ...
* http://sandeep.io/ uses h-feed with p-name and p-author properties and child h-entry posts. In particular using h-feed on the <html> element allows using p-name on the <title> element and re-using the visible window title of the HTML page as the name of the feed, neatly avoiding a [[DRY]] violation.
* ...

See https://indieweb.org/h-feed#IndieWeb_Examples for many more examples of h-feed in the wild.

== Implementations ==
=== Readers ===
* [https://github.com/kylewm/woodwind Woodwind]
* [https://github.com/barnabywalters/shrewdness Shrewdness]

=== Proxies ===
* Bridgy

=== Converters ===
* '''[http://unmung.com unmung]''' - will transform an RSS or Atom feed into an [[h-feed]] containing h-entries

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[hAtom]] classnames in addition to the more future-proof h-feed properties, for example:

<source lang=html4strict>
<div class="h-feed hfeed">
<h1 class="p-name site-title">The Markup Blog</h1>
<p class="p-summary site-description">Stories of elements of their attributes.</p>

<article class="h-entry hentry">
<a class="u-url" rel="bookmark" href="2020/06/22/balanced-divisive-complementary">
<h2 class="p-name entry-title">A Tale Of Two Tags: Part 2</h2>
</a>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-22T09:45:57-07:00">June 21, 2012</time>
<div class="p-summary entry-summary">
<p>From balanced harmony, to divisive misunderstandings, to complementary roles.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>

<article class="h-entry hentry">
<a class="u-url" rel="bookmark" href="2020/06/20/best-visible-alternative-invisible">
<h2 class="p-name entry-title">A Tale Of Two Tags: Part 1</h2>
</a>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="p-summary entry-summary">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>

</div>
</source>

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

The class '''<code>hfeed</code>''' is a ''backward compatible root class name'' that indicates the presence of an [[hAtom]] feed.

Backward compatibility hAtom property class names and rel values are listed 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-feed" is found, don't look for an "hfeed" on the same element.

Compat root class name: <code id="hfeed">hfeed</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

(this section is a stub and needs review and citations to note what real world examples would each of these backcompat parsing rules actually help parse)

* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the defined way to tag an hfeed. Thus parsers should look for rel=tag hyperlinks inside an hfeed, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.
* <code>site-title</code> - parse as '''<code>p-name</code>''' [WordPress (Core? Typical themes?) has this class name by default, and without it buggy parsers may imply p-name as the whole h-feed ([http://microformats.org/wiki/microformats2-parsing#parsing_for_implied_properties implied properties only apply to actual h-x roots, not backcompat]).]
* <code>site-description</code> - parse as '''<code>p-summary</code>''' [WordPress (Core? Typical themes?) has this class name by default]

If no "h-feed" nor "hfeed" element is found, however multiple top-level [[h-entry]] elements (explicit or backcompat) are found, implementations may use:
* top level [[h-entry]] elements as items in a synthetic h-feed.
* <code><title></code> of the page or the URL of the page as '''<code>p-name</code>'''
* https://indieweb.org/authorship on the page to discover default authorship for any h-entry posts lacking explicit parsed <code>author</code> properties.

== FAQ ==
=== How do I avoid duplicating the page title ===
''I want to use the name (title) of my page as the name of my feed, how do I avoid duplicating the page title somewhere invisibly on the page as the feed name?''

If you want re-use the <title> of your page as the name of your feed, you can do so by putting the h-feed root class name on the <html> element, and the p-name property class name on the <title> element, e.g. here's a snippet showing how those tags would look:
<source lang=html4strict>
<html class="h-feed">
…
<title class="p-name">The Markup Blog</title>
…
</source>

=== What should a subscriber do with a page with multiple feeds ===
''What do I do when a user subscribes to a URL with multiple distinct h-feeds?''

A feed reader should subscribe to the first h-feed it finds at a URL.

Related: http://indiewebcamp.com/reader

== See Also ==
* [[h-entry]]
* [[microformats2]]
* [[hAtom]]

[[Category:Draft Specifications]]

h-feed

2021-08-20T04:59:07Z

Dshanske:

{{DISPLAYTITLE:h-feed}}

<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-feed</dfn> is a simple, open format for publishing a stream or feed of [[h-entry]] posts, like complete posts on a home page or archive pages, or summaries or other brief lists of posts. h-feed is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-feed is the [[microformats2]] update to [[hAtom]], and in particular its "hfeed" root class.

{{cc0-owfa-license}}

== Properties ==
h-feed properties, inside an element with class '''h-feed'''. All properties are optional.

root class name: h-feed

=== Core Properties ===
The following ''core'' h-feed properties have broad consensus:
* '''<code>p-name</code>''' - name of the feed
* '''<code>p-author</code>''' - author of the feed, optionally embed an [[h-card]] {{main|h-card}}
* '''<code>u-url</code>''' - URL of the feed
* '''<code>u-photo</code>''' - representative photo / icon for the feed

children:
* nested [[h-entry]] objects representing the items of the feed

=== Draft Properties ===
None currently.

=== Proposed Properties ===
The following properties are proposed additions based on various observed examples in the wild, but are awaiting at least one reader / real world consuming code example to become a draft property:
* '''<code>p-summary</code>''' - based on non-trivial actual content usage of "atom:subtitle" on Blogger and WordPress.com featured blogs's Atom feeds.
* '''<code>p-entry</code>''' - to be more consistent with the cascading of p-author or [http://microformats.org/wiki/comment-brainstorming#Proposal p-comment].

== Proposed Additions ==

* Proposal that h-feed not be limited to h-entry, due use cases for feeds of h-cards or h-events https://github.com/microformats/h-feed/issues/3
* Proposal to add implied h-feed in cases where no h-feed is explicitly marked up. https://github.com/microformats/h-feed/issues/1

== Status ==
'''h-feed''' is a microformats.org draft specification. Public discussion on h-feed takes place on:
* https://github.com/microformats/h-feed/issues and
* the #microformats [[irc]] channel on irc.freenode.net.

h-feed is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-feed up as a classic [[hAtom]] "hfeed".

== Use Cases ==
* Named feeds
** IndieWeb Readers are consuming home page feeds marked up with h-feed and using the name of the h-feed in their user interfce.

* Generate an Atom feed
** This seems like a legacy use-case, not sufficient to actually justify h-feed.

* Feed per channel of content - needs a name
** "I will have a feed per tag (channel) so I want to name them." - Sandeep Shetty in #indiewebcamp
** It appears there is some desire to create separate feeds for an indieweb site for separate subsets of content, and name them <em>explicitly</em> accordingly. This presents a need for a container object for the h-entry elements, where the container itself can have a name. This is a potential interesting use-case for an explicit 'h-feed'.

== Examples in the wild ==
Add any examples in the wild that you find to the top of this list.
* ...
* http://sandeep.io/ uses h-feed with p-name and p-author properties and child h-entry posts. In particular using h-feed on the <html> element allows using p-name on the <title> element and re-using the visible window title of the HTML page as the name of the feed, neatly avoiding a [[DRY]] violation.
* ...

See https://indieweb.org/h-feed#IndieWeb_Examples for many more examples of h-feed in the wild.

== Implementations ==
=== Readers ===
* [https://github.com/kylewm/woodwind Woodwind]
* [https://github.com/barnabywalters/shrewdness Shrewdness]

=== Proxies ===
* Bridgy

=== Converters ===
* '''[http://unmung.com unmung]''' - will transform an RSS or Atom feed into an [[h-feed]] containing h-entries

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[hAtom]] classnames in addition to the more future-proof h-feed properties, for example:

<source lang=html4strict>
<div class="h-feed hfeed">
<h1 class="p-name site-title">The Markup Blog</h1>
<p class="p-summary site-description">Stories of elements of their attributes.</p>

<article class="h-entry hentry">
<a class="u-url" rel="bookmark" href="2020/06/22/balanced-divisive-complementary">
<h2 class="p-name entry-title">A Tale Of Two Tags: Part 2</h2>
</a>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-22T09:45:57-07:00">June 21, 2012</time>
<div class="p-summary entry-summary">
<p>From balanced harmony, to divisive misunderstandings, to complementary roles.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>

<article class="h-entry hentry">
<a class="u-url" rel="bookmark" href="2020/06/20/best-visible-alternative-invisible">
<h2 class="p-name entry-title">A Tale Of Two Tags: Part 1</h2>
</a>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="p-summary entry-summary">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>

</div>
</source>

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

The class '''<code>hfeed</code>''' is a ''backward compatible root class name'' that indicates the presence of an [[hAtom]] feed.

Backward compatibility hAtom property class names and rel values are listed 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-feed" is found, don't look for an "hfeed" on the same element.

Compat root class name: <code id="hfeed">hfeed</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

(this section is a stub and needs review and citations to note what real world examples would each of these backcompat parsing rules actually help parse)

* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the defined way to tag an hfeed. Thus parsers should look for rel=tag hyperlinks inside an hfeed, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.
* <code>site-title</code> - parse as '''<code>p-name</code>''' [WordPress (Core? Typical themes?) has this class name by default, and without it buggy parsers may imply p-name as the whole h-feed ([http://microformats.org/wiki/microformats2-parsing#parsing_for_implied_properties implied properties only apply to actual h-x roots, not backcompat]).]
* <code>site-description</code> - parse as '''<code>p-summary</code>''' [WordPress (Core? Typical themes?) has this class name by default]

If no "h-feed" nor "hfeed" element is found, however multiple top-level [[h-entry]] elements (explicit or backcompat) are found, implementations may use:
* top level [[h-entry]] elements as items in a synthetic h-feed.
* <code><title></code> of the page or the URL of the page as '''<code>p-name</code>'''
* https://indieweb.org/authorship on the page to discover default authorship for any h-entry posts lacking explicit parsed <code>author</code> properties.

== FAQ ==
=== How do I avoid duplicating the page title ===
''I want to use the name (title) of my page as the name of my feed, how do I avoid duplicating the page title somewhere invisibly on the page as the feed name?''

If you want re-use the <title> of your page as the name of your feed, you can do so by putting the h-feed root class name on the <html> element, and the p-name property class name on the <title> element, e.g. here's a snippet showing how those tags would look:
<source lang=html4strict>
<html class="h-feed">
…
<title class="p-name">The Markup Blog</title>
…
</source>

=== What should a subscriber do with a page with multiple feeds ===
''What do I do when a user subscribes to a URL with multiple distinct h-feeds?''

A feed reader should subscribe to the first h-feed it finds at a URL.

Related: http://indiewebcamp.com/reader

== See Also ==
* [[h-entry]]
* [[microformats2]]
* [[hAtom]]

[[Category:Draft Specifications]]

h-feed

2021-08-20T04:57:40Z

Dshanske:

{{DISPLAYTITLE:h-feed}}

<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-feed</dfn> is a simple, open format for publishing a stream or feed of [[h-entry]] posts, like complete posts on a home page or archive pages, or summaries or other brief lists of posts. h-feed is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-feed is the [[microformats2]] update to [[hAtom]], and in particular its "hfeed" root class.

{{cc0-owfa-license}}

== Properties ==
h-feed properties, inside an element with class '''h-feed'''. All properties are optional.

root class name: h-feed

=== Core Properties ===
The following ''core'' h-feed properties have broad consensus:
* '''<code>p-name</code>''' - name of the feed
* '''<code>p-author</code>''' - author of the feed, optionally embed an [[h-card]] {{main|h-card}}
* '''<code>u-url</code>''' - URL of the feed
* '''<code>u-photo</code>''' - representative photo / icon for the feed

children:
* nested [[h-entry]] objects representing the items of the feed

=== Draft Properties ===
None currently.

=== Proposed Properties ===
The following properties are proposed additions based on various observed examples in the wild, but are awaiting at least one reader / real world consuming code example to become a draft property:
* '''<code>p-summary</code>''' - based on non-trivial actual content usage of "atom:subtitle" on Blogger and WordPress.com featured blogs's Atom feeds.
* '''<code>p-entry</code>''' - to be more consistent with the cascading of p-author or [http://microformats.org/wiki/comment-brainstorming#Proposal p-comment].

== Proposed Additions ===

* Proposal that h-feed not be limited to h-entry, due use cases for feeds of h-cards or h-events https://github.com/microformats/h-feed/issues/3

== Status ==
'''h-feed''' is a microformats.org draft specification. Public discussion on h-feed takes place on:
* https://github.com/microformats/h-feed/issues and
* the #microformats [[irc]] channel on irc.freenode.net.

h-feed is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-feed up as a classic [[hAtom]] "hfeed".

== Use Cases ==
* Named feeds
** IndieWeb Readers are consuming home page feeds marked up with h-feed and using the name of the h-feed in their user interfce.

* Generate an Atom feed
** This seems like a legacy use-case, not sufficient to actually justify h-feed.

* Feed per channel of content - needs a name
** "I will have a feed per tag (channel) so I want to name them." - Sandeep Shetty in #indiewebcamp
** It appears there is some desire to create separate feeds for an indieweb site for separate subsets of content, and name them <em>explicitly</em> accordingly. This presents a need for a container object for the h-entry elements, where the container itself can have a name. This is a potential interesting use-case for an explicit 'h-feed'.

== Examples in the wild ==
Add any examples in the wild that you find to the top of this list.
* ...
* http://sandeep.io/ uses h-feed with p-name and p-author properties and child h-entry posts. In particular using h-feed on the <html> element allows using p-name on the <title> element and re-using the visible window title of the HTML page as the name of the feed, neatly avoiding a [[DRY]] violation.
* ...

See https://indieweb.org/h-feed#IndieWeb_Examples for many more examples of h-feed in the wild.

== Implementations ==
=== Readers ===
* [https://github.com/kylewm/woodwind Woodwind]
* [https://github.com/barnabywalters/shrewdness Shrewdness]

=== Proxies ===
* Bridgy

=== Converters ===
* '''[http://unmung.com unmung]''' - will transform an RSS or Atom feed into an [[h-feed]] containing h-entries

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[hAtom]] classnames in addition to the more future-proof h-feed properties, for example:

<source lang=html4strict>
<div class="h-feed hfeed">
<h1 class="p-name site-title">The Markup Blog</h1>
<p class="p-summary site-description">Stories of elements of their attributes.</p>

<article class="h-entry hentry">
<a class="u-url" rel="bookmark" href="2020/06/22/balanced-divisive-complementary">
<h2 class="p-name entry-title">A Tale Of Two Tags: Part 2</h2>
</a>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-22T09:45:57-07:00">June 21, 2012</time>
<div class="p-summary entry-summary">
<p>From balanced harmony, to divisive misunderstandings, to complementary roles.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>

<article class="h-entry hentry">
<a class="u-url" rel="bookmark" href="2020/06/20/best-visible-alternative-invisible">
<h2 class="p-name entry-title">A Tale Of Two Tags: Part 1</h2>
</a>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="p-summary entry-summary">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>

</div>
</source>

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

The class '''<code>hfeed</code>''' is a ''backward compatible root class name'' that indicates the presence of an [[hAtom]] feed.

Backward compatibility hAtom property class names and rel values are listed 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-feed" is found, don't look for an "hfeed" on the same element.

Compat root class name: <code id="hfeed">hfeed</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

(this section is a stub and needs review and citations to note what real world examples would each of these backcompat parsing rules actually help parse)

* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the defined way to tag an hfeed. Thus parsers should look for rel=tag hyperlinks inside an hfeed, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.
* <code>site-title</code> - parse as '''<code>p-name</code>''' [WordPress (Core? Typical themes?) has this class name by default, and without it buggy parsers may imply p-name as the whole h-feed ([http://microformats.org/wiki/microformats2-parsing#parsing_for_implied_properties implied properties only apply to actual h-x roots, not backcompat]).]
* <code>site-description</code> - parse as '''<code>p-summary</code>''' [WordPress (Core? Typical themes?) has this class name by default]

If no "h-feed" nor "hfeed" element is found, however multiple top-level [[h-entry]] elements (explicit or backcompat) are found, implementations may use:
* top level [[h-entry]] elements as items in a synthetic h-feed.
* <code><title></code> of the page or the URL of the page as '''<code>p-name</code>'''
* https://indieweb.org/authorship on the page to discover default authorship for any h-entry posts lacking explicit parsed <code>author</code> properties.

== FAQ ==
=== How do I avoid duplicating the page title ===
''I want to use the name (title) of my page as the name of my feed, how do I avoid duplicating the page title somewhere invisibly on the page as the feed name?''

If you want re-use the <title> of your page as the name of your feed, you can do so by putting the h-feed root class name on the <html> element, and the p-name property class name on the <title> element, e.g. here's a snippet showing how those tags would look:
<source lang=html4strict>
<html class="h-feed">
…
<title class="p-name">The Markup Blog</title>
…
</source>

=== What should a subscriber do with a page with multiple feeds ===
''What do I do when a user subscribes to a URL with multiple distinct h-feeds?''

A feed reader should subscribe to the first h-feed it finds at a URL.

Related: http://indiewebcamp.com/reader

== See Also ==
* [[h-entry]]
* [[microformats2]]
* [[hAtom]]

[[Category:Draft Specifications]]

h-event

2021-08-20T04:52:35Z

Dshanske: /* Experimental Properties */

{{DISPLAYTITLE:h-event}}
<dfn style="font-style:normal;font-weight:bold">h-event</dfn> is a simple, open format for events on the web. h-event is often used with both event listings and individual event pages. h-event is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-event is the [[microformats2]] update to [[hCalendar]].

;<span id="status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [https://github.com/microformats/h-event/issues feedback].
;<span id="participate">Participate</span>
:[https://github.com/microformats/h-event/issues Open Issues]
:[[IRC]]
:Advance the spec by contributing to a consensus in [https://github.com/microformats/h-event/issues/1 issue: adopt same change control as h-entry]
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__

== Example ==
Here is a simple event example:

<source lang=html4strict>
<div class="h-event">
<h1 class="p-name">Microformats Meetup</h1>
<p>From
<time class="dt-start" datetime="2013-06-30 12:00">30<sup>th</sup> June 2013, 12:00</time>
to <time class="dt-end" datetime="2013-06-30 18:00">18:00</time>
at <span class="p-location">Some bar in SF</span></p>
<p class="p-summary">Get together and discuss all things microformats-related.</p>
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-event"
],
"properties": {
"name": [
"Microformats Meetup"
],
"start": [
"2013-06-30 12:00:00"
],
"end": [
"2013-06-30 18:00:00"
],
"location": [
"Some bar in SF"
],
"summary": [
"Get together and discuss all things microformats-related."
]
}
}
]
}
</source>

=== Get started ===
The class '''<code>h-event</code>''' is a ''root class name'' that indicates the presence of an h-event.

'''p-name''', '''dt-start''', '''dt-end''', '''p-location''', '''p-summary''', and the other h-event property class names listed below define ''properties'' of the h-event.

See [[microformats2-parsing]] to learn more about property class names.

== Properties ==
h-event properties, inside an element with class '''h-event''':
* '''<code>p-name</code>''' - event name (or title)
* '''<code>p-summary</code>''' - short summary of the event
* '''<code>dt-start</code>''' - datetime the event starts
* '''<code>dt-end</code>''' - datetime the event ends
* '''<code>dt-duration</code>''' - duration of the event
* '''<code>p-description</code>''' - more detailed description of the event
** '''WARNING:''' Proposed to be replaced by '''<code>e-content</code>''' (re-used from [[h-entry]])
** See and follow-up: https://github.com/microformats/h-event/issues/3
* '''<code>u-url</code>''' - permalink for the event
* '''<code>p-category</code>''' - event category(ies)/tag(s)
* '''<code>p-location</code>''' - where the event takes place, optionally embedded [[h-card]], [[h-adr]], or [[h-geo]]

All properties are optional.

=== Experimental Properties ===

These properties are currently in use in the wild but not (yet) part of the draft h-event spec:

* '''<code>p-attendee</code>''' - a person attending the event, optionally embed [[h-card]]
<div class="discussion">
* This draft has not been updated in almost 2 years. During this period, <code>h-entry</code> <code>p-rsvp</code> has been standardised, thus making it robust and mature enough for the addition. I guess it's about time to unlabel <code>p-attendee</code> as experimental.
** I've filed https://github.com/microformats/h-event/issues/2 to track advancing this draft as a whole. Let's do that with the existing draft before discussing p-attendee in particular. And rather than guessing, take a look at the vocabulary maturity levels in h-entry and perhaps help evaluate (in another issue) p-attendee according to those criteria. [[User:Tantek|Tantek]] 01:10, 28 February 2017 (UTC)
* I would also suggest to extend expected value to [[h-entry]], so that, while the personal info can be preserved, the attendee can also support p-rsvp property of h-entry.
** I don't understand this. p-attendee is supposed to represent a person, e.g. an [[h-card]]. How would it having that be an [[h-entry]] make sense and work (from a publishing and consuming code perspective)? This proposed extension to p-attendee may be worth its own issue as well. [[User:Tantek|Tantek]] 01:10, 28 February 2017 (UTC)
</div>
* '''<code>p-organizer</code>''' - a person organizing an event, optionally embedded [[h-card]]. Used in Indieweb events, but not consumed. https://github.com/microformats/h-event/issues/10
* '''<code>u-rsvp</code>''' - similar to the proposed u-comment on h-entry, this would be the proposed property to mark up displayed RSVPs on an h-event. https://github.com/microformats/h-event/issues/9

== Status ==
'''h-event''' is a microformats.org draft specification. Public discussion on h-event takes place on the [[irc|#microformats channel on irc.freenode.net]] ([https://chat.indieweb.org/microformats view recent discussions]), and specific issues [https://github.com/microformats/h-event/issues may be filed on GitHub].

h-event is ready to use and implemented in the wild. For backwards compatibility you should also mark up top-level h-events as classic [[hCalendar]] events.

== Property Details ==
(stub, to be expanded)

=== p-location ===
<code>p-location</code> is typically a physical address, optionally marked up with [[h-adr]], for example:

<source lang=html4strict>
<p class="p-location h-adr">
<span class="p-street-address">17 Austerstræti</span>
<span class="p-locality">Reykjavík</span>
<span class="p-country-name">Iceland</span>
</p>
</source>

=== Reserved Properties ===
Reserved properties:
* '''<code>p-organizer</code>''' - a person (co-)organizing the event, optionally embed [[h-card]] {{main|h-card}}
** proposed as way to [https://github.com/snarfed/bridgy/issues/275 implement copying an event organizer to Eventbrite]

== Examples in the wild ==
Real world in the wild examples:

* ... add uses of h-event you see in the wild here.
* [http://www.w3.org/conf/ W3Conf 2013] uses h-event for the main event, and h-card for all the speakers and notable attendees. The h-cards make particularly good use of implied name, url, and photo properties.
* [http://tantek.com/ Tantek Çelik] uses h-event on his home page
* [http://tantek.com/presentations/2012/06/microformats microformats.org at 7 years] presentation with h-event
* [http://tantek.com/presentations/2012/06/pdf2012-indieweb.html Rise of the Indie Web hCards] (from Personal Democracy Forum 2012 #pdf12 #pdf2012) has [[microformats2]] h-event and h-card markup
* WebMaker by Mozilla has h-event and h-card on event search (e.g. [https://webmaker.org/en-US/events/near/?lat=45.5234515&lng=-122.6762071 search near Portland Oregon]) and event pages (e.g. [https://webmaker.org/en-US/events/192f56eb9/ IndieWebCamp 2012]).[https://twitter.com/microformats/status/212207925643587585]
* [http://indiewebcamp.com IndieWebCamp] has [[microformats2]] h-event markup with embedded h-cards for the organizers and the location.
* [https://wiki.mozilla.org/Events Mozilla Events] page has [[microformats2]] h-event markup with attendees marked up with h-card.
* https://gregorlove.com/events has h-event markup, for example: https://gregorlove.com/2017/06/homebrew-website-club/
** has additional property from [[h-entry]]: <code>dt-published</code>
* https://oauth.net/events/ has a list of h-event marked up events relating to OAuth, both future and past
* http://68middle.st/events has events marked up in h-event

See [[microformats2#Examples_in_the_wild|microformats2 examples in the wild]] for more

== Validating ==
{{h-spec-section-validating}}

== Implementations ==
Software implementations that publish or consume h-event, including themes, plugins, or extensions:

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

* [https://github.com/gRegorLove/mf2-to-iCalendar mf2 to iCalendar]: Convert microformats h-event to iCalendar. Example: https://gregorlove.com/calendar/

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[hCalendar]] classnames in addition to the more future-proof h-event properties, for example:

<source lang=html4strict>
<div class="h-event vevent">
<h1 class="p-name summary">Some great event</h1>
</div>
</div>
</source>

=== 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-event" is found, don't look for a "vevent" on the same element.

Compat root class name: <code id="vevent">vevent</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>summary</code> - parse as '''<code>p-name</code>'''
* <code>dtstart</code> - parse as '''<code>dt-start</code>'''
* <code>dtend</code> - parse as '''<code>dt-end</code>'''
* <code>duration</code> - parse as '''<code>dt-duration</code>'''
* <code>description</code>
* <code>url</code> - parse as '''u-'''
* <code>category</code>
* <code>location</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>, and compat root <code>adr</code> in the absence of <code>h-adr</code>
* <code>geo</code> - parse as '''<code>p-location h-geo</code>''' including compat root <code>geo</code>

=== iCalendar Compatibility ===
hCalendar-specific implementations that perform custom display or translation to iCalendar .ics {{should}} prefer <code>p-name</code> over <code>p-summary</code>, and use <code>p-summary</code> value(s) as a fallback if there is no <code>p-name</code>.

== Background ==
This work is based on the existing [[hCalendar]] and [[iCalendar]] specifications.

== Design Principles ==
(stub, expand)

== See Also ==
* [[h-calendar-to-do]]
* [[h-event-brainstorming]]
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-adr]]
* [[h-geo]]
* [[h-card]]
* [[hCalendar]]
* [[h-entry]]s can be RSVPs to events, using the p-rsvp property

[[Category:Draft Specifications]]

h-event

2021-08-20T04:52:13Z

Dshanske: /* Properties */

{{DISPLAYTITLE:h-event}}
<dfn style="font-style:normal;font-weight:bold">h-event</dfn> is a simple, open format for events on the web. h-event is often used with both event listings and individual event pages. h-event is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-event is the [[microformats2]] update to [[hCalendar]].

;<span id="status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [https://github.com/microformats/h-event/issues feedback].
;<span id="participate">Participate</span>
:[https://github.com/microformats/h-event/issues Open Issues]
:[[IRC]]
:Advance the spec by contributing to a consensus in [https://github.com/microformats/h-event/issues/1 issue: adopt same change control as h-entry]
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__

== Example ==
Here is a simple event example:

<source lang=html4strict>
<div class="h-event">
<h1 class="p-name">Microformats Meetup</h1>
<p>From
<time class="dt-start" datetime="2013-06-30 12:00">30<sup>th</sup> June 2013, 12:00</time>
to <time class="dt-end" datetime="2013-06-30 18:00">18:00</time>
at <span class="p-location">Some bar in SF</span></p>
<p class="p-summary">Get together and discuss all things microformats-related.</p>
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-event"
],
"properties": {
"name": [
"Microformats Meetup"
],
"start": [
"2013-06-30 12:00:00"
],
"end": [
"2013-06-30 18:00:00"
],
"location": [
"Some bar in SF"
],
"summary": [
"Get together and discuss all things microformats-related."
]
}
}
]
}
</source>

=== Get started ===
The class '''<code>h-event</code>''' is a ''root class name'' that indicates the presence of an h-event.

'''p-name''', '''dt-start''', '''dt-end''', '''p-location''', '''p-summary''', and the other h-event property class names listed below define ''properties'' of the h-event.

See [[microformats2-parsing]] to learn more about property class names.

== Properties ==
h-event properties, inside an element with class '''h-event''':
* '''<code>p-name</code>''' - event name (or title)
* '''<code>p-summary</code>''' - short summary of the event
* '''<code>dt-start</code>''' - datetime the event starts
* '''<code>dt-end</code>''' - datetime the event ends
* '''<code>dt-duration</code>''' - duration of the event
* '''<code>p-description</code>''' - more detailed description of the event
** '''WARNING:''' Proposed to be replaced by '''<code>e-content</code>''' (re-used from [[h-entry]])
** See and follow-up: https://github.com/microformats/h-event/issues/3
* '''<code>u-url</code>''' - permalink for the event
* '''<code>p-category</code>''' - event category(ies)/tag(s)
* '''<code>p-location</code>''' - where the event takes place, optionally embedded [[h-card]], [[h-adr]], or [[h-geo]]

All properties are optional.

=== Experimental Properties ===

These properties are currently in use in the wild but not (yet) part of the draft h-event spec:

* '''<code>p-attendee</code>''' - a person attending the event, optionally embed [[h-card]]
<div class="discussion">
* This draft has not been updated in almost 2 years. During this period, <code>h-entry</code> <code>p-rsvp</code> has been standardised, thus making it robust and mature enough for the addition. I guess it's about time to unlabel <code>p-attendee</code> as experimental.
** I've filed https://github.com/microformats/h-event/issues/2 to track advancing this draft as a whole. Let's do that with the existing draft before discussing p-attendee in particular. And rather than guessing, take a look at the vocabulary maturity levels in h-entry and perhaps help evaluate (in another issue) p-attendee according to those criteria. [[User:Tantek|Tantek]] 01:10, 28 February 2017 (UTC)
* I would also suggest to extend expected value to [[h-entry]], so that, while the personal info can be preserved, the attendee can also support p-rsvp property of h-entry.
** I don't understand this. p-attendee is supposed to represent a person, e.g. an [[h-card]]. How would it having that be an [[h-entry]] make sense and work (from a publishing and consuming code perspective)? This proposed extension to p-attendee may be worth its own issue as well. [[User:Tantek|Tantek]] 01:10, 28 February 2017 (UTC)
</div>
* '''<code>p-organizer</code>''' - a person organizing an event, optionally embedded [[h-card]]. Used in Indieweb events, but not consumed.
* '''<code>u-rsvp</code>''' - similar to the proposed u-comment on h-entry, this would be the proposed property to mark up displayed RSVPs on an h-event. https://github.com/microformats/h-event/issues/9

== Status ==
'''h-event''' is a microformats.org draft specification. Public discussion on h-event takes place on the [[irc|#microformats channel on irc.freenode.net]] ([https://chat.indieweb.org/microformats view recent discussions]), and specific issues [https://github.com/microformats/h-event/issues may be filed on GitHub].

h-event is ready to use and implemented in the wild. For backwards compatibility you should also mark up top-level h-events as classic [[hCalendar]] events.

== Property Details ==
(stub, to be expanded)

=== p-location ===
<code>p-location</code> is typically a physical address, optionally marked up with [[h-adr]], for example:

<source lang=html4strict>
<p class="p-location h-adr">
<span class="p-street-address">17 Austerstræti</span>
<span class="p-locality">Reykjavík</span>
<span class="p-country-name">Iceland</span>
</p>
</source>

=== Reserved Properties ===
Reserved properties:
* '''<code>p-organizer</code>''' - a person (co-)organizing the event, optionally embed [[h-card]] {{main|h-card}}
** proposed as way to [https://github.com/snarfed/bridgy/issues/275 implement copying an event organizer to Eventbrite]

== Examples in the wild ==
Real world in the wild examples:

* ... add uses of h-event you see in the wild here.
* [http://www.w3.org/conf/ W3Conf 2013] uses h-event for the main event, and h-card for all the speakers and notable attendees. The h-cards make particularly good use of implied name, url, and photo properties.
* [http://tantek.com/ Tantek Çelik] uses h-event on his home page
* [http://tantek.com/presentations/2012/06/microformats microformats.org at 7 years] presentation with h-event
* [http://tantek.com/presentations/2012/06/pdf2012-indieweb.html Rise of the Indie Web hCards] (from Personal Democracy Forum 2012 #pdf12 #pdf2012) has [[microformats2]] h-event and h-card markup
* WebMaker by Mozilla has h-event and h-card on event search (e.g. [https://webmaker.org/en-US/events/near/?lat=45.5234515&lng=-122.6762071 search near Portland Oregon]) and event pages (e.g. [https://webmaker.org/en-US/events/192f56eb9/ IndieWebCamp 2012]).[https://twitter.com/microformats/status/212207925643587585]
* [http://indiewebcamp.com IndieWebCamp] has [[microformats2]] h-event markup with embedded h-cards for the organizers and the location.
* [https://wiki.mozilla.org/Events Mozilla Events] page has [[microformats2]] h-event markup with attendees marked up with h-card.
* https://gregorlove.com/events has h-event markup, for example: https://gregorlove.com/2017/06/homebrew-website-club/
** has additional property from [[h-entry]]: <code>dt-published</code>
* https://oauth.net/events/ has a list of h-event marked up events relating to OAuth, both future and past
* http://68middle.st/events has events marked up in h-event

See [[microformats2#Examples_in_the_wild|microformats2 examples in the wild]] for more

== Validating ==
{{h-spec-section-validating}}

== Implementations ==
Software implementations that publish or consume h-event, including themes, plugins, or extensions:

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

* [https://github.com/gRegorLove/mf2-to-iCalendar mf2 to iCalendar]: Convert microformats h-event to iCalendar. Example: https://gregorlove.com/calendar/

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[hCalendar]] classnames in addition to the more future-proof h-event properties, for example:

<source lang=html4strict>
<div class="h-event vevent">
<h1 class="p-name summary">Some great event</h1>
</div>
</div>
</source>

=== 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-event" is found, don't look for a "vevent" on the same element.

Compat root class name: <code id="vevent">vevent</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>summary</code> - parse as '''<code>p-name</code>'''
* <code>dtstart</code> - parse as '''<code>dt-start</code>'''
* <code>dtend</code> - parse as '''<code>dt-end</code>'''
* <code>duration</code> - parse as '''<code>dt-duration</code>'''
* <code>description</code>
* <code>url</code> - parse as '''u-'''
* <code>category</code>
* <code>location</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>, and compat root <code>adr</code> in the absence of <code>h-adr</code>
* <code>geo</code> - parse as '''<code>p-location h-geo</code>''' including compat root <code>geo</code>

=== iCalendar Compatibility ===
hCalendar-specific implementations that perform custom display or translation to iCalendar .ics {{should}} prefer <code>p-name</code> over <code>p-summary</code>, and use <code>p-summary</code> value(s) as a fallback if there is no <code>p-name</code>.

== Background ==
This work is based on the existing [[hCalendar]] and [[iCalendar]] specifications.

== Design Principles ==
(stub, expand)

== See Also ==
* [[h-calendar-to-do]]
* [[h-event-brainstorming]]
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-adr]]
* [[h-geo]]
* [[h-card]]
* [[hCalendar]]
* [[h-entry]]s can be RSVPs to events, using the p-rsvp property

[[Category:Draft Specifications]]

h-entry

2021-08-20T04:44:32Z

Dshanske: /* Proposed Additions */

{{DISPLAYTITLE:h-entry}}
<dfn style="font-style:normal;font-weight:bold">h-entry</dfn> 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 [[microformats|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]].

;<span id="status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [[h-entry-issues|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|change control]] process.
;<span id="participate">Participate</span>
:[https://github.com/microformats/h-entry/issues Open Issues]
:[[h-entry-issues|Resolved issues before 2012-246]]
:[[IRC]]
:Advance the spec by following explicit [[#change_control|change control]] process
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__

== Example ==
Here is a simple blog post example:

<source lang=html4strict>
<article class="h-entry">
<h1 class="p-name">Microformats are amazing</h1>
<p>Published by <a class="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></p>

<p class="p-summary">In which I extoll the virtues of using microformats.</p>

<div class="e-content">
<p>Blah blah blah</p>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"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>"
}
]
}
}
]
}
</source>

== Get started ==
The class '''<code>h-entry</code>''' 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 optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

=== Core Properties ===
The following ''core'' h-entry properties have broad consensus and are broadly interoperably published and consumed:
* '''<code>p-name</code>''' - entry name/title
* '''<code>p-summary</code>''' - short entry summary
* '''<code>e-content</code>''' - full content of the entry
* '''<code>dt-published</code>''' - when the entry was published
* '''<code>dt-updated</code>''' - when the entry was updated
* '''<code>p-author</code>''' - who wrote the entry, optionally embedded [[h-card]](s)
* '''<code>p-category</code>''' - entry categories/tags
* '''<code>u-url</code>''' - entry permalink URL
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical entry URL
* '''<code>p-location</code>''' - location the entry was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code id="u-syndication">u-syndication</code>''' - URL(s) of syndicated copies of this post. The property equivalent of [[rel-syndication]] ([http://erinjo.is/2014/checked-into-rockit-colabs-23 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]) ([https://kartikprabhu.com/notes/re-citizen-of-indieweb example])
* '''<code id="p-rsvp">p-rsvp</code>''' (enum, use <data> element or [[value-class-pattern]])
** "yes", "no", "maybe", "interested". Case-insensitive values, normalized to lowercase. Examples:
** <code><nowiki>... <data class="p-rsvp" value="YES">is going</data> to ...</nowiki></code>, or
** <code><nowiki>... <data class="p-rsvp" value="Maybe">might go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="no">unable to go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="iNtEreSTed">am interested/tracking/watching</data> ...</nowiki></code>
* '''<code id="u-like-of">u-like-of</code>''' - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded [[h-cite]]
* '''<code id="u-repost-of">u-repost-of</code>''' - the URL which the h-entry is considered a “repost” of. Optionally an embedded [[h-cite]].

=== 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 id="p-comment">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])
** [https://github.com/microformats/h-entry/issues/20 Issue 20]
* '''<code id="u-photo">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.
** [https://github.com/microformats/h-entry/issues/4 Issue 4: u-photo draft->core bc way more than 3+ pub and consuming impls/sites]
* '''<code id="u-video">u-video</code>''' - special u- parsing rules for <code><video src> & <source src></code>
** [https://github.com/microformats/h-entry/issues/5 Issue 5]

=== 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 awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:
* '''<code>u-audio</code>''' - special u- parsing rules for <code><audio src> & <source src></code>. Examples: [http://transportini.com/ Transportini],[https://indieweb.org/podcast#How_to_podcast_with_h-feed possibly more]
** [https://github.com/microformats/h-entry/issues/6 Issue 6]
* '''<code>u-like</code>''' - similar to p-comment, URL to a like post of the current post, e.g. in a responses list or facepile.
* '''<code>u-repost</code>''' - similar to u-like, URL to a repost of the current post, e.g. in a responses list or facepile.
* '''<code>u-bookmark-of</code>''' - indicates this h-entry is a bookmark of another URL. Optionally an [[h-cite]]. See [https://indieweb.org/bookmark indieweb.org/bookmark] for examples in the wild.
** [https://github.com/microformats/h-entry/issues/12 Issue 12]
* '''<code>u-featured</code>''' - 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]].
** +1 sknebel: https://github.com/microformats/h-entry/issues/14
* '''<code>p-latitude</code>''' - latitude of the location of the entry
* '''<code>p-longitude</code>''' - longitude of the location of the entry
* '''<code>p-duration</code>''' - duration of an audio or video file in the entry. https://indieweb.org/duration Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
** [https://github.com/microformats/h-entry/issues/21 Issue 21]
* '''<code>p-size</code>''' - size in bytes of an audio or video file in the entry. https://indieweb.org/size Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>u-listen-of</code>''' - also known as a 'scrobble', indicates this h-entry is a listen of another URL. Optionally an h-cite. https://github.com/microformats/h-entry/issues/11
* '''<code>u-watch-of</code>''' - indicates this h-entry is a watch of another URL, a visual version of the scrobble. Optionally an h-cite. https://github.com/microformats/h-entry/issues/17
* '''<code>p-read-of</code>''' - indicates this h-entry is a read post of some written work (book or other document). The value can be the title of the work or an h-cite. Proposal also mentions <code>u-read-of</code>, where the value would be a URL to the written work or a representative citation page. https://github.com/microformats/h-entry/issues/10
* '''<code>u-translation-of</code>''' - indicates this h-entry is a translation of the linked URL into another language. Can be used in the same way as the existing <code>u-like-of</code> and <code>u-repost-of</code> properties, with just the URL to the original h-entry, or (optionally) contain an embedded <code>h-cite</code>. https://github.com/microformats/h-entry/issues/26
* '''<code>u-checkin</code>''' - the URL of the venue/location h-card which the h-entry is considered a “checkin” of. Optionally an embedded h-card. https://github.com/microformats/h-entry/issues/15

The following interpretation is also proposed addition:
* if the <code>p-location</code> is also an embedded [[h-card]], the entry is treated as a "checkin".
** -1 [[User:Aaronpk|Aaronpk]] 14:22, 19 January 2017 (UTC) [https://aaronparecki.com/2017/01/13/21/ this post] is not a checkin, but has an h-card as the p-location property.

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: [[h-entry#change_control|change control]]

== Property Details ==
This section is a stub.
=== p-location ===
'''<code>p-location</code>''' has been re-used from [[h-event]].

== FAQ ==
=== p-name of a note ===
<div class="discussion">
* '''What is the <code>p-name</code> of a [https://indieweb.org/note note]?'''
** You probably should avoid adding <code>p-name</code> to notes. See https://indieweb.org/note for more discussion of the topic.
</div>

=== venue an entry was posted from ===
<div class="discussion">
* '''How do you indicate a named venue where an entry was posted from? Like a restaurant or park.'''
** Use an embedded [[h-card]] microformat on a <code>p-location</code> property value.
</div>

=== address an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== lat long an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== dt-published property and HTML5 time element ===
<div class="discussion">
* '''Does the dt-published property need to be a time element?'''
** The <code>dt-published</code> property should be a <code><time></code> 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.
</div>

=== what is the bare minimum list of required properties on an h-entry ===
<div class="discussion">
* 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:
</div>
* <code>url</code>
* <code>published</code> — if there is no "published" date for the "entry", then reconsider whether it is correct (or worth) marking it up as an entry.
<div class="discussion">
* 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:
</div>
* <code>content</code> (or <code>summary</code> at least) - especially for structured content. For a plain text note, the content/summary (whichever is used) should be the same as the <code>name</code>, otherwise it will be implied from the text content of the root element.
* <code>name</code> - for explicitly named/titled entries like blog posts and articles. Otherwise the entry is assumed to be a "title-less" [https://indieweb.org/note note] (like a tweet).
* <code>author</code> - including a nested <code>[[h-card]]</code> with author details like name, photo, url.

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

* ... add uses of h-entry you see in the wild here.
* ind.ie mark up their [https://ind.ie/blog blog] listing and [https://ind.ie/blog/autumn-events-2014/ permalink] pages with h-entry
* David John Mead marks up his profile, blog posts and comments with h-card, h-entry and h-cite on [http://davidjohnmead.com davidjohnmead.com]
* [[User:Brian|Brian Suda]] marks up his blog posts up with h-entry and h-card on [http://optional.is/required/ optional.is]
* Ashton McAllen marks up his blog posts, reposts, comments and likes with h-entry, h-card and h-cite on [http://acegiak.net/ acegiak.net]
* Emma Kuo marks up her blog posts and notes with h-entry and h-card on [http://notenoughneon.com/ notenoughneon.com]
* Scott Jenson marks up his blog posts with h-entry and h-card on [http://jenson.org/ jenson.org]
* Emily McAllen marks up her blog posts with h-entry and h-card on [http://blackwoolholiday.com/ blackwoolholiday.com]
* Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on [https://snarfed.org/ snarfed.org]
* Barry Frost marks up his notes with h-entry, h-card and h-cite on [http://barryfrost.com/ barryfrost.com]
* Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on [http://caseorganic.com/ caseorganic.com]
* Johannes Ernst marks up his blog posts with h-entry on [http://upon2020.com/blog/ upon2020.com]
* Michiel de Jong marks up his profile and notes with h-entry and h-card on [https://michielbdejong.com/ michielbdejong.com]
* Mike Taylor marks up his profile and blog posts with h-card and h-entry on [https://bear.im/bearlog/ bear.im]
* Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on [http://erinjo.is/ erinjo.is]
* Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on [https://jeena.net/ jeena.net]
* Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on [http://andysylvester.com/2014/03/01/howto-setting-up-the-selfoss-feed-reader-with-microformats-support/ andysylvester.com] (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --[[User:Barnabywalters|bw]] 14:44, 13 March 2014 (UTC))
* Chloe Weil marks up her blog posts with h-entry on [http://chloeweil.com/blog chloeweil.com]
* Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on [http://christopheducamp.com/ christopheducamp.com]
* Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on [http://glennjones.net/ glennjones.net]
* Marcus Povey marks up his blog posts and profile with h-entry and h-card on [http://www.marcus-povey.co.uk/ marcus-povey.co.uk]
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* Kyle Mahan marks up his profile and notes with h-card and h-entry on [http://kylewm.com/ kylewm.com]
* Okinawan-lyrics marks up his posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* App.net marks up profile pages and permalink pages with h-entry as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* The Twitter archive browser UI uses h-entry and h-card internally, unfortunately it’s not exposed as HTML in static files anywhere
* Brett Comnes marks up his posts with h-entry and h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like ([http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his posts up with h-card and h-entry, as well as draft u-in-reply-to and experimental u-like properties ([http://sandeep.io/101 example])
* Laurent Eschenauer marks up his posts with h-entry ([http://eschnou.com/entry/first-autonomous-flight-of-my-nodecopter-62-24992.html example])
* Tom Morris marks up his posts using h-entry ([http://tommorris.org/posts/8417 example])
* Numerous newer W3C specs, e.g.
** [http://www.w3.org/TR/2013/CR-css3-values-20130404/ CSS Values and Units Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/CR-css3-conditional-20130404/ CSS Conditional Rules Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/WD-css3-page-20130314/ CSS Paged Media Module Level 3 - 2013-03-14]
** [http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/ CSS Counter Styles Level 3 - 2013-02-21]
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry.
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Aaron Parecki uses h-entry to mark up notes, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-entry on his home page, as well as h-entry on all post permalinks, e.g. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], with [[rel-prev]]/[[rel-next]] (if applicable) to indicate prev/next posts
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-entry on all notes and articles, as well as nested within notes as reply contexts [http://waterpigs.co.uk/notes/1468/ example] and comments [http://waterpigs.co.uk/notes/1482/ example].

=== offline ===
* spreadly marks up share permalink pages with h-entry, as well as minimal h-cards and experimental p-like properties

== Validating ==
* '''[http://indiewebify.me/validate-h-entry/ indiewebify.me h-entry validator]''' parses [[h-entry]] markup, finds common errors and makes suggestions for things to add, with code samples
* '''[http://shrewdness.waterpigs.co.uk/test/ Shrewdness h-entry/h-feed validator]''' shows how shrewdness interprets+displays h-entries, with original source and interim formats, works for single h-entries and feed pages

{{h-spec-section-validating}}

== 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 [https://indieweb.org/ 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.
* [https://gnu.io/social/ GNUsocial] [https://git.gnu.io/gnu/gnu-social/ source code]
* [https://hubzilla.org/hubzilla/ Hubzilla] [https://github.org/redmatrix/hubzilla source code]
* [http://friendica.com/ Friendica] [https://github.org/friendica/friendica source code]
* [http://github.com/dissolve/inkblot InkBlot]
* ...

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

<source lang=html4strict>
<article class="h-entry hentry">
<h1 class="p-name entry-title">A Tale Of Two Tags</h1>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="e-content entry-content">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
<p>The a tag is perhaps the best of HTML, yet its corresponding invisible link tag has uses too.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>
</source>

{{note|Note: you may use any valid HTML5 elements. The <code>article h1 address time</code> elements are used in the example as semantically richer suggestions, however in general <code>div span</code> work fine too. The <code>time</code> element is special though in that its <code>datetime</code> 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: <code id="hentry">hentry</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

* <code>entry-title</code> - parse as '''<code>p-name</code>'''
* <code>entry-summary</code> - parse as '''<code>p-summary</code>'''
* <code>entry-content</code> - parse as '''<code>e-content</code>'''
* <code>published</code> - parse as '''dt-'''
* <code>updated</code> - parse as '''dt-'''
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>category</code>
* <code>rel=bookmark</code> - parse as '''<code>u-url</code>'''. While not a class name nor typical microformats property, rel=bookmark was the only way to indicate an hentry permalink. Thus parsers should look for rel=bookmark hyperlinks inside an hentry, and take their "href" value as a value for a '''<code>u-url</code>''' property, including handling any relative URL resolution.
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hentry. Thus parsers should look for rel=tag hyperlinks inside an hentry, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

Proposed: ([https://github.com/microformats/h-entry/issues/7 follow-up in issue #7])
* <code>time.entry-date[datetime]</code> - in the absence of <code>published</code>, parse as '''<code>dt-published</code>'''. parse for the first <code><time></code> element with class name of <code>entry-date</code> and non-empty <code>datetime</code> attribute inside an hentry, if there is no <code>published</code> property, use that time element's <code>datetime</code> attribute value for the <code>dt-published</code> property. Evidence: default WordPress themes 2011-2014([https://wp-themes.com/twentyeleven/][https://wp-themes.com/twentytwelve/][https://wp-themes.com/twentythirteen/][https://wp-themes.com/twentyfourteen/]).
* <code>rel=author</code> - in the absence of <code>author</code>, parse as '''<code>u-author</code>'''. While not a class name nor typical microformats property, rel=author was commonly used to link to an author's URL. Thus parsers should look for rel=author hyperlinks inside an hentry (or even on the same page, preceding the hentry), use the absolute version of it as a value for the '''<code>u-author</code>''' property if there is no "author" property. (citations to "hentry" examples in the wild that <em>depend</em> on rel=author needed to accepted this proposal. Note: default WordPress themes twentyeleven, twentytwelve, twentythirteen, twentyfourteen all use rel=author but only inside class="author vcard", and thus rel=author can be ignored since authorship is already picked up by existing <code>author</code> backcompat parsing.)

=== 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|rel=bookmark]]?''

A: tl;dr: use <code>class="u-url u-uid"</code> instead of <code>rel=bookmark</code> 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.

<nowiki>*</nowiki> even though rel=bookmark in particular is article-element / sectioning scoped in HTML5[http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-bookmark], 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 <code>entry-*</code> 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#Could_hAtom_instead_use_title_content_and_summary|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: [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-128 2012-08-30 IRC conversation].

== Related Work ==
Work that re-uses or builds upon h-entry:
* [https://mailpile.pagekite.me:8080/p/Open_Message_Format Mailpile Open Message Format] is using h-entry with structured properties, e.g. p-author h-card.

== Background ==
This work is based on the existing [[hAtom]] microformat, and extensive selfdogfooding in the [http://indiewebcamp.com 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 [[h-entry-issues|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|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|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_Additions|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|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|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 ==
* [[h-feed]]
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-geo]]
* [[hCard]]

[[Category:Specifications]]

h-entry

2021-08-20T04:40:41Z

Dshanske: /* Proposed Additions */

{{DISPLAYTITLE:h-entry}}
<dfn style="font-style:normal;font-weight:bold">h-entry</dfn> 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 [[microformats|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]].

;<span id="status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [[h-entry-issues|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|change control]] process.
;<span id="participate">Participate</span>
:[https://github.com/microformats/h-entry/issues Open Issues]
:[[h-entry-issues|Resolved issues before 2012-246]]
:[[IRC]]
:Advance the spec by following explicit [[#change_control|change control]] process
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__

== Example ==
Here is a simple blog post example:

<source lang=html4strict>
<article class="h-entry">
<h1 class="p-name">Microformats are amazing</h1>
<p>Published by <a class="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></p>

<p class="p-summary">In which I extoll the virtues of using microformats.</p>

<div class="e-content">
<p>Blah blah blah</p>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"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>"
}
]
}
}
]
}
</source>

== Get started ==
The class '''<code>h-entry</code>''' 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 optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

=== Core Properties ===
The following ''core'' h-entry properties have broad consensus and are broadly interoperably published and consumed:
* '''<code>p-name</code>''' - entry name/title
* '''<code>p-summary</code>''' - short entry summary
* '''<code>e-content</code>''' - full content of the entry
* '''<code>dt-published</code>''' - when the entry was published
* '''<code>dt-updated</code>''' - when the entry was updated
* '''<code>p-author</code>''' - who wrote the entry, optionally embedded [[h-card]](s)
* '''<code>p-category</code>''' - entry categories/tags
* '''<code>u-url</code>''' - entry permalink URL
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical entry URL
* '''<code>p-location</code>''' - location the entry was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code id="u-syndication">u-syndication</code>''' - URL(s) of syndicated copies of this post. The property equivalent of [[rel-syndication]] ([http://erinjo.is/2014/checked-into-rockit-colabs-23 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]) ([https://kartikprabhu.com/notes/re-citizen-of-indieweb example])
* '''<code id="p-rsvp">p-rsvp</code>''' (enum, use <data> element or [[value-class-pattern]])
** "yes", "no", "maybe", "interested". Case-insensitive values, normalized to lowercase. Examples:
** <code><nowiki>... <data class="p-rsvp" value="YES">is going</data> to ...</nowiki></code>, or
** <code><nowiki>... <data class="p-rsvp" value="Maybe">might go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="no">unable to go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="iNtEreSTed">am interested/tracking/watching</data> ...</nowiki></code>
* '''<code id="u-like-of">u-like-of</code>''' - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded [[h-cite]]
* '''<code id="u-repost-of">u-repost-of</code>''' - the URL which the h-entry is considered a “repost” of. Optionally an embedded [[h-cite]].

=== 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 id="p-comment">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])
** [https://github.com/microformats/h-entry/issues/20 Issue 20]
* '''<code id="u-photo">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.
** [https://github.com/microformats/h-entry/issues/4 Issue 4: u-photo draft->core bc way more than 3+ pub and consuming impls/sites]
* '''<code id="u-video">u-video</code>''' - special u- parsing rules for <code><video src> & <source src></code>
** [https://github.com/microformats/h-entry/issues/5 Issue 5]

=== 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 awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:
* '''<code>u-audio</code>''' - special u- parsing rules for <code><audio src> & <source src></code>. Examples: [http://transportini.com/ Transportini],[https://indieweb.org/podcast#How_to_podcast_with_h-feed possibly more]
** [https://github.com/microformats/h-entry/issues/6 Issue 6]
* '''<code>u-like</code>''' - similar to p-comment, URL to a like post of the current post, e.g. in a responses list or facepile.
* '''<code>u-repost</code>''' - similar to u-like, URL to a repost of the current post, e.g. in a responses list or facepile.
* '''<code>u-bookmark-of</code>''' - indicates this h-entry is a bookmark of another URL. Optionally an [[h-cite]]. See [https://indieweb.org/bookmark indieweb.org/bookmark] for examples in the wild.
** [https://github.com/microformats/h-entry/issues/12 Issue 12]
* '''<code>u-featured</code>''' - 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]].
** +1 sknebel: https://github.com/microformats/h-entry/issues/14
* '''<code>p-latitude</code>''' - latitude of the location of the entry
* '''<code>p-longitude</code>''' - longitude of the location of the entry
* '''<code>p-duration</code>''' - duration of an audio or video file in the entry. https://indieweb.org/duration Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
** [https://github.com/microformats/h-entry/issues/21 Issue 21]
* '''<code>p-size</code>''' - size in bytes of an audio or video file in the entry. https://indieweb.org/size Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>u-listen-of</code>''' - also known as a 'scrobble', indicates this h-entry is a listen of another URL. Optionally an h-cite. https://github.com/microformats/h-entry/issues/11
* '''<code>u-watch-of</code>''' - indicates this h-entry is a watch of another URL, a visual version of the scrobble. Optionally an h-cite. https://github.com/microformats/h-entry/issues/17
* '''<code>p-read-of</code>''' - indicates this h-entry is a read post of some written work (book or other document). The value can be the title of the work or an h-cite. Proposal also mentions <code>u-read-of</code>, where the value would be a URL to the written work or a representative citation page. https://github.com/microformats/h-entry/issues/10
* '''<code>u-translation-of</code>''' - indicates this h-entry is a translation of the linked URL into another language. Can be used in the same way as the existing <code>u-like-of</code> and <code>u-repost-of</code> properties, with just the URL to the original h-entry, or (optionally) contain an embedded <code>h-cite</code>. https://github.com/microformats/h-entry/issues/26

The following interpretation is also proposed addition:
* if the <code>p-location</code> is also an embedded [[h-card]], the entry is treated as a "checkin".
** -1 [[User:Aaronpk|Aaronpk]] 14:22, 19 January 2017 (UTC) [https://aaronparecki.com/2017/01/13/21/ this post] is not a checkin, but has an h-card as the p-location property.

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: [[h-entry#change_control|change control]]

== Property Details ==
This section is a stub.
=== p-location ===
'''<code>p-location</code>''' has been re-used from [[h-event]].

== FAQ ==
=== p-name of a note ===
<div class="discussion">
* '''What is the <code>p-name</code> of a [https://indieweb.org/note note]?'''
** You probably should avoid adding <code>p-name</code> to notes. See https://indieweb.org/note for more discussion of the topic.
</div>

=== venue an entry was posted from ===
<div class="discussion">
* '''How do you indicate a named venue where an entry was posted from? Like a restaurant or park.'''
** Use an embedded [[h-card]] microformat on a <code>p-location</code> property value.
</div>

=== address an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== lat long an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== dt-published property and HTML5 time element ===
<div class="discussion">
* '''Does the dt-published property need to be a time element?'''
** The <code>dt-published</code> property should be a <code><time></code> 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.
</div>

=== what is the bare minimum list of required properties on an h-entry ===
<div class="discussion">
* 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:
</div>
* <code>url</code>
* <code>published</code> — if there is no "published" date for the "entry", then reconsider whether it is correct (or worth) marking it up as an entry.
<div class="discussion">
* 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:
</div>
* <code>content</code> (or <code>summary</code> at least) - especially for structured content. For a plain text note, the content/summary (whichever is used) should be the same as the <code>name</code>, otherwise it will be implied from the text content of the root element.
* <code>name</code> - for explicitly named/titled entries like blog posts and articles. Otherwise the entry is assumed to be a "title-less" [https://indieweb.org/note note] (like a tweet).
* <code>author</code> - including a nested <code>[[h-card]]</code> with author details like name, photo, url.

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

* ... add uses of h-entry you see in the wild here.
* ind.ie mark up their [https://ind.ie/blog blog] listing and [https://ind.ie/blog/autumn-events-2014/ permalink] pages with h-entry
* David John Mead marks up his profile, blog posts and comments with h-card, h-entry and h-cite on [http://davidjohnmead.com davidjohnmead.com]
* [[User:Brian|Brian Suda]] marks up his blog posts up with h-entry and h-card on [http://optional.is/required/ optional.is]
* Ashton McAllen marks up his blog posts, reposts, comments and likes with h-entry, h-card and h-cite on [http://acegiak.net/ acegiak.net]
* Emma Kuo marks up her blog posts and notes with h-entry and h-card on [http://notenoughneon.com/ notenoughneon.com]
* Scott Jenson marks up his blog posts with h-entry and h-card on [http://jenson.org/ jenson.org]
* Emily McAllen marks up her blog posts with h-entry and h-card on [http://blackwoolholiday.com/ blackwoolholiday.com]
* Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on [https://snarfed.org/ snarfed.org]
* Barry Frost marks up his notes with h-entry, h-card and h-cite on [http://barryfrost.com/ barryfrost.com]
* Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on [http://caseorganic.com/ caseorganic.com]
* Johannes Ernst marks up his blog posts with h-entry on [http://upon2020.com/blog/ upon2020.com]
* Michiel de Jong marks up his profile and notes with h-entry and h-card on [https://michielbdejong.com/ michielbdejong.com]
* Mike Taylor marks up his profile and blog posts with h-card and h-entry on [https://bear.im/bearlog/ bear.im]
* Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on [http://erinjo.is/ erinjo.is]
* Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on [https://jeena.net/ jeena.net]
* Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on [http://andysylvester.com/2014/03/01/howto-setting-up-the-selfoss-feed-reader-with-microformats-support/ andysylvester.com] (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --[[User:Barnabywalters|bw]] 14:44, 13 March 2014 (UTC))
* Chloe Weil marks up her blog posts with h-entry on [http://chloeweil.com/blog chloeweil.com]
* Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on [http://christopheducamp.com/ christopheducamp.com]
* Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on [http://glennjones.net/ glennjones.net]
* Marcus Povey marks up his blog posts and profile with h-entry and h-card on [http://www.marcus-povey.co.uk/ marcus-povey.co.uk]
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* Kyle Mahan marks up his profile and notes with h-card and h-entry on [http://kylewm.com/ kylewm.com]
* Okinawan-lyrics marks up his posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* App.net marks up profile pages and permalink pages with h-entry as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* The Twitter archive browser UI uses h-entry and h-card internally, unfortunately it’s not exposed as HTML in static files anywhere
* Brett Comnes marks up his posts with h-entry and h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like ([http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his posts up with h-card and h-entry, as well as draft u-in-reply-to and experimental u-like properties ([http://sandeep.io/101 example])
* Laurent Eschenauer marks up his posts with h-entry ([http://eschnou.com/entry/first-autonomous-flight-of-my-nodecopter-62-24992.html example])
* Tom Morris marks up his posts using h-entry ([http://tommorris.org/posts/8417 example])
* Numerous newer W3C specs, e.g.
** [http://www.w3.org/TR/2013/CR-css3-values-20130404/ CSS Values and Units Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/CR-css3-conditional-20130404/ CSS Conditional Rules Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/WD-css3-page-20130314/ CSS Paged Media Module Level 3 - 2013-03-14]
** [http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/ CSS Counter Styles Level 3 - 2013-02-21]
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry.
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Aaron Parecki uses h-entry to mark up notes, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-entry on his home page, as well as h-entry on all post permalinks, e.g. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], with [[rel-prev]]/[[rel-next]] (if applicable) to indicate prev/next posts
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-entry on all notes and articles, as well as nested within notes as reply contexts [http://waterpigs.co.uk/notes/1468/ example] and comments [http://waterpigs.co.uk/notes/1482/ example].

=== offline ===
* spreadly marks up share permalink pages with h-entry, as well as minimal h-cards and experimental p-like properties

== Validating ==
* '''[http://indiewebify.me/validate-h-entry/ indiewebify.me h-entry validator]''' parses [[h-entry]] markup, finds common errors and makes suggestions for things to add, with code samples
* '''[http://shrewdness.waterpigs.co.uk/test/ Shrewdness h-entry/h-feed validator]''' shows how shrewdness interprets+displays h-entries, with original source and interim formats, works for single h-entries and feed pages

{{h-spec-section-validating}}

== 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 [https://indieweb.org/ 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.
* [https://gnu.io/social/ GNUsocial] [https://git.gnu.io/gnu/gnu-social/ source code]
* [https://hubzilla.org/hubzilla/ Hubzilla] [https://github.org/redmatrix/hubzilla source code]
* [http://friendica.com/ Friendica] [https://github.org/friendica/friendica source code]
* [http://github.com/dissolve/inkblot InkBlot]
* ...

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

<source lang=html4strict>
<article class="h-entry hentry">
<h1 class="p-name entry-title">A Tale Of Two Tags</h1>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="e-content entry-content">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
<p>The a tag is perhaps the best of HTML, yet its corresponding invisible link tag has uses too.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>
</source>

{{note|Note: you may use any valid HTML5 elements. The <code>article h1 address time</code> elements are used in the example as semantically richer suggestions, however in general <code>div span</code> work fine too. The <code>time</code> element is special though in that its <code>datetime</code> 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: <code id="hentry">hentry</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

* <code>entry-title</code> - parse as '''<code>p-name</code>'''
* <code>entry-summary</code> - parse as '''<code>p-summary</code>'''
* <code>entry-content</code> - parse as '''<code>e-content</code>'''
* <code>published</code> - parse as '''dt-'''
* <code>updated</code> - parse as '''dt-'''
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>category</code>
* <code>rel=bookmark</code> - parse as '''<code>u-url</code>'''. While not a class name nor typical microformats property, rel=bookmark was the only way to indicate an hentry permalink. Thus parsers should look for rel=bookmark hyperlinks inside an hentry, and take their "href" value as a value for a '''<code>u-url</code>''' property, including handling any relative URL resolution.
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hentry. Thus parsers should look for rel=tag hyperlinks inside an hentry, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

Proposed: ([https://github.com/microformats/h-entry/issues/7 follow-up in issue #7])
* <code>time.entry-date[datetime]</code> - in the absence of <code>published</code>, parse as '''<code>dt-published</code>'''. parse for the first <code><time></code> element with class name of <code>entry-date</code> and non-empty <code>datetime</code> attribute inside an hentry, if there is no <code>published</code> property, use that time element's <code>datetime</code> attribute value for the <code>dt-published</code> property. Evidence: default WordPress themes 2011-2014([https://wp-themes.com/twentyeleven/][https://wp-themes.com/twentytwelve/][https://wp-themes.com/twentythirteen/][https://wp-themes.com/twentyfourteen/]).
* <code>rel=author</code> - in the absence of <code>author</code>, parse as '''<code>u-author</code>'''. While not a class name nor typical microformats property, rel=author was commonly used to link to an author's URL. Thus parsers should look for rel=author hyperlinks inside an hentry (or even on the same page, preceding the hentry), use the absolute version of it as a value for the '''<code>u-author</code>''' property if there is no "author" property. (citations to "hentry" examples in the wild that <em>depend</em> on rel=author needed to accepted this proposal. Note: default WordPress themes twentyeleven, twentytwelve, twentythirteen, twentyfourteen all use rel=author but only inside class="author vcard", and thus rel=author can be ignored since authorship is already picked up by existing <code>author</code> backcompat parsing.)

=== 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|rel=bookmark]]?''

A: tl;dr: use <code>class="u-url u-uid"</code> instead of <code>rel=bookmark</code> 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.

<nowiki>*</nowiki> even though rel=bookmark in particular is article-element / sectioning scoped in HTML5[http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-bookmark], 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 <code>entry-*</code> 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#Could_hAtom_instead_use_title_content_and_summary|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: [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-128 2012-08-30 IRC conversation].

== Related Work ==
Work that re-uses or builds upon h-entry:
* [https://mailpile.pagekite.me:8080/p/Open_Message_Format Mailpile Open Message Format] is using h-entry with structured properties, e.g. p-author h-card.

== Background ==
This work is based on the existing [[hAtom]] microformat, and extensive selfdogfooding in the [http://indiewebcamp.com 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 [[h-entry-issues|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|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|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_Additions|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|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|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 ==
* [[h-feed]]
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-geo]]
* [[hCard]]

[[Category:Specifications]]

h-entry

2021-08-20T04:39:43Z

Dshanske: /* Proposed Additions */

{{DISPLAYTITLE:h-entry}}
<dfn style="font-style:normal;font-weight:bold">h-entry</dfn> 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 [[microformats|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]].

;<span id="status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [[h-entry-issues|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|change control]] process.
;<span id="participate">Participate</span>
:[https://github.com/microformats/h-entry/issues Open Issues]
:[[h-entry-issues|Resolved issues before 2012-246]]
:[[IRC]]
:Advance the spec by following explicit [[#change_control|change control]] process
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__

== Example ==
Here is a simple blog post example:

<source lang=html4strict>
<article class="h-entry">
<h1 class="p-name">Microformats are amazing</h1>
<p>Published by <a class="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></p>

<p class="p-summary">In which I extoll the virtues of using microformats.</p>

<div class="e-content">
<p>Blah blah blah</p>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"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>"
}
]
}
}
]
}
</source>

== Get started ==
The class '''<code>h-entry</code>''' 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 optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

=== Core Properties ===
The following ''core'' h-entry properties have broad consensus and are broadly interoperably published and consumed:
* '''<code>p-name</code>''' - entry name/title
* '''<code>p-summary</code>''' - short entry summary
* '''<code>e-content</code>''' - full content of the entry
* '''<code>dt-published</code>''' - when the entry was published
* '''<code>dt-updated</code>''' - when the entry was updated
* '''<code>p-author</code>''' - who wrote the entry, optionally embedded [[h-card]](s)
* '''<code>p-category</code>''' - entry categories/tags
* '''<code>u-url</code>''' - entry permalink URL
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical entry URL
* '''<code>p-location</code>''' - location the entry was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code id="u-syndication">u-syndication</code>''' - URL(s) of syndicated copies of this post. The property equivalent of [[rel-syndication]] ([http://erinjo.is/2014/checked-into-rockit-colabs-23 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]) ([https://kartikprabhu.com/notes/re-citizen-of-indieweb example])
* '''<code id="p-rsvp">p-rsvp</code>''' (enum, use <data> element or [[value-class-pattern]])
** "yes", "no", "maybe", "interested". Case-insensitive values, normalized to lowercase. Examples:
** <code><nowiki>... <data class="p-rsvp" value="YES">is going</data> to ...</nowiki></code>, or
** <code><nowiki>... <data class="p-rsvp" value="Maybe">might go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="no">unable to go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="iNtEreSTed">am interested/tracking/watching</data> ...</nowiki></code>
* '''<code id="u-like-of">u-like-of</code>''' - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded [[h-cite]]
* '''<code id="u-repost-of">u-repost-of</code>''' - the URL which the h-entry is considered a “repost” of. Optionally an embedded [[h-cite]].

=== 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 id="p-comment">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])
** [https://github.com/microformats/h-entry/issues/20 Issue 20]
* '''<code id="u-photo">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.
** [https://github.com/microformats/h-entry/issues/4 Issue 4: u-photo draft->core bc way more than 3+ pub and consuming impls/sites]
* '''<code id="u-video">u-video</code>''' - special u- parsing rules for <code><video src> & <source src></code>
** [https://github.com/microformats/h-entry/issues/5 Issue 5]

=== 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 awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:
* '''<code>u-audio</code>''' - special u- parsing rules for <code><audio src> & <source src></code>. Examples: [http://transportini.com/ Transportini],[https://indieweb.org/podcast#How_to_podcast_with_h-feed possibly more]
** [https://github.com/microformats/h-entry/issues/6 Issue 6]
* '''<code>u-like</code>''' - similar to p-comment, URL to a like post of the current post, e.g. in a responses list or facepile.
* '''<code>u-repost</code>''' - similar to u-like, URL to a repost of the current post, e.g. in a responses list or facepile.
* '''<code>u-bookmark-of</code>''' - indicates this h-entry is a bookmark of another URL. Optionally an [[h-cite]]. See [https://indieweb.org/bookmark indieweb.org/bookmark] for examples in the wild.
** [https://github.com/microformats/h-entry/issues/12 Issue 12]
* '''<code>u-featured</code>''' - 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]].
** +1 sknebel: https://github.com/microformats/h-entry/issues/14
* '''<code>p-latitude</code>''' - latitude of the location of the entry
* '''<code>p-longitude</code>''' - longitude of the location of the entry
* '''<code>p-duration</code>''' - duration of an audio or video file in the entry. https://indieweb.org/duration Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>p-size</code>''' - size in bytes of an audio or video file in the entry. https://indieweb.org/size Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>u-listen-of</code>''' - also known as a 'scrobble', indicates this h-entry is a listen of another URL. Optionally an h-cite. https://github.com/microformats/h-entry/issues/11
* '''<code>u-watch-of</code>''' - indicates this h-entry is a watch of another URL, a visual version of the scrobble. Optionally an h-cite. https://github.com/microformats/h-entry/issues/17
* '''<code>p-read-of</code>''' - indicates this h-entry is a read post of some written work (book or other document). The value can be the title of the work or an h-cite. Proposal also mentions <code>u-read-of</code>, where the value would be a URL to the written work or a representative citation page. https://github.com/microformats/h-entry/issues/10
* '''<code>u-translation-of</code>''' - indicates this h-entry is a translation of the linked URL into another language. Can be used in the same way as the existing <code>u-like-of</code> and <code>u-repost-of</code> properties, with just the URL to the original h-entry, or (optionally) contain an embedded <code>h-cite</code>. https://github.com/microformats/h-entry/issues/26

The following interpretation is also proposed addition:
* if the <code>p-location</code> is also an embedded [[h-card]], the entry is treated as a "checkin".
** -1 [[User:Aaronpk|Aaronpk]] 14:22, 19 January 2017 (UTC) [https://aaronparecki.com/2017/01/13/21/ this post] is not a checkin, but has an h-card as the p-location property.

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: [[h-entry#change_control|change control]]

== Property Details ==
This section is a stub.
=== p-location ===
'''<code>p-location</code>''' has been re-used from [[h-event]].

== FAQ ==
=== p-name of a note ===
<div class="discussion">
* '''What is the <code>p-name</code> of a [https://indieweb.org/note note]?'''
** You probably should avoid adding <code>p-name</code> to notes. See https://indieweb.org/note for more discussion of the topic.
</div>

=== venue an entry was posted from ===
<div class="discussion">
* '''How do you indicate a named venue where an entry was posted from? Like a restaurant or park.'''
** Use an embedded [[h-card]] microformat on a <code>p-location</code> property value.
</div>

=== address an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== lat long an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== dt-published property and HTML5 time element ===
<div class="discussion">
* '''Does the dt-published property need to be a time element?'''
** The <code>dt-published</code> property should be a <code><time></code> 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.
</div>

=== what is the bare minimum list of required properties on an h-entry ===
<div class="discussion">
* 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:
</div>
* <code>url</code>
* <code>published</code> — if there is no "published" date for the "entry", then reconsider whether it is correct (or worth) marking it up as an entry.
<div class="discussion">
* 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:
</div>
* <code>content</code> (or <code>summary</code> at least) - especially for structured content. For a plain text note, the content/summary (whichever is used) should be the same as the <code>name</code>, otherwise it will be implied from the text content of the root element.
* <code>name</code> - for explicitly named/titled entries like blog posts and articles. Otherwise the entry is assumed to be a "title-less" [https://indieweb.org/note note] (like a tweet).
* <code>author</code> - including a nested <code>[[h-card]]</code> with author details like name, photo, url.

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

* ... add uses of h-entry you see in the wild here.
* ind.ie mark up their [https://ind.ie/blog blog] listing and [https://ind.ie/blog/autumn-events-2014/ permalink] pages with h-entry
* David John Mead marks up his profile, blog posts and comments with h-card, h-entry and h-cite on [http://davidjohnmead.com davidjohnmead.com]
* [[User:Brian|Brian Suda]] marks up his blog posts up with h-entry and h-card on [http://optional.is/required/ optional.is]
* Ashton McAllen marks up his blog posts, reposts, comments and likes with h-entry, h-card and h-cite on [http://acegiak.net/ acegiak.net]
* Emma Kuo marks up her blog posts and notes with h-entry and h-card on [http://notenoughneon.com/ notenoughneon.com]
* Scott Jenson marks up his blog posts with h-entry and h-card on [http://jenson.org/ jenson.org]
* Emily McAllen marks up her blog posts with h-entry and h-card on [http://blackwoolholiday.com/ blackwoolholiday.com]
* Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on [https://snarfed.org/ snarfed.org]
* Barry Frost marks up his notes with h-entry, h-card and h-cite on [http://barryfrost.com/ barryfrost.com]
* Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on [http://caseorganic.com/ caseorganic.com]
* Johannes Ernst marks up his blog posts with h-entry on [http://upon2020.com/blog/ upon2020.com]
* Michiel de Jong marks up his profile and notes with h-entry and h-card on [https://michielbdejong.com/ michielbdejong.com]
* Mike Taylor marks up his profile and blog posts with h-card and h-entry on [https://bear.im/bearlog/ bear.im]
* Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on [http://erinjo.is/ erinjo.is]
* Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on [https://jeena.net/ jeena.net]
* Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on [http://andysylvester.com/2014/03/01/howto-setting-up-the-selfoss-feed-reader-with-microformats-support/ andysylvester.com] (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --[[User:Barnabywalters|bw]] 14:44, 13 March 2014 (UTC))
* Chloe Weil marks up her blog posts with h-entry on [http://chloeweil.com/blog chloeweil.com]
* Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on [http://christopheducamp.com/ christopheducamp.com]
* Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on [http://glennjones.net/ glennjones.net]
* Marcus Povey marks up his blog posts and profile with h-entry and h-card on [http://www.marcus-povey.co.uk/ marcus-povey.co.uk]
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* Kyle Mahan marks up his profile and notes with h-card and h-entry on [http://kylewm.com/ kylewm.com]
* Okinawan-lyrics marks up his posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* App.net marks up profile pages and permalink pages with h-entry as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* The Twitter archive browser UI uses h-entry and h-card internally, unfortunately it’s not exposed as HTML in static files anywhere
* Brett Comnes marks up his posts with h-entry and h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like ([http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his posts up with h-card and h-entry, as well as draft u-in-reply-to and experimental u-like properties ([http://sandeep.io/101 example])
* Laurent Eschenauer marks up his posts with h-entry ([http://eschnou.com/entry/first-autonomous-flight-of-my-nodecopter-62-24992.html example])
* Tom Morris marks up his posts using h-entry ([http://tommorris.org/posts/8417 example])
* Numerous newer W3C specs, e.g.
** [http://www.w3.org/TR/2013/CR-css3-values-20130404/ CSS Values and Units Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/CR-css3-conditional-20130404/ CSS Conditional Rules Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/WD-css3-page-20130314/ CSS Paged Media Module Level 3 - 2013-03-14]
** [http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/ CSS Counter Styles Level 3 - 2013-02-21]
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry.
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Aaron Parecki uses h-entry to mark up notes, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-entry on his home page, as well as h-entry on all post permalinks, e.g. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], with [[rel-prev]]/[[rel-next]] (if applicable) to indicate prev/next posts
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-entry on all notes and articles, as well as nested within notes as reply contexts [http://waterpigs.co.uk/notes/1468/ example] and comments [http://waterpigs.co.uk/notes/1482/ example].

=== offline ===
* spreadly marks up share permalink pages with h-entry, as well as minimal h-cards and experimental p-like properties

== Validating ==
* '''[http://indiewebify.me/validate-h-entry/ indiewebify.me h-entry validator]''' parses [[h-entry]] markup, finds common errors and makes suggestions for things to add, with code samples
* '''[http://shrewdness.waterpigs.co.uk/test/ Shrewdness h-entry/h-feed validator]''' shows how shrewdness interprets+displays h-entries, with original source and interim formats, works for single h-entries and feed pages

{{h-spec-section-validating}}

== 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 [https://indieweb.org/ 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.
* [https://gnu.io/social/ GNUsocial] [https://git.gnu.io/gnu/gnu-social/ source code]
* [https://hubzilla.org/hubzilla/ Hubzilla] [https://github.org/redmatrix/hubzilla source code]
* [http://friendica.com/ Friendica] [https://github.org/friendica/friendica source code]
* [http://github.com/dissolve/inkblot InkBlot]
* ...

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

<source lang=html4strict>
<article class="h-entry hentry">
<h1 class="p-name entry-title">A Tale Of Two Tags</h1>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="e-content entry-content">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
<p>The a tag is perhaps the best of HTML, yet its corresponding invisible link tag has uses too.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>
</source>

{{note|Note: you may use any valid HTML5 elements. The <code>article h1 address time</code> elements are used in the example as semantically richer suggestions, however in general <code>div span</code> work fine too. The <code>time</code> element is special though in that its <code>datetime</code> 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: <code id="hentry">hentry</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

* <code>entry-title</code> - parse as '''<code>p-name</code>'''
* <code>entry-summary</code> - parse as '''<code>p-summary</code>'''
* <code>entry-content</code> - parse as '''<code>e-content</code>'''
* <code>published</code> - parse as '''dt-'''
* <code>updated</code> - parse as '''dt-'''
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>category</code>
* <code>rel=bookmark</code> - parse as '''<code>u-url</code>'''. While not a class name nor typical microformats property, rel=bookmark was the only way to indicate an hentry permalink. Thus parsers should look for rel=bookmark hyperlinks inside an hentry, and take their "href" value as a value for a '''<code>u-url</code>''' property, including handling any relative URL resolution.
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hentry. Thus parsers should look for rel=tag hyperlinks inside an hentry, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

Proposed: ([https://github.com/microformats/h-entry/issues/7 follow-up in issue #7])
* <code>time.entry-date[datetime]</code> - in the absence of <code>published</code>, parse as '''<code>dt-published</code>'''. parse for the first <code><time></code> element with class name of <code>entry-date</code> and non-empty <code>datetime</code> attribute inside an hentry, if there is no <code>published</code> property, use that time element's <code>datetime</code> attribute value for the <code>dt-published</code> property. Evidence: default WordPress themes 2011-2014([https://wp-themes.com/twentyeleven/][https://wp-themes.com/twentytwelve/][https://wp-themes.com/twentythirteen/][https://wp-themes.com/twentyfourteen/]).
* <code>rel=author</code> - in the absence of <code>author</code>, parse as '''<code>u-author</code>'''. While not a class name nor typical microformats property, rel=author was commonly used to link to an author's URL. Thus parsers should look for rel=author hyperlinks inside an hentry (or even on the same page, preceding the hentry), use the absolute version of it as a value for the '''<code>u-author</code>''' property if there is no "author" property. (citations to "hentry" examples in the wild that <em>depend</em> on rel=author needed to accepted this proposal. Note: default WordPress themes twentyeleven, twentytwelve, twentythirteen, twentyfourteen all use rel=author but only inside class="author vcard", and thus rel=author can be ignored since authorship is already picked up by existing <code>author</code> backcompat parsing.)

=== 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|rel=bookmark]]?''

A: tl;dr: use <code>class="u-url u-uid"</code> instead of <code>rel=bookmark</code> 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.

<nowiki>*</nowiki> even though rel=bookmark in particular is article-element / sectioning scoped in HTML5[http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-bookmark], 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 <code>entry-*</code> 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#Could_hAtom_instead_use_title_content_and_summary|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: [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-128 2012-08-30 IRC conversation].

== Related Work ==
Work that re-uses or builds upon h-entry:
* [https://mailpile.pagekite.me:8080/p/Open_Message_Format Mailpile Open Message Format] is using h-entry with structured properties, e.g. p-author h-card.

== Background ==
This work is based on the existing [[hAtom]] microformat, and extensive selfdogfooding in the [http://indiewebcamp.com 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 [[h-entry-issues|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|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|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_Additions|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|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|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 ==
* [[h-feed]]
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-geo]]
* [[hCard]]

[[Category:Specifications]]

h-entry

2021-08-20T04:38:58Z

Dshanske: /* Proposed Additions */

{{DISPLAYTITLE:h-entry}}
<dfn style="font-style:normal;font-weight:bold">h-entry</dfn> 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 [[microformats|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]].

;<span id="status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [[h-entry-issues|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|change control]] process.
;<span id="participate">Participate</span>
:[https://github.com/microformats/h-entry/issues Open Issues]
:[[h-entry-issues|Resolved issues before 2012-246]]
:[[IRC]]
:Advance the spec by following explicit [[#change_control|change control]] process
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__

== Example ==
Here is a simple blog post example:

<source lang=html4strict>
<article class="h-entry">
<h1 class="p-name">Microformats are amazing</h1>
<p>Published by <a class="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></p>

<p class="p-summary">In which I extoll the virtues of using microformats.</p>

<div class="e-content">
<p>Blah blah blah</p>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"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>"
}
]
}
}
]
}
</source>

== Get started ==
The class '''<code>h-entry</code>''' 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 optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

=== Core Properties ===
The following ''core'' h-entry properties have broad consensus and are broadly interoperably published and consumed:
* '''<code>p-name</code>''' - entry name/title
* '''<code>p-summary</code>''' - short entry summary
* '''<code>e-content</code>''' - full content of the entry
* '''<code>dt-published</code>''' - when the entry was published
* '''<code>dt-updated</code>''' - when the entry was updated
* '''<code>p-author</code>''' - who wrote the entry, optionally embedded [[h-card]](s)
* '''<code>p-category</code>''' - entry categories/tags
* '''<code>u-url</code>''' - entry permalink URL
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical entry URL
* '''<code>p-location</code>''' - location the entry was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code id="u-syndication">u-syndication</code>''' - URL(s) of syndicated copies of this post. The property equivalent of [[rel-syndication]] ([http://erinjo.is/2014/checked-into-rockit-colabs-23 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]) ([https://kartikprabhu.com/notes/re-citizen-of-indieweb example])
* '''<code id="p-rsvp">p-rsvp</code>''' (enum, use <data> element or [[value-class-pattern]])
** "yes", "no", "maybe", "interested". Case-insensitive values, normalized to lowercase. Examples:
** <code><nowiki>... <data class="p-rsvp" value="YES">is going</data> to ...</nowiki></code>, or
** <code><nowiki>... <data class="p-rsvp" value="Maybe">might go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="no">unable to go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="iNtEreSTed">am interested/tracking/watching</data> ...</nowiki></code>
* '''<code id="u-like-of">u-like-of</code>''' - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded [[h-cite]]
* '''<code id="u-repost-of">u-repost-of</code>''' - the URL which the h-entry is considered a “repost” of. Optionally an embedded [[h-cite]].

=== 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 id="p-comment">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])
** [https://github.com/microformats/h-entry/issues/20 Issue 20]
* '''<code id="u-photo">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.
** [https://github.com/microformats/h-entry/issues/4 Issue 4: u-photo draft->core bc way more than 3+ pub and consuming impls/sites]
* '''<code id="u-video">u-video</code>''' - special u- parsing rules for <code><video src> & <source src></code>
** [https://github.com/microformats/h-entry/issues/5 Issue 5]

=== 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 awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:
* '''<code>u-audio</code>''' - special u- parsing rules for <code><audio src> & <source src></code>. Examples: [http://transportini.com/ Transportini],[https://indieweb.org/podcast#How_to_podcast_with_h-feed possibly more]
** [https://github.com/microformats/h-entry/issues/6 Issue 6]
* '''<code>u-like</code>''' - similar to p-comment, URL to a like post of the current post, e.g. in a responses list or facepile.
* '''<code>u-repost</code>''' - similar to u-like, URL to a repost of the current post, e.g. in a responses list or facepile.
* '''<code>u-bookmark-of</code>''' - indicates this h-entry is a bookmark of another URL. Optionally an [[h-cite]]. See [https://indieweb.org/bookmark indieweb.org/bookmark] for examples in the wild.
* '''<code>u-featured</code>''' - 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]].
** +1 sknebel: https://github.com/microformats/h-entry/issues/14
* '''<code>p-latitude</code>''' - latitude of the location of the entry
* '''<code>p-longitude</code>''' - longitude of the location of the entry
* '''<code>p-duration</code>''' - duration of an audio or video file in the entry. https://indieweb.org/duration Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>p-size</code>''' - size in bytes of an audio or video file in the entry. https://indieweb.org/size Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>u-listen-of</code>''' - also known as a 'scrobble', indicates this h-entry is a listen of another URL. Optionally an h-cite. https://github.com/microformats/h-entry/issues/11
* '''<code>u-watch-of</code>''' - indicates this h-entry is a watch of another URL, a visual version of the scrobble. Optionally an h-cite. https://github.com/microformats/h-entry/issues/17
* '''<code>p-read-of</code>''' - indicates this h-entry is a read post of some written work (book or other document). The value can be the title of the work or an h-cite. Proposal also mentions <code>u-read-of</code>, where the value would be a URL to the written work or a representative citation page. https://github.com/microformats/h-entry/issues/10
* '''<code>u-translation-of</code>''' - indicates this h-entry is a translation of the linked URL into another language. Can be used in the same way as the existing <code>u-like-of</code> and <code>u-repost-of</code> properties, with just the URL to the original h-entry, or (optionally) contain an embedded <code>h-cite</code>. https://github.com/microformats/h-entry/issues/26

The following interpretation is also proposed addition:
* if the <code>p-location</code> is also an embedded [[h-card]], the entry is treated as a "checkin".
** -1 [[User:Aaronpk|Aaronpk]] 14:22, 19 January 2017 (UTC) [https://aaronparecki.com/2017/01/13/21/ this post] is not a checkin, but has an h-card as the p-location property.

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: [[h-entry#change_control|change control]]

== Property Details ==
This section is a stub.
=== p-location ===
'''<code>p-location</code>''' has been re-used from [[h-event]].

== FAQ ==
=== p-name of a note ===
<div class="discussion">
* '''What is the <code>p-name</code> of a [https://indieweb.org/note note]?'''
** You probably should avoid adding <code>p-name</code> to notes. See https://indieweb.org/note for more discussion of the topic.
</div>

=== venue an entry was posted from ===
<div class="discussion">
* '''How do you indicate a named venue where an entry was posted from? Like a restaurant or park.'''
** Use an embedded [[h-card]] microformat on a <code>p-location</code> property value.
</div>

=== address an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== lat long an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== dt-published property and HTML5 time element ===
<div class="discussion">
* '''Does the dt-published property need to be a time element?'''
** The <code>dt-published</code> property should be a <code><time></code> 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.
</div>

=== what is the bare minimum list of required properties on an h-entry ===
<div class="discussion">
* 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:
</div>
* <code>url</code>
* <code>published</code> — if there is no "published" date for the "entry", then reconsider whether it is correct (or worth) marking it up as an entry.
<div class="discussion">
* 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:
</div>
* <code>content</code> (or <code>summary</code> at least) - especially for structured content. For a plain text note, the content/summary (whichever is used) should be the same as the <code>name</code>, otherwise it will be implied from the text content of the root element.
* <code>name</code> - for explicitly named/titled entries like blog posts and articles. Otherwise the entry is assumed to be a "title-less" [https://indieweb.org/note note] (like a tweet).
* <code>author</code> - including a nested <code>[[h-card]]</code> with author details like name, photo, url.

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

* ... add uses of h-entry you see in the wild here.
* ind.ie mark up their [https://ind.ie/blog blog] listing and [https://ind.ie/blog/autumn-events-2014/ permalink] pages with h-entry
* David John Mead marks up his profile, blog posts and comments with h-card, h-entry and h-cite on [http://davidjohnmead.com davidjohnmead.com]
* [[User:Brian|Brian Suda]] marks up his blog posts up with h-entry and h-card on [http://optional.is/required/ optional.is]
* Ashton McAllen marks up his blog posts, reposts, comments and likes with h-entry, h-card and h-cite on [http://acegiak.net/ acegiak.net]
* Emma Kuo marks up her blog posts and notes with h-entry and h-card on [http://notenoughneon.com/ notenoughneon.com]
* Scott Jenson marks up his blog posts with h-entry and h-card on [http://jenson.org/ jenson.org]
* Emily McAllen marks up her blog posts with h-entry and h-card on [http://blackwoolholiday.com/ blackwoolholiday.com]
* Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on [https://snarfed.org/ snarfed.org]
* Barry Frost marks up his notes with h-entry, h-card and h-cite on [http://barryfrost.com/ barryfrost.com]
* Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on [http://caseorganic.com/ caseorganic.com]
* Johannes Ernst marks up his blog posts with h-entry on [http://upon2020.com/blog/ upon2020.com]
* Michiel de Jong marks up his profile and notes with h-entry and h-card on [https://michielbdejong.com/ michielbdejong.com]
* Mike Taylor marks up his profile and blog posts with h-card and h-entry on [https://bear.im/bearlog/ bear.im]
* Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on [http://erinjo.is/ erinjo.is]
* Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on [https://jeena.net/ jeena.net]
* Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on [http://andysylvester.com/2014/03/01/howto-setting-up-the-selfoss-feed-reader-with-microformats-support/ andysylvester.com] (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --[[User:Barnabywalters|bw]] 14:44, 13 March 2014 (UTC))
* Chloe Weil marks up her blog posts with h-entry on [http://chloeweil.com/blog chloeweil.com]
* Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on [http://christopheducamp.com/ christopheducamp.com]
* Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on [http://glennjones.net/ glennjones.net]
* Marcus Povey marks up his blog posts and profile with h-entry and h-card on [http://www.marcus-povey.co.uk/ marcus-povey.co.uk]
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* Kyle Mahan marks up his profile and notes with h-card and h-entry on [http://kylewm.com/ kylewm.com]
* Okinawan-lyrics marks up his posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* App.net marks up profile pages and permalink pages with h-entry as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* The Twitter archive browser UI uses h-entry and h-card internally, unfortunately it’s not exposed as HTML in static files anywhere
* Brett Comnes marks up his posts with h-entry and h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like ([http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his posts up with h-card and h-entry, as well as draft u-in-reply-to and experimental u-like properties ([http://sandeep.io/101 example])
* Laurent Eschenauer marks up his posts with h-entry ([http://eschnou.com/entry/first-autonomous-flight-of-my-nodecopter-62-24992.html example])
* Tom Morris marks up his posts using h-entry ([http://tommorris.org/posts/8417 example])
* Numerous newer W3C specs, e.g.
** [http://www.w3.org/TR/2013/CR-css3-values-20130404/ CSS Values and Units Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/CR-css3-conditional-20130404/ CSS Conditional Rules Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/WD-css3-page-20130314/ CSS Paged Media Module Level 3 - 2013-03-14]
** [http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/ CSS Counter Styles Level 3 - 2013-02-21]
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry.
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Aaron Parecki uses h-entry to mark up notes, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-entry on his home page, as well as h-entry on all post permalinks, e.g. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], with [[rel-prev]]/[[rel-next]] (if applicable) to indicate prev/next posts
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-entry on all notes and articles, as well as nested within notes as reply contexts [http://waterpigs.co.uk/notes/1468/ example] and comments [http://waterpigs.co.uk/notes/1482/ example].

=== offline ===
* spreadly marks up share permalink pages with h-entry, as well as minimal h-cards and experimental p-like properties

== Validating ==
* '''[http://indiewebify.me/validate-h-entry/ indiewebify.me h-entry validator]''' parses [[h-entry]] markup, finds common errors and makes suggestions for things to add, with code samples
* '''[http://shrewdness.waterpigs.co.uk/test/ Shrewdness h-entry/h-feed validator]''' shows how shrewdness interprets+displays h-entries, with original source and interim formats, works for single h-entries and feed pages

{{h-spec-section-validating}}

== 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 [https://indieweb.org/ 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.
* [https://gnu.io/social/ GNUsocial] [https://git.gnu.io/gnu/gnu-social/ source code]
* [https://hubzilla.org/hubzilla/ Hubzilla] [https://github.org/redmatrix/hubzilla source code]
* [http://friendica.com/ Friendica] [https://github.org/friendica/friendica source code]
* [http://github.com/dissolve/inkblot InkBlot]
* ...

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

<source lang=html4strict>
<article class="h-entry hentry">
<h1 class="p-name entry-title">A Tale Of Two Tags</h1>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="e-content entry-content">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
<p>The a tag is perhaps the best of HTML, yet its corresponding invisible link tag has uses too.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>
</source>

{{note|Note: you may use any valid HTML5 elements. The <code>article h1 address time</code> elements are used in the example as semantically richer suggestions, however in general <code>div span</code> work fine too. The <code>time</code> element is special though in that its <code>datetime</code> 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: <code id="hentry">hentry</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

* <code>entry-title</code> - parse as '''<code>p-name</code>'''
* <code>entry-summary</code> - parse as '''<code>p-summary</code>'''
* <code>entry-content</code> - parse as '''<code>e-content</code>'''
* <code>published</code> - parse as '''dt-'''
* <code>updated</code> - parse as '''dt-'''
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>category</code>
* <code>rel=bookmark</code> - parse as '''<code>u-url</code>'''. While not a class name nor typical microformats property, rel=bookmark was the only way to indicate an hentry permalink. Thus parsers should look for rel=bookmark hyperlinks inside an hentry, and take their "href" value as a value for a '''<code>u-url</code>''' property, including handling any relative URL resolution.
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hentry. Thus parsers should look for rel=tag hyperlinks inside an hentry, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

Proposed: ([https://github.com/microformats/h-entry/issues/7 follow-up in issue #7])
* <code>time.entry-date[datetime]</code> - in the absence of <code>published</code>, parse as '''<code>dt-published</code>'''. parse for the first <code><time></code> element with class name of <code>entry-date</code> and non-empty <code>datetime</code> attribute inside an hentry, if there is no <code>published</code> property, use that time element's <code>datetime</code> attribute value for the <code>dt-published</code> property. Evidence: default WordPress themes 2011-2014([https://wp-themes.com/twentyeleven/][https://wp-themes.com/twentytwelve/][https://wp-themes.com/twentythirteen/][https://wp-themes.com/twentyfourteen/]).
* <code>rel=author</code> - in the absence of <code>author</code>, parse as '''<code>u-author</code>'''. While not a class name nor typical microformats property, rel=author was commonly used to link to an author's URL. Thus parsers should look for rel=author hyperlinks inside an hentry (or even on the same page, preceding the hentry), use the absolute version of it as a value for the '''<code>u-author</code>''' property if there is no "author" property. (citations to "hentry" examples in the wild that <em>depend</em> on rel=author needed to accepted this proposal. Note: default WordPress themes twentyeleven, twentytwelve, twentythirteen, twentyfourteen all use rel=author but only inside class="author vcard", and thus rel=author can be ignored since authorship is already picked up by existing <code>author</code> backcompat parsing.)

=== 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|rel=bookmark]]?''

A: tl;dr: use <code>class="u-url u-uid"</code> instead of <code>rel=bookmark</code> 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.

<nowiki>*</nowiki> even though rel=bookmark in particular is article-element / sectioning scoped in HTML5[http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-bookmark], 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 <code>entry-*</code> 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#Could_hAtom_instead_use_title_content_and_summary|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: [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-128 2012-08-30 IRC conversation].

== Related Work ==
Work that re-uses or builds upon h-entry:
* [https://mailpile.pagekite.me:8080/p/Open_Message_Format Mailpile Open Message Format] is using h-entry with structured properties, e.g. p-author h-card.

== Background ==
This work is based on the existing [[hAtom]] microformat, and extensive selfdogfooding in the [http://indiewebcamp.com 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 [[h-entry-issues|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|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|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_Additions|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|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|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 ==
* [[h-feed]]
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-geo]]
* [[hCard]]

[[Category:Specifications]]

h-entry

2021-08-20T04:37:33Z

Dshanske: /* Draft Properties */

{{DISPLAYTITLE:h-entry}}
<dfn style="font-style:normal;font-weight:bold">h-entry</dfn> 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 [[microformats|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]].

;<span id="status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [[h-entry-issues|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|change control]] process.
;<span id="participate">Participate</span>
:[https://github.com/microformats/h-entry/issues Open Issues]
:[[h-entry-issues|Resolved issues before 2012-246]]
:[[IRC]]
:Advance the spec by following explicit [[#change_control|change control]] process
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__

== Example ==
Here is a simple blog post example:

<source lang=html4strict>
<article class="h-entry">
<h1 class="p-name">Microformats are amazing</h1>
<p>Published by <a class="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></p>

<p class="p-summary">In which I extoll the virtues of using microformats.</p>

<div class="e-content">
<p>Blah blah blah</p>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"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>"
}
]
}
}
]
}
</source>

== Get started ==
The class '''<code>h-entry</code>''' 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 optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

=== Core Properties ===
The following ''core'' h-entry properties have broad consensus and are broadly interoperably published and consumed:
* '''<code>p-name</code>''' - entry name/title
* '''<code>p-summary</code>''' - short entry summary
* '''<code>e-content</code>''' - full content of the entry
* '''<code>dt-published</code>''' - when the entry was published
* '''<code>dt-updated</code>''' - when the entry was updated
* '''<code>p-author</code>''' - who wrote the entry, optionally embedded [[h-card]](s)
* '''<code>p-category</code>''' - entry categories/tags
* '''<code>u-url</code>''' - entry permalink URL
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical entry URL
* '''<code>p-location</code>''' - location the entry was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code id="u-syndication">u-syndication</code>''' - URL(s) of syndicated copies of this post. The property equivalent of [[rel-syndication]] ([http://erinjo.is/2014/checked-into-rockit-colabs-23 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]) ([https://kartikprabhu.com/notes/re-citizen-of-indieweb example])
* '''<code id="p-rsvp">p-rsvp</code>''' (enum, use <data> element or [[value-class-pattern]])
** "yes", "no", "maybe", "interested". Case-insensitive values, normalized to lowercase. Examples:
** <code><nowiki>... <data class="p-rsvp" value="YES">is going</data> to ...</nowiki></code>, or
** <code><nowiki>... <data class="p-rsvp" value="Maybe">might go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="no">unable to go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="iNtEreSTed">am interested/tracking/watching</data> ...</nowiki></code>
* '''<code id="u-like-of">u-like-of</code>''' - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded [[h-cite]]
* '''<code id="u-repost-of">u-repost-of</code>''' - the URL which the h-entry is considered a “repost” of. Optionally an embedded [[h-cite]].

=== 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 id="p-comment">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])
** [https://github.com/microformats/h-entry/issues/20 Issue 20]
* '''<code id="u-photo">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.
** [https://github.com/microformats/h-entry/issues/4 Issue 4: u-photo draft->core bc way more than 3+ pub and consuming impls/sites]
* '''<code id="u-video">u-video</code>''' - special u- parsing rules for <code><video src> & <source src></code>
** [https://github.com/microformats/h-entry/issues/5 Issue 5]

=== 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 awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:
* '''<code>u-audio</code>''' - special u- parsing rules for <code><audio src> & <source src></code>. Examples: [http://transportini.com/ Transportini],[https://indieweb.org/podcast#How_to_podcast_with_h-feed possibly more]
* '''<code>u-like</code>''' - similar to p-comment, URL to a like post of the current post, e.g. in a responses list or facepile.
* '''<code>u-repost</code>''' - similar to u-like, URL to a repost of the current post, e.g. in a responses list or facepile.
* '''<code>u-bookmark-of</code>''' - indicates this h-entry is a bookmark of another URL. Optionally an [[h-cite]]. See [https://indieweb.org/bookmark indieweb.org/bookmark] for examples in the wild.
* '''<code>u-featured</code>''' - 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]].
** +1 sknebel: https://github.com/microformats/h-entry/issues/14
* '''<code>p-latitude</code>''' - latitude of the location of the entry
* '''<code>p-longitude</code>''' - longitude of the location of the entry
* '''<code>p-duration</code>''' - duration of an audio or video file in the entry. https://indieweb.org/duration Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>p-size</code>''' - size in bytes of an audio or video file in the entry. https://indieweb.org/size Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>u-listen-of</code>''' - also known as a 'scrobble', indicates this h-entry is a listen of another URL. Optionally an h-cite. https://github.com/microformats/h-entry/issues/11
* '''<code>u-watch-of</code>''' - indicates this h-entry is a watch of another URL, a visual version of the scrobble. Optionally an h-cite. https://github.com/microformats/h-entry/issues/17
* '''<code>p-read-of</code>''' - indicates this h-entry is a read post of some written work (book or other document). The value can be the title of the work or an h-cite. Proposal also mentions <code>u-read-of</code>, where the value would be a URL to the written work or a representative citation page. https://github.com/microformats/h-entry/issues/10
* '''<code>u-translation-of</code>''' - indicates this h-entry is a translation of the linked URL into another language. Can be used in the same way as the existing <code>u-like-of</code> and <code>u-repost-of</code> properties, with just the URL to the original h-entry, or (optionally) contain an embedded <code>h-cite</code>. https://github.com/microformats/h-entry/issues/26

The following interpretation is also proposed addition:
* if the <code>p-location</code> is also an embedded [[h-card]], the entry is treated as a "checkin".
** -1 [[User:Aaronpk|Aaronpk]] 14:22, 19 January 2017 (UTC) [https://aaronparecki.com/2017/01/13/21/ this post] is not a checkin, but has an h-card as the p-location property.

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: [[h-entry#change_control|change control]]

== Property Details ==
This section is a stub.
=== p-location ===
'''<code>p-location</code>''' has been re-used from [[h-event]].

== FAQ ==
=== p-name of a note ===
<div class="discussion">
* '''What is the <code>p-name</code> of a [https://indieweb.org/note note]?'''
** You probably should avoid adding <code>p-name</code> to notes. See https://indieweb.org/note for more discussion of the topic.
</div>

=== venue an entry was posted from ===
<div class="discussion">
* '''How do you indicate a named venue where an entry was posted from? Like a restaurant or park.'''
** Use an embedded [[h-card]] microformat on a <code>p-location</code> property value.
</div>

=== address an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== lat long an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== dt-published property and HTML5 time element ===
<div class="discussion">
* '''Does the dt-published property need to be a time element?'''
** The <code>dt-published</code> property should be a <code><time></code> 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.
</div>

=== what is the bare minimum list of required properties on an h-entry ===
<div class="discussion">
* 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:
</div>
* <code>url</code>
* <code>published</code> — if there is no "published" date for the "entry", then reconsider whether it is correct (or worth) marking it up as an entry.
<div class="discussion">
* 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:
</div>
* <code>content</code> (or <code>summary</code> at least) - especially for structured content. For a plain text note, the content/summary (whichever is used) should be the same as the <code>name</code>, otherwise it will be implied from the text content of the root element.
* <code>name</code> - for explicitly named/titled entries like blog posts and articles. Otherwise the entry is assumed to be a "title-less" [https://indieweb.org/note note] (like a tweet).
* <code>author</code> - including a nested <code>[[h-card]]</code> with author details like name, photo, url.

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

* ... add uses of h-entry you see in the wild here.
* ind.ie mark up their [https://ind.ie/blog blog] listing and [https://ind.ie/blog/autumn-events-2014/ permalink] pages with h-entry
* David John Mead marks up his profile, blog posts and comments with h-card, h-entry and h-cite on [http://davidjohnmead.com davidjohnmead.com]
* [[User:Brian|Brian Suda]] marks up his blog posts up with h-entry and h-card on [http://optional.is/required/ optional.is]
* Ashton McAllen marks up his blog posts, reposts, comments and likes with h-entry, h-card and h-cite on [http://acegiak.net/ acegiak.net]
* Emma Kuo marks up her blog posts and notes with h-entry and h-card on [http://notenoughneon.com/ notenoughneon.com]
* Scott Jenson marks up his blog posts with h-entry and h-card on [http://jenson.org/ jenson.org]
* Emily McAllen marks up her blog posts with h-entry and h-card on [http://blackwoolholiday.com/ blackwoolholiday.com]
* Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on [https://snarfed.org/ snarfed.org]
* Barry Frost marks up his notes with h-entry, h-card and h-cite on [http://barryfrost.com/ barryfrost.com]
* Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on [http://caseorganic.com/ caseorganic.com]
* Johannes Ernst marks up his blog posts with h-entry on [http://upon2020.com/blog/ upon2020.com]
* Michiel de Jong marks up his profile and notes with h-entry and h-card on [https://michielbdejong.com/ michielbdejong.com]
* Mike Taylor marks up his profile and blog posts with h-card and h-entry on [https://bear.im/bearlog/ bear.im]
* Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on [http://erinjo.is/ erinjo.is]
* Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on [https://jeena.net/ jeena.net]
* Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on [http://andysylvester.com/2014/03/01/howto-setting-up-the-selfoss-feed-reader-with-microformats-support/ andysylvester.com] (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --[[User:Barnabywalters|bw]] 14:44, 13 March 2014 (UTC))
* Chloe Weil marks up her blog posts with h-entry on [http://chloeweil.com/blog chloeweil.com]
* Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on [http://christopheducamp.com/ christopheducamp.com]
* Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on [http://glennjones.net/ glennjones.net]
* Marcus Povey marks up his blog posts and profile with h-entry and h-card on [http://www.marcus-povey.co.uk/ marcus-povey.co.uk]
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* Kyle Mahan marks up his profile and notes with h-card and h-entry on [http://kylewm.com/ kylewm.com]
* Okinawan-lyrics marks up his posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* App.net marks up profile pages and permalink pages with h-entry as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* The Twitter archive browser UI uses h-entry and h-card internally, unfortunately it’s not exposed as HTML in static files anywhere
* Brett Comnes marks up his posts with h-entry and h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like ([http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his posts up with h-card and h-entry, as well as draft u-in-reply-to and experimental u-like properties ([http://sandeep.io/101 example])
* Laurent Eschenauer marks up his posts with h-entry ([http://eschnou.com/entry/first-autonomous-flight-of-my-nodecopter-62-24992.html example])
* Tom Morris marks up his posts using h-entry ([http://tommorris.org/posts/8417 example])
* Numerous newer W3C specs, e.g.
** [http://www.w3.org/TR/2013/CR-css3-values-20130404/ CSS Values and Units Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/CR-css3-conditional-20130404/ CSS Conditional Rules Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/WD-css3-page-20130314/ CSS Paged Media Module Level 3 - 2013-03-14]
** [http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/ CSS Counter Styles Level 3 - 2013-02-21]
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry.
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Aaron Parecki uses h-entry to mark up notes, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-entry on his home page, as well as h-entry on all post permalinks, e.g. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], with [[rel-prev]]/[[rel-next]] (if applicable) to indicate prev/next posts
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-entry on all notes and articles, as well as nested within notes as reply contexts [http://waterpigs.co.uk/notes/1468/ example] and comments [http://waterpigs.co.uk/notes/1482/ example].

=== offline ===
* spreadly marks up share permalink pages with h-entry, as well as minimal h-cards and experimental p-like properties

== Validating ==
* '''[http://indiewebify.me/validate-h-entry/ indiewebify.me h-entry validator]''' parses [[h-entry]] markup, finds common errors and makes suggestions for things to add, with code samples
* '''[http://shrewdness.waterpigs.co.uk/test/ Shrewdness h-entry/h-feed validator]''' shows how shrewdness interprets+displays h-entries, with original source and interim formats, works for single h-entries and feed pages

{{h-spec-section-validating}}

== 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 [https://indieweb.org/ 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.
* [https://gnu.io/social/ GNUsocial] [https://git.gnu.io/gnu/gnu-social/ source code]
* [https://hubzilla.org/hubzilla/ Hubzilla] [https://github.org/redmatrix/hubzilla source code]
* [http://friendica.com/ Friendica] [https://github.org/friendica/friendica source code]
* [http://github.com/dissolve/inkblot InkBlot]
* ...

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

<source lang=html4strict>
<article class="h-entry hentry">
<h1 class="p-name entry-title">A Tale Of Two Tags</h1>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="e-content entry-content">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
<p>The a tag is perhaps the best of HTML, yet its corresponding invisible link tag has uses too.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>
</source>

{{note|Note: you may use any valid HTML5 elements. The <code>article h1 address time</code> elements are used in the example as semantically richer suggestions, however in general <code>div span</code> work fine too. The <code>time</code> element is special though in that its <code>datetime</code> 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: <code id="hentry">hentry</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

* <code>entry-title</code> - parse as '''<code>p-name</code>'''
* <code>entry-summary</code> - parse as '''<code>p-summary</code>'''
* <code>entry-content</code> - parse as '''<code>e-content</code>'''
* <code>published</code> - parse as '''dt-'''
* <code>updated</code> - parse as '''dt-'''
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>category</code>
* <code>rel=bookmark</code> - parse as '''<code>u-url</code>'''. While not a class name nor typical microformats property, rel=bookmark was the only way to indicate an hentry permalink. Thus parsers should look for rel=bookmark hyperlinks inside an hentry, and take their "href" value as a value for a '''<code>u-url</code>''' property, including handling any relative URL resolution.
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hentry. Thus parsers should look for rel=tag hyperlinks inside an hentry, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

Proposed: ([https://github.com/microformats/h-entry/issues/7 follow-up in issue #7])
* <code>time.entry-date[datetime]</code> - in the absence of <code>published</code>, parse as '''<code>dt-published</code>'''. parse for the first <code><time></code> element with class name of <code>entry-date</code> and non-empty <code>datetime</code> attribute inside an hentry, if there is no <code>published</code> property, use that time element's <code>datetime</code> attribute value for the <code>dt-published</code> property. Evidence: default WordPress themes 2011-2014([https://wp-themes.com/twentyeleven/][https://wp-themes.com/twentytwelve/][https://wp-themes.com/twentythirteen/][https://wp-themes.com/twentyfourteen/]).
* <code>rel=author</code> - in the absence of <code>author</code>, parse as '''<code>u-author</code>'''. While not a class name nor typical microformats property, rel=author was commonly used to link to an author's URL. Thus parsers should look for rel=author hyperlinks inside an hentry (or even on the same page, preceding the hentry), use the absolute version of it as a value for the '''<code>u-author</code>''' property if there is no "author" property. (citations to "hentry" examples in the wild that <em>depend</em> on rel=author needed to accepted this proposal. Note: default WordPress themes twentyeleven, twentytwelve, twentythirteen, twentyfourteen all use rel=author but only inside class="author vcard", and thus rel=author can be ignored since authorship is already picked up by existing <code>author</code> backcompat parsing.)

=== 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|rel=bookmark]]?''

A: tl;dr: use <code>class="u-url u-uid"</code> instead of <code>rel=bookmark</code> 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.

<nowiki>*</nowiki> even though rel=bookmark in particular is article-element / sectioning scoped in HTML5[http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-bookmark], 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 <code>entry-*</code> 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#Could_hAtom_instead_use_title_content_and_summary|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: [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-128 2012-08-30 IRC conversation].

== Related Work ==
Work that re-uses or builds upon h-entry:
* [https://mailpile.pagekite.me:8080/p/Open_Message_Format Mailpile Open Message Format] is using h-entry with structured properties, e.g. p-author h-card.

== Background ==
This work is based on the existing [[hAtom]] microformat, and extensive selfdogfooding in the [http://indiewebcamp.com 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 [[h-entry-issues|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|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|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_Additions|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|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|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 ==
* [[h-feed]]
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-geo]]
* [[hCard]]

[[Category:Specifications]]

h-entry

2021-08-20T04:36:51Z

Dshanske: /* Draft Properties */

{{DISPLAYTITLE:h-entry}}
<dfn style="font-style:normal;font-weight:bold">h-entry</dfn> 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 [[microformats|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]].

;<span id="status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [[h-entry-issues|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|change control]] process.
;<span id="participate">Participate</span>
:[https://github.com/microformats/h-entry/issues Open Issues]
:[[h-entry-issues|Resolved issues before 2012-246]]
:[[IRC]]
:Advance the spec by following explicit [[#change_control|change control]] process
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__

== Example ==
Here is a simple blog post example:

<source lang=html4strict>
<article class="h-entry">
<h1 class="p-name">Microformats are amazing</h1>
<p>Published by <a class="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></p>

<p class="p-summary">In which I extoll the virtues of using microformats.</p>

<div class="e-content">
<p>Blah blah blah</p>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"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>"
}
]
}
}
]
}
</source>

== Get started ==
The class '''<code>h-entry</code>''' 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 optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

=== Core Properties ===
The following ''core'' h-entry properties have broad consensus and are broadly interoperably published and consumed:
* '''<code>p-name</code>''' - entry name/title
* '''<code>p-summary</code>''' - short entry summary
* '''<code>e-content</code>''' - full content of the entry
* '''<code>dt-published</code>''' - when the entry was published
* '''<code>dt-updated</code>''' - when the entry was updated
* '''<code>p-author</code>''' - who wrote the entry, optionally embedded [[h-card]](s)
* '''<code>p-category</code>''' - entry categories/tags
* '''<code>u-url</code>''' - entry permalink URL
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical entry URL
* '''<code>p-location</code>''' - location the entry was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code id="u-syndication">u-syndication</code>''' - URL(s) of syndicated copies of this post. The property equivalent of [[rel-syndication]] ([http://erinjo.is/2014/checked-into-rockit-colabs-23 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]) ([https://kartikprabhu.com/notes/re-citizen-of-indieweb example])
* '''<code id="p-rsvp">p-rsvp</code>''' (enum, use <data> element or [[value-class-pattern]])
** "yes", "no", "maybe", "interested". Case-insensitive values, normalized to lowercase. Examples:
** <code><nowiki>... <data class="p-rsvp" value="YES">is going</data> to ...</nowiki></code>, or
** <code><nowiki>... <data class="p-rsvp" value="Maybe">might go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="no">unable to go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="iNtEreSTed">am interested/tracking/watching</data> ...</nowiki></code>
* '''<code id="u-like-of">u-like-of</code>''' - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded [[h-cite]]
* '''<code id="u-repost-of">u-repost-of</code>''' - the URL which the h-entry is considered a “repost” of. Optionally an embedded [[h-cite]].

=== 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 id="p-comment">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])
** [https://github.com/microformats/h-entry/issues/20 Issue 20]
* '''<code id="u-photo">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.
** [https://github.com/microformats/h-entry/issues/4 Issue 4: u-photo draft->core bc way more than 3+ pub and consuming impls/sites]
* '''<code id="u-video">u-video</code>''' - special u- parsing rules for <code><video src> & <source src></code>

=== 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 awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:
* '''<code>u-audio</code>''' - special u- parsing rules for <code><audio src> & <source src></code>. Examples: [http://transportini.com/ Transportini],[https://indieweb.org/podcast#How_to_podcast_with_h-feed possibly more]
* '''<code>u-like</code>''' - similar to p-comment, URL to a like post of the current post, e.g. in a responses list or facepile.
* '''<code>u-repost</code>''' - similar to u-like, URL to a repost of the current post, e.g. in a responses list or facepile.
* '''<code>u-bookmark-of</code>''' - indicates this h-entry is a bookmark of another URL. Optionally an [[h-cite]]. See [https://indieweb.org/bookmark indieweb.org/bookmark] for examples in the wild.
* '''<code>u-featured</code>''' - 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]].
** +1 sknebel: https://github.com/microformats/h-entry/issues/14
* '''<code>p-latitude</code>''' - latitude of the location of the entry
* '''<code>p-longitude</code>''' - longitude of the location of the entry
* '''<code>p-duration</code>''' - duration of an audio or video file in the entry. https://indieweb.org/duration Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>p-size</code>''' - size in bytes of an audio or video file in the entry. https://indieweb.org/size Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>u-listen-of</code>''' - also known as a 'scrobble', indicates this h-entry is a listen of another URL. Optionally an h-cite. https://github.com/microformats/h-entry/issues/11
* '''<code>u-watch-of</code>''' - indicates this h-entry is a watch of another URL, a visual version of the scrobble. Optionally an h-cite. https://github.com/microformats/h-entry/issues/17
* '''<code>p-read-of</code>''' - indicates this h-entry is a read post of some written work (book or other document). The value can be the title of the work or an h-cite. Proposal also mentions <code>u-read-of</code>, where the value would be a URL to the written work or a representative citation page. https://github.com/microformats/h-entry/issues/10
* '''<code>u-translation-of</code>''' - indicates this h-entry is a translation of the linked URL into another language. Can be used in the same way as the existing <code>u-like-of</code> and <code>u-repost-of</code> properties, with just the URL to the original h-entry, or (optionally) contain an embedded <code>h-cite</code>. https://github.com/microformats/h-entry/issues/26

The following interpretation is also proposed addition:
* if the <code>p-location</code> is also an embedded [[h-card]], the entry is treated as a "checkin".
** -1 [[User:Aaronpk|Aaronpk]] 14:22, 19 January 2017 (UTC) [https://aaronparecki.com/2017/01/13/21/ this post] is not a checkin, but has an h-card as the p-location property.

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: [[h-entry#change_control|change control]]

== Property Details ==
This section is a stub.
=== p-location ===
'''<code>p-location</code>''' has been re-used from [[h-event]].

== FAQ ==
=== p-name of a note ===
<div class="discussion">
* '''What is the <code>p-name</code> of a [https://indieweb.org/note note]?'''
** You probably should avoid adding <code>p-name</code> to notes. See https://indieweb.org/note for more discussion of the topic.
</div>

=== venue an entry was posted from ===
<div class="discussion">
* '''How do you indicate a named venue where an entry was posted from? Like a restaurant or park.'''
** Use an embedded [[h-card]] microformat on a <code>p-location</code> property value.
</div>

=== address an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== lat long an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== dt-published property and HTML5 time element ===
<div class="discussion">
* '''Does the dt-published property need to be a time element?'''
** The <code>dt-published</code> property should be a <code><time></code> 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.
</div>

=== what is the bare minimum list of required properties on an h-entry ===
<div class="discussion">
* 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:
</div>
* <code>url</code>
* <code>published</code> — if there is no "published" date for the "entry", then reconsider whether it is correct (or worth) marking it up as an entry.
<div class="discussion">
* 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:
</div>
* <code>content</code> (or <code>summary</code> at least) - especially for structured content. For a plain text note, the content/summary (whichever is used) should be the same as the <code>name</code>, otherwise it will be implied from the text content of the root element.
* <code>name</code> - for explicitly named/titled entries like blog posts and articles. Otherwise the entry is assumed to be a "title-less" [https://indieweb.org/note note] (like a tweet).
* <code>author</code> - including a nested <code>[[h-card]]</code> with author details like name, photo, url.

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

* ... add uses of h-entry you see in the wild here.
* ind.ie mark up their [https://ind.ie/blog blog] listing and [https://ind.ie/blog/autumn-events-2014/ permalink] pages with h-entry
* David John Mead marks up his profile, blog posts and comments with h-card, h-entry and h-cite on [http://davidjohnmead.com davidjohnmead.com]
* [[User:Brian|Brian Suda]] marks up his blog posts up with h-entry and h-card on [http://optional.is/required/ optional.is]
* Ashton McAllen marks up his blog posts, reposts, comments and likes with h-entry, h-card and h-cite on [http://acegiak.net/ acegiak.net]
* Emma Kuo marks up her blog posts and notes with h-entry and h-card on [http://notenoughneon.com/ notenoughneon.com]
* Scott Jenson marks up his blog posts with h-entry and h-card on [http://jenson.org/ jenson.org]
* Emily McAllen marks up her blog posts with h-entry and h-card on [http://blackwoolholiday.com/ blackwoolholiday.com]
* Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on [https://snarfed.org/ snarfed.org]
* Barry Frost marks up his notes with h-entry, h-card and h-cite on [http://barryfrost.com/ barryfrost.com]
* Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on [http://caseorganic.com/ caseorganic.com]
* Johannes Ernst marks up his blog posts with h-entry on [http://upon2020.com/blog/ upon2020.com]
* Michiel de Jong marks up his profile and notes with h-entry and h-card on [https://michielbdejong.com/ michielbdejong.com]
* Mike Taylor marks up his profile and blog posts with h-card and h-entry on [https://bear.im/bearlog/ bear.im]
* Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on [http://erinjo.is/ erinjo.is]
* Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on [https://jeena.net/ jeena.net]
* Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on [http://andysylvester.com/2014/03/01/howto-setting-up-the-selfoss-feed-reader-with-microformats-support/ andysylvester.com] (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --[[User:Barnabywalters|bw]] 14:44, 13 March 2014 (UTC))
* Chloe Weil marks up her blog posts with h-entry on [http://chloeweil.com/blog chloeweil.com]
* Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on [http://christopheducamp.com/ christopheducamp.com]
* Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on [http://glennjones.net/ glennjones.net]
* Marcus Povey marks up his blog posts and profile with h-entry and h-card on [http://www.marcus-povey.co.uk/ marcus-povey.co.uk]
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* Kyle Mahan marks up his profile and notes with h-card and h-entry on [http://kylewm.com/ kylewm.com]
* Okinawan-lyrics marks up his posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* App.net marks up profile pages and permalink pages with h-entry as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* The Twitter archive browser UI uses h-entry and h-card internally, unfortunately it’s not exposed as HTML in static files anywhere
* Brett Comnes marks up his posts with h-entry and h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like ([http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his posts up with h-card and h-entry, as well as draft u-in-reply-to and experimental u-like properties ([http://sandeep.io/101 example])
* Laurent Eschenauer marks up his posts with h-entry ([http://eschnou.com/entry/first-autonomous-flight-of-my-nodecopter-62-24992.html example])
* Tom Morris marks up his posts using h-entry ([http://tommorris.org/posts/8417 example])
* Numerous newer W3C specs, e.g.
** [http://www.w3.org/TR/2013/CR-css3-values-20130404/ CSS Values and Units Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/CR-css3-conditional-20130404/ CSS Conditional Rules Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/WD-css3-page-20130314/ CSS Paged Media Module Level 3 - 2013-03-14]
** [http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/ CSS Counter Styles Level 3 - 2013-02-21]
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry.
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Aaron Parecki uses h-entry to mark up notes, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-entry on his home page, as well as h-entry on all post permalinks, e.g. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], with [[rel-prev]]/[[rel-next]] (if applicable) to indicate prev/next posts
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-entry on all notes and articles, as well as nested within notes as reply contexts [http://waterpigs.co.uk/notes/1468/ example] and comments [http://waterpigs.co.uk/notes/1482/ example].

=== offline ===
* spreadly marks up share permalink pages with h-entry, as well as minimal h-cards and experimental p-like properties

== Validating ==
* '''[http://indiewebify.me/validate-h-entry/ indiewebify.me h-entry validator]''' parses [[h-entry]] markup, finds common errors and makes suggestions for things to add, with code samples
* '''[http://shrewdness.waterpigs.co.uk/test/ Shrewdness h-entry/h-feed validator]''' shows how shrewdness interprets+displays h-entries, with original source and interim formats, works for single h-entries and feed pages

{{h-spec-section-validating}}

== 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 [https://indieweb.org/ 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.
* [https://gnu.io/social/ GNUsocial] [https://git.gnu.io/gnu/gnu-social/ source code]
* [https://hubzilla.org/hubzilla/ Hubzilla] [https://github.org/redmatrix/hubzilla source code]
* [http://friendica.com/ Friendica] [https://github.org/friendica/friendica source code]
* [http://github.com/dissolve/inkblot InkBlot]
* ...

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

<source lang=html4strict>
<article class="h-entry hentry">
<h1 class="p-name entry-title">A Tale Of Two Tags</h1>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="e-content entry-content">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
<p>The a tag is perhaps the best of HTML, yet its corresponding invisible link tag has uses too.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>
</source>

{{note|Note: you may use any valid HTML5 elements. The <code>article h1 address time</code> elements are used in the example as semantically richer suggestions, however in general <code>div span</code> work fine too. The <code>time</code> element is special though in that its <code>datetime</code> 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: <code id="hentry">hentry</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

* <code>entry-title</code> - parse as '''<code>p-name</code>'''
* <code>entry-summary</code> - parse as '''<code>p-summary</code>'''
* <code>entry-content</code> - parse as '''<code>e-content</code>'''
* <code>published</code> - parse as '''dt-'''
* <code>updated</code> - parse as '''dt-'''
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>category</code>
* <code>rel=bookmark</code> - parse as '''<code>u-url</code>'''. While not a class name nor typical microformats property, rel=bookmark was the only way to indicate an hentry permalink. Thus parsers should look for rel=bookmark hyperlinks inside an hentry, and take their "href" value as a value for a '''<code>u-url</code>''' property, including handling any relative URL resolution.
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hentry. Thus parsers should look for rel=tag hyperlinks inside an hentry, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

Proposed: ([https://github.com/microformats/h-entry/issues/7 follow-up in issue #7])
* <code>time.entry-date[datetime]</code> - in the absence of <code>published</code>, parse as '''<code>dt-published</code>'''. parse for the first <code><time></code> element with class name of <code>entry-date</code> and non-empty <code>datetime</code> attribute inside an hentry, if there is no <code>published</code> property, use that time element's <code>datetime</code> attribute value for the <code>dt-published</code> property. Evidence: default WordPress themes 2011-2014([https://wp-themes.com/twentyeleven/][https://wp-themes.com/twentytwelve/][https://wp-themes.com/twentythirteen/][https://wp-themes.com/twentyfourteen/]).
* <code>rel=author</code> - in the absence of <code>author</code>, parse as '''<code>u-author</code>'''. While not a class name nor typical microformats property, rel=author was commonly used to link to an author's URL. Thus parsers should look for rel=author hyperlinks inside an hentry (or even on the same page, preceding the hentry), use the absolute version of it as a value for the '''<code>u-author</code>''' property if there is no "author" property. (citations to "hentry" examples in the wild that <em>depend</em> on rel=author needed to accepted this proposal. Note: default WordPress themes twentyeleven, twentytwelve, twentythirteen, twentyfourteen all use rel=author but only inside class="author vcard", and thus rel=author can be ignored since authorship is already picked up by existing <code>author</code> backcompat parsing.)

=== 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|rel=bookmark]]?''

A: tl;dr: use <code>class="u-url u-uid"</code> instead of <code>rel=bookmark</code> 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.

<nowiki>*</nowiki> even though rel=bookmark in particular is article-element / sectioning scoped in HTML5[http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-bookmark], 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 <code>entry-*</code> 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#Could_hAtom_instead_use_title_content_and_summary|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: [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-128 2012-08-30 IRC conversation].

== Related Work ==
Work that re-uses or builds upon h-entry:
* [https://mailpile.pagekite.me:8080/p/Open_Message_Format Mailpile Open Message Format] is using h-entry with structured properties, e.g. p-author h-card.

== Background ==
This work is based on the existing [[hAtom]] microformat, and extensive selfdogfooding in the [http://indiewebcamp.com 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 [[h-entry-issues|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|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|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_Additions|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|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|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 ==
* [[h-feed]]
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-geo]]
* [[hCard]]

[[Category:Specifications]]

h-entry

2021-08-20T04:36:16Z

Dshanske: /* Draft Properties */

{{DISPLAYTITLE:h-entry}}
<dfn style="font-style:normal;font-weight:bold">h-entry</dfn> 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 [[microformats|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]].

;<span id="status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [[h-entry-issues|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|change control]] process.
;<span id="participate">Participate</span>
:[https://github.com/microformats/h-entry/issues Open Issues]
:[[h-entry-issues|Resolved issues before 2012-246]]
:[[IRC]]
:Advance the spec by following explicit [[#change_control|change control]] process
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__

== Example ==
Here is a simple blog post example:

<source lang=html4strict>
<article class="h-entry">
<h1 class="p-name">Microformats are amazing</h1>
<p>Published by <a class="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></p>

<p class="p-summary">In which I extoll the virtues of using microformats.</p>

<div class="e-content">
<p>Blah blah blah</p>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"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>"
}
]
}
}
]
}
</source>

== Get started ==
The class '''<code>h-entry</code>''' 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 optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

=== Core Properties ===
The following ''core'' h-entry properties have broad consensus and are broadly interoperably published and consumed:
* '''<code>p-name</code>''' - entry name/title
* '''<code>p-summary</code>''' - short entry summary
* '''<code>e-content</code>''' - full content of the entry
* '''<code>dt-published</code>''' - when the entry was published
* '''<code>dt-updated</code>''' - when the entry was updated
* '''<code>p-author</code>''' - who wrote the entry, optionally embedded [[h-card]](s)
* '''<code>p-category</code>''' - entry categories/tags
* '''<code>u-url</code>''' - entry permalink URL
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical entry URL
* '''<code>p-location</code>''' - location the entry was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code id="u-syndication">u-syndication</code>''' - URL(s) of syndicated copies of this post. The property equivalent of [[rel-syndication]] ([http://erinjo.is/2014/checked-into-rockit-colabs-23 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]) ([https://kartikprabhu.com/notes/re-citizen-of-indieweb example])
* '''<code id="p-rsvp">p-rsvp</code>''' (enum, use <data> element or [[value-class-pattern]])
** "yes", "no", "maybe", "interested". Case-insensitive values, normalized to lowercase. Examples:
** <code><nowiki>... <data class="p-rsvp" value="YES">is going</data> to ...</nowiki></code>, or
** <code><nowiki>... <data class="p-rsvp" value="Maybe">might go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="no">unable to go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="iNtEreSTed">am interested/tracking/watching</data> ...</nowiki></code>
* '''<code id="u-like-of">u-like-of</code>''' - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded [[h-cite]]
* '''<code id="u-repost-of">u-repost-of</code>''' - the URL which the h-entry is considered a “repost” of. Optionally an embedded [[h-cite]].

=== 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 id="p-comment">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])
** [https://github.com/microformats/h-entry/issues/20 Discussion]
* '''<code id="u-photo">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.
** [https://github.com/microformats/h-entry/issues/4 Issue 4: u-photo draft->core bc way more than 3+ pub and consuming impls/sites]
* '''<code id="u-video">u-video</code>''' - special u- parsing rules for <code><video src> & <source src></code>

=== 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 awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:
* '''<code>u-audio</code>''' - special u- parsing rules for <code><audio src> & <source src></code>. Examples: [http://transportini.com/ Transportini],[https://indieweb.org/podcast#How_to_podcast_with_h-feed possibly more]
* '''<code>u-like</code>''' - similar to p-comment, URL to a like post of the current post, e.g. in a responses list or facepile.
* '''<code>u-repost</code>''' - similar to u-like, URL to a repost of the current post, e.g. in a responses list or facepile.
* '''<code>u-bookmark-of</code>''' - indicates this h-entry is a bookmark of another URL. Optionally an [[h-cite]]. See [https://indieweb.org/bookmark indieweb.org/bookmark] for examples in the wild.
* '''<code>u-featured</code>''' - 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]].
** +1 sknebel: https://github.com/microformats/h-entry/issues/14
* '''<code>p-latitude</code>''' - latitude of the location of the entry
* '''<code>p-longitude</code>''' - longitude of the location of the entry
* '''<code>p-duration</code>''' - duration of an audio or video file in the entry. https://indieweb.org/duration Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>p-size</code>''' - size in bytes of an audio or video file in the entry. https://indieweb.org/size Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>u-listen-of</code>''' - also known as a 'scrobble', indicates this h-entry is a listen of another URL. Optionally an h-cite. https://github.com/microformats/h-entry/issues/11
* '''<code>u-watch-of</code>''' - indicates this h-entry is a watch of another URL, a visual version of the scrobble. Optionally an h-cite. https://github.com/microformats/h-entry/issues/17
* '''<code>p-read-of</code>''' - indicates this h-entry is a read post of some written work (book or other document). The value can be the title of the work or an h-cite. Proposal also mentions <code>u-read-of</code>, where the value would be a URL to the written work or a representative citation page. https://github.com/microformats/h-entry/issues/10
* '''<code>u-translation-of</code>''' - indicates this h-entry is a translation of the linked URL into another language. Can be used in the same way as the existing <code>u-like-of</code> and <code>u-repost-of</code> properties, with just the URL to the original h-entry, or (optionally) contain an embedded <code>h-cite</code>. https://github.com/microformats/h-entry/issues/26

The following interpretation is also proposed addition:
* if the <code>p-location</code> is also an embedded [[h-card]], the entry is treated as a "checkin".
** -1 [[User:Aaronpk|Aaronpk]] 14:22, 19 January 2017 (UTC) [https://aaronparecki.com/2017/01/13/21/ this post] is not a checkin, but has an h-card as the p-location property.

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: [[h-entry#change_control|change control]]

== Property Details ==
This section is a stub.
=== p-location ===
'''<code>p-location</code>''' has been re-used from [[h-event]].

== FAQ ==
=== p-name of a note ===
<div class="discussion">
* '''What is the <code>p-name</code> of a [https://indieweb.org/note note]?'''
** You probably should avoid adding <code>p-name</code> to notes. See https://indieweb.org/note for more discussion of the topic.
</div>

=== venue an entry was posted from ===
<div class="discussion">
* '''How do you indicate a named venue where an entry was posted from? Like a restaurant or park.'''
** Use an embedded [[h-card]] microformat on a <code>p-location</code> property value.
</div>

=== address an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== lat long an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== dt-published property and HTML5 time element ===
<div class="discussion">
* '''Does the dt-published property need to be a time element?'''
** The <code>dt-published</code> property should be a <code><time></code> 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.
</div>

=== what is the bare minimum list of required properties on an h-entry ===
<div class="discussion">
* 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:
</div>
* <code>url</code>
* <code>published</code> — if there is no "published" date for the "entry", then reconsider whether it is correct (or worth) marking it up as an entry.
<div class="discussion">
* 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:
</div>
* <code>content</code> (or <code>summary</code> at least) - especially for structured content. For a plain text note, the content/summary (whichever is used) should be the same as the <code>name</code>, otherwise it will be implied from the text content of the root element.
* <code>name</code> - for explicitly named/titled entries like blog posts and articles. Otherwise the entry is assumed to be a "title-less" [https://indieweb.org/note note] (like a tweet).
* <code>author</code> - including a nested <code>[[h-card]]</code> with author details like name, photo, url.

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

* ... add uses of h-entry you see in the wild here.
* ind.ie mark up their [https://ind.ie/blog blog] listing and [https://ind.ie/blog/autumn-events-2014/ permalink] pages with h-entry
* David John Mead marks up his profile, blog posts and comments with h-card, h-entry and h-cite on [http://davidjohnmead.com davidjohnmead.com]
* [[User:Brian|Brian Suda]] marks up his blog posts up with h-entry and h-card on [http://optional.is/required/ optional.is]
* Ashton McAllen marks up his blog posts, reposts, comments and likes with h-entry, h-card and h-cite on [http://acegiak.net/ acegiak.net]
* Emma Kuo marks up her blog posts and notes with h-entry and h-card on [http://notenoughneon.com/ notenoughneon.com]
* Scott Jenson marks up his blog posts with h-entry and h-card on [http://jenson.org/ jenson.org]
* Emily McAllen marks up her blog posts with h-entry and h-card on [http://blackwoolholiday.com/ blackwoolholiday.com]
* Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on [https://snarfed.org/ snarfed.org]
* Barry Frost marks up his notes with h-entry, h-card and h-cite on [http://barryfrost.com/ barryfrost.com]
* Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on [http://caseorganic.com/ caseorganic.com]
* Johannes Ernst marks up his blog posts with h-entry on [http://upon2020.com/blog/ upon2020.com]
* Michiel de Jong marks up his profile and notes with h-entry and h-card on [https://michielbdejong.com/ michielbdejong.com]
* Mike Taylor marks up his profile and blog posts with h-card and h-entry on [https://bear.im/bearlog/ bear.im]
* Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on [http://erinjo.is/ erinjo.is]
* Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on [https://jeena.net/ jeena.net]
* Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on [http://andysylvester.com/2014/03/01/howto-setting-up-the-selfoss-feed-reader-with-microformats-support/ andysylvester.com] (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --[[User:Barnabywalters|bw]] 14:44, 13 March 2014 (UTC))
* Chloe Weil marks up her blog posts with h-entry on [http://chloeweil.com/blog chloeweil.com]
* Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on [http://christopheducamp.com/ christopheducamp.com]
* Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on [http://glennjones.net/ glennjones.net]
* Marcus Povey marks up his blog posts and profile with h-entry and h-card on [http://www.marcus-povey.co.uk/ marcus-povey.co.uk]
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* Kyle Mahan marks up his profile and notes with h-card and h-entry on [http://kylewm.com/ kylewm.com]
* Okinawan-lyrics marks up his posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* App.net marks up profile pages and permalink pages with h-entry as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* The Twitter archive browser UI uses h-entry and h-card internally, unfortunately it’s not exposed as HTML in static files anywhere
* Brett Comnes marks up his posts with h-entry and h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like ([http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his posts up with h-card and h-entry, as well as draft u-in-reply-to and experimental u-like properties ([http://sandeep.io/101 example])
* Laurent Eschenauer marks up his posts with h-entry ([http://eschnou.com/entry/first-autonomous-flight-of-my-nodecopter-62-24992.html example])
* Tom Morris marks up his posts using h-entry ([http://tommorris.org/posts/8417 example])
* Numerous newer W3C specs, e.g.
** [http://www.w3.org/TR/2013/CR-css3-values-20130404/ CSS Values and Units Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/CR-css3-conditional-20130404/ CSS Conditional Rules Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/WD-css3-page-20130314/ CSS Paged Media Module Level 3 - 2013-03-14]
** [http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/ CSS Counter Styles Level 3 - 2013-02-21]
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry.
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Aaron Parecki uses h-entry to mark up notes, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-entry on his home page, as well as h-entry on all post permalinks, e.g. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], with [[rel-prev]]/[[rel-next]] (if applicable) to indicate prev/next posts
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-entry on all notes and articles, as well as nested within notes as reply contexts [http://waterpigs.co.uk/notes/1468/ example] and comments [http://waterpigs.co.uk/notes/1482/ example].

=== offline ===
* spreadly marks up share permalink pages with h-entry, as well as minimal h-cards and experimental p-like properties

== Validating ==
* '''[http://indiewebify.me/validate-h-entry/ indiewebify.me h-entry validator]''' parses [[h-entry]] markup, finds common errors and makes suggestions for things to add, with code samples
* '''[http://shrewdness.waterpigs.co.uk/test/ Shrewdness h-entry/h-feed validator]''' shows how shrewdness interprets+displays h-entries, with original source and interim formats, works for single h-entries and feed pages

{{h-spec-section-validating}}

== 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 [https://indieweb.org/ 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.
* [https://gnu.io/social/ GNUsocial] [https://git.gnu.io/gnu/gnu-social/ source code]
* [https://hubzilla.org/hubzilla/ Hubzilla] [https://github.org/redmatrix/hubzilla source code]
* [http://friendica.com/ Friendica] [https://github.org/friendica/friendica source code]
* [http://github.com/dissolve/inkblot InkBlot]
* ...

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

<source lang=html4strict>
<article class="h-entry hentry">
<h1 class="p-name entry-title">A Tale Of Two Tags</h1>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="e-content entry-content">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
<p>The a tag is perhaps the best of HTML, yet its corresponding invisible link tag has uses too.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>
</source>

{{note|Note: you may use any valid HTML5 elements. The <code>article h1 address time</code> elements are used in the example as semantically richer suggestions, however in general <code>div span</code> work fine too. The <code>time</code> element is special though in that its <code>datetime</code> 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: <code id="hentry">hentry</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

* <code>entry-title</code> - parse as '''<code>p-name</code>'''
* <code>entry-summary</code> - parse as '''<code>p-summary</code>'''
* <code>entry-content</code> - parse as '''<code>e-content</code>'''
* <code>published</code> - parse as '''dt-'''
* <code>updated</code> - parse as '''dt-'''
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>category</code>
* <code>rel=bookmark</code> - parse as '''<code>u-url</code>'''. While not a class name nor typical microformats property, rel=bookmark was the only way to indicate an hentry permalink. Thus parsers should look for rel=bookmark hyperlinks inside an hentry, and take their "href" value as a value for a '''<code>u-url</code>''' property, including handling any relative URL resolution.
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hentry. Thus parsers should look for rel=tag hyperlinks inside an hentry, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

Proposed: ([https://github.com/microformats/h-entry/issues/7 follow-up in issue #7])
* <code>time.entry-date[datetime]</code> - in the absence of <code>published</code>, parse as '''<code>dt-published</code>'''. parse for the first <code><time></code> element with class name of <code>entry-date</code> and non-empty <code>datetime</code> attribute inside an hentry, if there is no <code>published</code> property, use that time element's <code>datetime</code> attribute value for the <code>dt-published</code> property. Evidence: default WordPress themes 2011-2014([https://wp-themes.com/twentyeleven/][https://wp-themes.com/twentytwelve/][https://wp-themes.com/twentythirteen/][https://wp-themes.com/twentyfourteen/]).
* <code>rel=author</code> - in the absence of <code>author</code>, parse as '''<code>u-author</code>'''. While not a class name nor typical microformats property, rel=author was commonly used to link to an author's URL. Thus parsers should look for rel=author hyperlinks inside an hentry (or even on the same page, preceding the hentry), use the absolute version of it as a value for the '''<code>u-author</code>''' property if there is no "author" property. (citations to "hentry" examples in the wild that <em>depend</em> on rel=author needed to accepted this proposal. Note: default WordPress themes twentyeleven, twentytwelve, twentythirteen, twentyfourteen all use rel=author but only inside class="author vcard", and thus rel=author can be ignored since authorship is already picked up by existing <code>author</code> backcompat parsing.)

=== 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|rel=bookmark]]?''

A: tl;dr: use <code>class="u-url u-uid"</code> instead of <code>rel=bookmark</code> 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.

<nowiki>*</nowiki> even though rel=bookmark in particular is article-element / sectioning scoped in HTML5[http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-bookmark], 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 <code>entry-*</code> 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#Could_hAtom_instead_use_title_content_and_summary|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: [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-128 2012-08-30 IRC conversation].

== Related Work ==
Work that re-uses or builds upon h-entry:
* [https://mailpile.pagekite.me:8080/p/Open_Message_Format Mailpile Open Message Format] is using h-entry with structured properties, e.g. p-author h-card.

== Background ==
This work is based on the existing [[hAtom]] microformat, and extensive selfdogfooding in the [http://indiewebcamp.com 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 [[h-entry-issues|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|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|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_Additions|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|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|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 ==
* [[h-feed]]
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-geo]]
* [[hCard]]

[[Category:Specifications]]

h-entry

2020-09-12T05:02:17Z

Dshanske: /* Proposed Additions */

{{DISPLAYTITLE:h-entry}}
<dfn style="font-style:normal;font-weight:bold">h-entry</dfn> 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 [[microformats|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]].

;<span id="Status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [[h-entry-issues|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|change control]] process.
;Participate
:[https://github.com/microformats/h-entry/issues Open Issues]
:[[h-entry-issues|Resolved issues before 2012-246]]
:[[IRC]]: [irc://irc.freenode.net/microformats #microformats on Freenode]
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__

== Example ==
Here is a simple blog post example:

<source lang=html4strict>
<article class="h-entry">
<h1 class="p-name">Microformats are amazing</h1>
<p>Published by <a class="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></p>

<p class="p-summary">In which I extoll the virtues of using microformats.</p>

<div class="e-content">
<p>Blah blah blah</p>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"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>"
}
]
}
}
]
}
</source>

== Get started ==
The class '''<code>h-entry</code>''' 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 optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

=== Core Properties ===
The following ''core'' h-entry properties have broad consensus and are broadly interoperably published and consumed:
* '''<code>p-name</code>''' - entry name/title
* '''<code>p-summary</code>''' - short entry summary
* '''<code>e-content</code>''' - full content of the entry
* '''<code>dt-published</code>''' - when the entry was published
* '''<code>dt-updated</code>''' - when the entry was updated
* '''<code>p-author</code>''' - who wrote the entry, optionally embedded [[h-card]](s)
* '''<code>p-category</code>''' - entry categories/tags
* '''<code>u-url</code>''' - entry permalink URL
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical entry URL
* '''<code>p-location</code>''' - location the entry was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code>u-syndication</code>''' - URL(s) of syndicated copies of this post. The property equivalent of [[rel-syndication]] ([http://erinjo.is/2014/checked-into-rockit-colabs-23 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]) ([https://kartikprabhu.com/notes/re-citizen-of-indieweb example])
* '''<code id="p-rsvp">p-rsvp</code>''' (enum, use <data> element or [[value-class-pattern]])
** "yes", "no", "maybe", "interested". Case-insensitive values, normalized to lowercase. Examples:
** <code><nowiki>... <data class="p-rsvp" value="YES">is going</data> to ...</nowiki></code>, or
** <code><nowiki>... <data class="p-rsvp" value="Maybe">might go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="no">unable to go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="iNtEreSTed">am interested/tracking/watching</data> ...</nowiki></code>
* '''<code id="u-like-of">u-like-of</code>''' - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded [[h-cite]]
* '''<code id="u-repost-of">u-repost-of</code>''' - the URL which the h-entry is considered a “repost” of. Optionally an embedded [[h-cite]].

=== 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 id="p-comment">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 id="u-photo">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.
** [https://github.com/microformats/h-entry/issues/4 Issue 4: u-photo draft->core bc way more than 3+ pub and consuming impls/sites]
* '''<code id="u-video">u-video</code>''' - special u- parsing rules for <code><video src> & <source src></code>

=== 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 awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:
* '''<code>u-audio</code>''' - special u- parsing rules for <code><audio src> & <source src></code>. Examples: [http://transportini.com/ Transportini],[https://indieweb.org/podcast#How_to_podcast_with_h-feed possibly more]
* '''<code>u-like</code>''' - similar to p-comment, URL to a like post of the current post, e.g. in a responses list or facepile.
* '''<code>u-repost</code>''' - similar to u-like, URL to a repost of the current post, e.g. in a responses list or facepile.
* '''<code>u-bookmark-of</code>''' - indicates this h-entry is a bookmark of another URL. Optionally an [[h-cite]]. See [https://indieweb.org/bookmark indieweb.org/bookmark] for examples in the wild.
* '''<code>u-featured</code>''' - 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]].
** +1 sknebel: https://github.com/microformats/h-entry/issues/14
* '''<code>p-latitude</code>''' - latitude of the location of the entry
* '''<code>p-longitude</code>''' - longitude of the location of the entry
* '''<code>p-duration</code>''' - duration of an audio or video file in the entry. https://indieweb.org/duration Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>p-size</code>''' - size in bytes of an audio or video file in the entry. https://indieweb.org/size Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>u-listen-of</code>''' - also known as a 'scrobble', indicates this h-entry is a listen of another URL. Optionally an h-cite. https://github.com/microformats/h-entry/issues/11
* '''<code>u-watch-of</code>''' - indicates this h-entry is a watch of another URL, a visual version of the scrobble. Optionally an h-cite. https://github.com/microformats/h-entry/issues/17
* '''<code>p-read-of</code>''' - indicates this h-entry is a read post of some written work (book or other document). The value can be the title of the work or an h-cite. Proposal also mentions u-read-of, where the value would be a URL to the written work or a representative citation page. https://github.com/microformats/h-entry/issues/10

The following interpretation is also proposed addition:
* if the <code>p-location</code> is also an embedded [[h-card]], the entry is treated as a "checkin".
** -1 [[User:Aaronpk|Aaronpk]] 14:22, 19 January 2017 (UTC) [https://aaronparecki.com/2017/01/13/21/ this post] is not a checkin, but has an h-card as the p-location property.

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: [[h-entry#change_control|change control]]

== Property Details ==
This section is a stub.
=== p-location ===
'''<code>p-location</code>''' has been re-used from [[h-event]].

== FAQ ==
=== p-name of a note ===
<div class="discussion">
* '''What is the <code>p-name</code> of a [https://indieweb.org/note note]?'''
** You probably should avoid adding <code>p-name</code> to notes. See https://indieweb.org/note for more discussion of the topic.
</div>

=== venue an entry was posted from ===
<div class="discussion">
* '''How do you indicate a named venue where an entry was posted from? Like a restaurant or park.'''
** Use an embedded [[h-card]] microformat on a <code>p-location</code> property value.
</div>

=== address an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== lat long an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== dt-published property and HTML5 time element ===
<div class="discussion">
* '''Does the dt-published property need to be a time element?'''
** The <code>dt-published</code> property should be a <code><time></code> 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.
</div>

=== what is the bare minimum list of required properties on an h-entry ===
<div class="discussion">
* 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:
</div>
* <code>url</code>
* <code>published</code> — if there is no "published" date for the "entry", then reconsider whether it is correct (or worth) marking it up as an entry.
<div class="discussion">
* 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:
</div>
* <code>content</code> (or <code>summary</code> at least) - especially for structured content. For a plain text note, the content/summary (whichever is used) should be the same as the <code>name</code>, otherwise it will be implied from the text content of the root element.
* <code>name</code> - for explicitly named/titled entries like blog posts and articles. Otherwise the entry is assumed to be a "title-less" [https://indieweb.org/note note] (like a tweet).
* <code>author</code> - including a nested <code>[[h-card]]</code> with author details like name, photo, url.

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

* ... add uses of h-entry you see in the wild here.
* ind.ie mark up their [https://ind.ie/blog blog] listing and [https://ind.ie/blog/autumn-events-2014/ permalink] pages with h-entry
* David John Mead marks up his profile, blog posts and comments with h-card, h-entry and h-cite on [http://davidjohnmead.com davidjohnmead.com]
* [[User:Brian|Brian Suda]] marks up his blog posts up with h-entry and h-card on [http://optional.is/required/ optional.is]
* Ashton McAllen marks up his blog posts, reposts, comments and likes with h-entry, h-card and h-cite on [http://acegiak.net/ acegiak.net]
* Emma Kuo marks up her blog posts and notes with h-entry and h-card on [http://notenoughneon.com/ notenoughneon.com]
* Scott Jenson marks up his blog posts with h-entry and h-card on [http://jenson.org/ jenson.org]
* Emily McAllen marks up her blog posts with h-entry and h-card on [http://blackwoolholiday.com/ blackwoolholiday.com]
* Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on [https://snarfed.org/ snarfed.org]
* Barry Frost marks up his notes with h-entry, h-card and h-cite on [http://barryfrost.com/ barryfrost.com]
* Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on [http://caseorganic.com/ caseorganic.com]
* Johannes Ernst marks up his blog posts with h-entry on [http://upon2020.com/blog/ upon2020.com]
* Michiel de Jong marks up his profile and notes with h-entry and h-card on [https://michielbdejong.com/ michielbdejong.com]
* Mike Taylor marks up his profile and blog posts with h-card and h-entry on [https://bear.im/bearlog/ bear.im]
* Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on [http://erinjo.is/ erinjo.is]
* Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on [https://jeena.net/ jeena.net]
* Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on [http://andysylvester.com/2014/03/01/howto-setting-up-the-selfoss-feed-reader-with-microformats-support/ andysylvester.com] (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --[[User:Barnabywalters|bw]] 14:44, 13 March 2014 (UTC))
* Chloe Weil marks up her blog posts with h-entry on [http://chloeweil.com/blog chloeweil.com]
* Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on [http://christopheducamp.com/ christopheducamp.com]
* Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on [http://glennjones.net/ glennjones.net]
* Marcus Povey marks up his blog posts and profile with h-entry and h-card on [http://www.marcus-povey.co.uk/ marcus-povey.co.uk]
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* Kyle Mahan marks up his profile and notes with h-card and h-entry on [http://kylewm.com/ kylewm.com]
* Okinawan-lyrics marks up his posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* App.net marks up profile pages and permalink pages with h-entry as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* The Twitter archive browser UI uses h-entry and h-card internally, unfortunately it’s not exposed as HTML in static files anywhere
* Brett Comnes marks up his posts with h-entry and h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like ([http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his posts up with h-card and h-entry, as well as draft u-in-reply-to and experimental u-like properties ([http://sandeep.io/101 example])
* Laurent Eschenauer marks up his posts with h-entry ([http://eschnou.com/entry/first-autonomous-flight-of-my-nodecopter-62-24992.html example])
* Tom Morris marks up his posts using h-entry ([http://tommorris.org/posts/8417 example])
* Numerous newer W3C specs, e.g.
** [http://www.w3.org/TR/2013/CR-css3-values-20130404/ CSS Values and Units Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/CR-css3-conditional-20130404/ CSS Conditional Rules Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/WD-css3-page-20130314/ CSS Paged Media Module Level 3 - 2013-03-14]
** [http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/ CSS Counter Styles Level 3 - 2013-02-21]
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry.
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Aaron Parecki uses h-entry to mark up notes, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-entry on his home page, as well as h-entry on all post permalinks, e.g. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], with [[rel-prev]]/[[rel-next]] (if applicable) to indicate prev/next posts
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-entry on all notes and articles, as well as nested within notes as reply contexts [http://waterpigs.co.uk/notes/1468/ example] and comments [http://waterpigs.co.uk/notes/1482/ example].

=== offline ===
* spreadly marks up share permalink pages with h-entry, as well as minimal h-cards and experimental p-like properties

== Validating ==
* '''[http://indiewebify.me/validate-h-entry/ indiewebify.me h-entry validator]''' parses [[h-entry]] markup, finds common errors and makes suggestions for things to add, with code samples
* '''[http://shrewdness.waterpigs.co.uk/test/ Shrewdness h-entry/h-feed validator]''' shows how shrewdness interprets+displays h-entries, with original source and interim formats, works for single h-entries and feed pages

{{h-spec-section-validating}}

== 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 [https://indieweb.org/ 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.
* [https://gnu.io/social/ GNUsocial] [https://git.gnu.io/gnu/gnu-social/ source code]
* [https://hubzilla.org/hubzilla/ Hubzilla] [https://github.org/redmatrix/hubzilla source code]
* [http://friendica.com/ Friendica] [https://github.org/friendica/friendica source code]
* [http://github.com/dissolve/inkblot InkBlot]
* ...

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

<source lang=html4strict>
<article class="h-entry hentry">
<h1 class="p-name entry-title">A Tale Of Two Tags</h1>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="e-content entry-content">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
<p>The a tag is perhaps the best of HTML, yet its corresponding invisible link tag has uses too.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>
</source>

{{note|Note: you may use any valid HTML5 elements. The <code>article h1 address time</code> elements are used in the example as semantically richer suggestions, however in general <code>div span</code> work fine too. The <code>time</code> element is special though in that its <code>datetime</code> 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: <code id="hentry">hentry</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

* <code>entry-title</code> - parse as '''<code>p-name</code>'''
* <code>entry-summary</code> - parse as '''<code>p-summary</code>'''
* <code>entry-content</code> - parse as '''<code>e-content</code>'''
* <code>published</code> - parse as '''dt-'''
* <code>updated</code> - parse as '''dt-'''
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>category</code>
* <code>rel=bookmark</code> - parse as '''<code>u-url</code>'''. While not a class name nor typical microformats property, rel=bookmark was the only way to indicate an hentry permalink. Thus parsers should look for rel=bookmark hyperlinks inside an hentry, and take their "href" value as a value for a '''<code>u-url</code>''' property, including handling any relative URL resolution.
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hentry. Thus parsers should look for rel=tag hyperlinks inside an hentry, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

Proposed: ([https://github.com/microformats/h-entry/issues/7 follow-up in issue #7])
* <code>time.entry-date[datetime]</code> - in the absence of <code>published</code>, parse as '''<code>dt-published</code>'''. parse for the first <code><time></code> element with class name of <code>entry-date</code> and non-empty <code>datetime</code> attribute inside an hentry, if there is no <code>published</code> property, use that time element's <code>datetime</code> attribute value for the <code>dt-published</code> property. Evidence: default WordPress themes 2011-2014([https://wp-themes.com/twentyeleven/][https://wp-themes.com/twentytwelve/][https://wp-themes.com/twentythirteen/][https://wp-themes.com/twentyfourteen/]).
* <code>rel=author</code> - in the absence of <code>author</code>, parse as '''<code>u-author</code>'''. While not a class name nor typical microformats property, rel=author was commonly used to link to an author's URL. Thus parsers should look for rel=author hyperlinks inside an hentry (or even on the same page, preceding the hentry), use the absolute version of it as a value for the '''<code>u-author</code>''' property if there is no "author" property. (citations to "hentry" examples in the wild that <em>depend</em> on rel=author needed to accepted this proposal. Note: default WordPress themes twentyeleven, twentytwelve, twentythirteen, twentyfourteen all use rel=author but only inside class="author vcard", and thus rel=author can be ignored since authorship is already picked up by existing <code>author</code> backcompat parsing.)

=== 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|rel=bookmark]]?''

A: tl;dr: use <code>class="u-url u-uid"</code> instead of <code>rel=bookmark</code> 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.

<nowiki>*</nowiki> even though rel=bookmark in particular is article-element / sectioning scoped in HTML5[http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-bookmark], 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 <code>entry-*</code> 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#Could_hAtom_instead_use_title_content_and_summary|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: [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-128 2012-08-30 IRC conversation].

== Related Work ==
Work that re-uses or builds upon h-entry:
* [https://mailpile.pagekite.me:8080/p/Open_Message_Format Mailpile Open Message Format] is using h-entry with structured properties, e.g. p-author h-card.

== Background ==
This work is based on the existing [[hAtom]] microformat, and extensive selfdogfooding in the [http://indiewebcamp.com 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 [[h-entry-issues|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|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|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_Additions|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|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|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 ==
* [[h-feed]]
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-geo]]
* [[hCard]]

[[Category:Specifications]]

h-entry

2020-09-12T05:00:01Z

Dshanske: /* Proposed Additions */

{{DISPLAYTITLE:h-entry}}
<dfn style="font-style:normal;font-weight:bold">h-entry</dfn> 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 [[microformats|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]].

;<span id="Status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [[h-entry-issues|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|change control]] process.
;Participate
:[https://github.com/microformats/h-entry/issues Open Issues]
:[[h-entry-issues|Resolved issues before 2012-246]]
:[[IRC]]: [irc://irc.freenode.net/microformats #microformats on Freenode]
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__

== Example ==
Here is a simple blog post example:

<source lang=html4strict>
<article class="h-entry">
<h1 class="p-name">Microformats are amazing</h1>
<p>Published by <a class="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></p>

<p class="p-summary">In which I extoll the virtues of using microformats.</p>

<div class="e-content">
<p>Blah blah blah</p>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"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>"
}
]
}
}
]
}
</source>

== Get started ==
The class '''<code>h-entry</code>''' 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 optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

=== Core Properties ===
The following ''core'' h-entry properties have broad consensus and are broadly interoperably published and consumed:
* '''<code>p-name</code>''' - entry name/title
* '''<code>p-summary</code>''' - short entry summary
* '''<code>e-content</code>''' - full content of the entry
* '''<code>dt-published</code>''' - when the entry was published
* '''<code>dt-updated</code>''' - when the entry was updated
* '''<code>p-author</code>''' - who wrote the entry, optionally embedded [[h-card]](s)
* '''<code>p-category</code>''' - entry categories/tags
* '''<code>u-url</code>''' - entry permalink URL
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical entry URL
* '''<code>p-location</code>''' - location the entry was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code>u-syndication</code>''' - URL(s) of syndicated copies of this post. The property equivalent of [[rel-syndication]] ([http://erinjo.is/2014/checked-into-rockit-colabs-23 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]) ([https://kartikprabhu.com/notes/re-citizen-of-indieweb example])
* '''<code id="p-rsvp">p-rsvp</code>''' (enum, use <data> element or [[value-class-pattern]])
** "yes", "no", "maybe", "interested". Case-insensitive values, normalized to lowercase. Examples:
** <code><nowiki>... <data class="p-rsvp" value="YES">is going</data> to ...</nowiki></code>, or
** <code><nowiki>... <data class="p-rsvp" value="Maybe">might go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="no">unable to go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="iNtEreSTed">am interested/tracking/watching</data> ...</nowiki></code>
* '''<code id="u-like-of">u-like-of</code>''' - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded [[h-cite]]
* '''<code id="u-repost-of">u-repost-of</code>''' - the URL which the h-entry is considered a “repost” of. Optionally an embedded [[h-cite]].

=== 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 id="p-comment">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 id="u-photo">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.
** [https://github.com/microformats/h-entry/issues/4 Issue 4: u-photo draft->core bc way more than 3+ pub and consuming impls/sites]
* '''<code id="u-video">u-video</code>''' - special u- parsing rules for <code><video src> & <source src></code>

=== 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 awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:
* '''<code>u-audio</code>''' - special u- parsing rules for <code><audio src> & <source src></code>. Examples: [http://transportini.com/ Transportini],[https://indieweb.org/podcast#How_to_podcast_with_h-feed possibly more]
* '''<code>u-like</code>''' - similar to p-comment, URL to a like post of the current post, e.g. in a responses list or facepile.
* '''<code>u-repost</code>''' - similar to u-like, URL to a repost of the current post, e.g. in a responses list or facepile.
* '''<code>u-bookmark-of</code>''' - indicates this h-entry is a bookmark of another URL. Optionally an [[h-cite]]. See [https://indieweb.org/bookmark indieweb.org/bookmark] for examples in the wild.
* '''<code>u-featured</code>''' - 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]].
** +1 sknebel: https://github.com/microformats/h-entry/issues/14
* '''<code>p-latitude</code>''' - latitude of the location of the entry
* '''<code>p-longitude</code>''' - longitude of the location of the entry
* '''<code>p-duration</code>''' - duration of an audio or video file in the entry. https://indieweb.org/duration Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>p-size</code>''' - size in bytes of an audio or video file in the entry. https://indieweb.org/size Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>u-listen-of</code>''' - also known as a 'scrobble', indicates this h-entry is a listen of another URL. Optionally an h-cite. https://github.com/microformats/h-entry/issues/11
* '''<code>p-read-of</code>''' - indicates this h-entry is a read post of some written work (book or other document). The value can be the title of the work or an h-cite. Proposal also mentions u-read-of, where the value would be a URL to the written work or a representative citation page. https://github.com/microformats/h-entry/issues/10

The following interpretation is also proposed addition:
* if the <code>p-location</code> is also an embedded [[h-card]], the entry is treated as a "checkin".
** -1 [[User:Aaronpk|Aaronpk]] 14:22, 19 January 2017 (UTC) [https://aaronparecki.com/2017/01/13/21/ this post] is not a checkin, but has an h-card as the p-location property.

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: [[h-entry#change_control|change control]]

== Property Details ==
This section is a stub.
=== p-location ===
'''<code>p-location</code>''' has been re-used from [[h-event]].

== FAQ ==
=== p-name of a note ===
<div class="discussion">
* '''What is the <code>p-name</code> of a [https://indieweb.org/note note]?'''
** You probably should avoid adding <code>p-name</code> to notes. See https://indieweb.org/note for more discussion of the topic.
</div>

=== venue an entry was posted from ===
<div class="discussion">
* '''How do you indicate a named venue where an entry was posted from? Like a restaurant or park.'''
** Use an embedded [[h-card]] microformat on a <code>p-location</code> property value.
</div>

=== address an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== lat long an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== dt-published property and HTML5 time element ===
<div class="discussion">
* '''Does the dt-published property need to be a time element?'''
** The <code>dt-published</code> property should be a <code><time></code> 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.
</div>

=== what is the bare minimum list of required properties on an h-entry ===
<div class="discussion">
* 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:
</div>
* <code>url</code>
* <code>published</code> — if there is no "published" date for the "entry", then reconsider whether it is correct (or worth) marking it up as an entry.
<div class="discussion">
* 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:
</div>
* <code>content</code> (or <code>summary</code> at least) - especially for structured content. For a plain text note, the content/summary (whichever is used) should be the same as the <code>name</code>, otherwise it will be implied from the text content of the root element.
* <code>name</code> - for explicitly named/titled entries like blog posts and articles. Otherwise the entry is assumed to be a "title-less" [https://indieweb.org/note note] (like a tweet).
* <code>author</code> - including a nested <code>[[h-card]]</code> with author details like name, photo, url.

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

* ... add uses of h-entry you see in the wild here.
* ind.ie mark up their [https://ind.ie/blog blog] listing and [https://ind.ie/blog/autumn-events-2014/ permalink] pages with h-entry
* David John Mead marks up his profile, blog posts and comments with h-card, h-entry and h-cite on [http://davidjohnmead.com davidjohnmead.com]
* [[User:Brian|Brian Suda]] marks up his blog posts up with h-entry and h-card on [http://optional.is/required/ optional.is]
* Ashton McAllen marks up his blog posts, reposts, comments and likes with h-entry, h-card and h-cite on [http://acegiak.net/ acegiak.net]
* Emma Kuo marks up her blog posts and notes with h-entry and h-card on [http://notenoughneon.com/ notenoughneon.com]
* Scott Jenson marks up his blog posts with h-entry and h-card on [http://jenson.org/ jenson.org]
* Emily McAllen marks up her blog posts with h-entry and h-card on [http://blackwoolholiday.com/ blackwoolholiday.com]
* Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on [https://snarfed.org/ snarfed.org]
* Barry Frost marks up his notes with h-entry, h-card and h-cite on [http://barryfrost.com/ barryfrost.com]
* Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on [http://caseorganic.com/ caseorganic.com]
* Johannes Ernst marks up his blog posts with h-entry on [http://upon2020.com/blog/ upon2020.com]
* Michiel de Jong marks up his profile and notes with h-entry and h-card on [https://michielbdejong.com/ michielbdejong.com]
* Mike Taylor marks up his profile and blog posts with h-card and h-entry on [https://bear.im/bearlog/ bear.im]
* Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on [http://erinjo.is/ erinjo.is]
* Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on [https://jeena.net/ jeena.net]
* Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on [http://andysylvester.com/2014/03/01/howto-setting-up-the-selfoss-feed-reader-with-microformats-support/ andysylvester.com] (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --[[User:Barnabywalters|bw]] 14:44, 13 March 2014 (UTC))
* Chloe Weil marks up her blog posts with h-entry on [http://chloeweil.com/blog chloeweil.com]
* Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on [http://christopheducamp.com/ christopheducamp.com]
* Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on [http://glennjones.net/ glennjones.net]
* Marcus Povey marks up his blog posts and profile with h-entry and h-card on [http://www.marcus-povey.co.uk/ marcus-povey.co.uk]
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* Kyle Mahan marks up his profile and notes with h-card and h-entry on [http://kylewm.com/ kylewm.com]
* Okinawan-lyrics marks up his posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* App.net marks up profile pages and permalink pages with h-entry as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* The Twitter archive browser UI uses h-entry and h-card internally, unfortunately it’s not exposed as HTML in static files anywhere
* Brett Comnes marks up his posts with h-entry and h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like ([http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his posts up with h-card and h-entry, as well as draft u-in-reply-to and experimental u-like properties ([http://sandeep.io/101 example])
* Laurent Eschenauer marks up his posts with h-entry ([http://eschnou.com/entry/first-autonomous-flight-of-my-nodecopter-62-24992.html example])
* Tom Morris marks up his posts using h-entry ([http://tommorris.org/posts/8417 example])
* Numerous newer W3C specs, e.g.
** [http://www.w3.org/TR/2013/CR-css3-values-20130404/ CSS Values and Units Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/CR-css3-conditional-20130404/ CSS Conditional Rules Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/WD-css3-page-20130314/ CSS Paged Media Module Level 3 - 2013-03-14]
** [http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/ CSS Counter Styles Level 3 - 2013-02-21]
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry.
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Aaron Parecki uses h-entry to mark up notes, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-entry on his home page, as well as h-entry on all post permalinks, e.g. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], with [[rel-prev]]/[[rel-next]] (if applicable) to indicate prev/next posts
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-entry on all notes and articles, as well as nested within notes as reply contexts [http://waterpigs.co.uk/notes/1468/ example] and comments [http://waterpigs.co.uk/notes/1482/ example].

=== offline ===
* spreadly marks up share permalink pages with h-entry, as well as minimal h-cards and experimental p-like properties

== Validating ==
* '''[http://indiewebify.me/validate-h-entry/ indiewebify.me h-entry validator]''' parses [[h-entry]] markup, finds common errors and makes suggestions for things to add, with code samples
* '''[http://shrewdness.waterpigs.co.uk/test/ Shrewdness h-entry/h-feed validator]''' shows how shrewdness interprets+displays h-entries, with original source and interim formats, works for single h-entries and feed pages

{{h-spec-section-validating}}

== 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 [https://indieweb.org/ 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.
* [https://gnu.io/social/ GNUsocial] [https://git.gnu.io/gnu/gnu-social/ source code]
* [https://hubzilla.org/hubzilla/ Hubzilla] [https://github.org/redmatrix/hubzilla source code]
* [http://friendica.com/ Friendica] [https://github.org/friendica/friendica source code]
* [http://github.com/dissolve/inkblot InkBlot]
* ...

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

<source lang=html4strict>
<article class="h-entry hentry">
<h1 class="p-name entry-title">A Tale Of Two Tags</h1>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="e-content entry-content">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
<p>The a tag is perhaps the best of HTML, yet its corresponding invisible link tag has uses too.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>
</source>

{{note|Note: you may use any valid HTML5 elements. The <code>article h1 address time</code> elements are used in the example as semantically richer suggestions, however in general <code>div span</code> work fine too. The <code>time</code> element is special though in that its <code>datetime</code> 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: <code id="hentry">hentry</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

* <code>entry-title</code> - parse as '''<code>p-name</code>'''
* <code>entry-summary</code> - parse as '''<code>p-summary</code>'''
* <code>entry-content</code> - parse as '''<code>e-content</code>'''
* <code>published</code> - parse as '''dt-'''
* <code>updated</code> - parse as '''dt-'''
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>category</code>
* <code>rel=bookmark</code> - parse as '''<code>u-url</code>'''. While not a class name nor typical microformats property, rel=bookmark was the only way to indicate an hentry permalink. Thus parsers should look for rel=bookmark hyperlinks inside an hentry, and take their "href" value as a value for a '''<code>u-url</code>''' property, including handling any relative URL resolution.
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hentry. Thus parsers should look for rel=tag hyperlinks inside an hentry, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

Proposed: ([https://github.com/microformats/h-entry/issues/7 follow-up in issue #7])
* <code>time.entry-date[datetime]</code> - in the absence of <code>published</code>, parse as '''<code>dt-published</code>'''. parse for the first <code><time></code> element with class name of <code>entry-date</code> and non-empty <code>datetime</code> attribute inside an hentry, if there is no <code>published</code> property, use that time element's <code>datetime</code> attribute value for the <code>dt-published</code> property. Evidence: default WordPress themes 2011-2014([https://wp-themes.com/twentyeleven/][https://wp-themes.com/twentytwelve/][https://wp-themes.com/twentythirteen/][https://wp-themes.com/twentyfourteen/]).
* <code>rel=author</code> - in the absence of <code>author</code>, parse as '''<code>u-author</code>'''. While not a class name nor typical microformats property, rel=author was commonly used to link to an author's URL. Thus parsers should look for rel=author hyperlinks inside an hentry (or even on the same page, preceding the hentry), use the absolute version of it as a value for the '''<code>u-author</code>''' property if there is no "author" property. (citations to "hentry" examples in the wild that <em>depend</em> on rel=author needed to accepted this proposal. Note: default WordPress themes twentyeleven, twentytwelve, twentythirteen, twentyfourteen all use rel=author but only inside class="author vcard", and thus rel=author can be ignored since authorship is already picked up by existing <code>author</code> backcompat parsing.)

=== 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|rel=bookmark]]?''

A: tl;dr: use <code>class="u-url u-uid"</code> instead of <code>rel=bookmark</code> 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.

<nowiki>*</nowiki> even though rel=bookmark in particular is article-element / sectioning scoped in HTML5[http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-bookmark], 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 <code>entry-*</code> 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#Could_hAtom_instead_use_title_content_and_summary|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: [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-128 2012-08-30 IRC conversation].

== Related Work ==
Work that re-uses or builds upon h-entry:
* [https://mailpile.pagekite.me:8080/p/Open_Message_Format Mailpile Open Message Format] is using h-entry with structured properties, e.g. p-author h-card.

== Background ==
This work is based on the existing [[hAtom]] microformat, and extensive selfdogfooding in the [http://indiewebcamp.com 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 [[h-entry-issues|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|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|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_Additions|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|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|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 ==
* [[h-feed]]
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-geo]]
* [[hCard]]

[[Category:Specifications]]

h-entry

2020-09-12T04:54:59Z

Dshanske: /* Proposed Additions */

{{DISPLAYTITLE:h-entry}}
<dfn style="font-style:normal;font-weight:bold">h-entry</dfn> 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 [[microformats|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]].

;<span id="Status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [[h-entry-issues|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|change control]] process.
;Participate
:[https://github.com/microformats/h-entry/issues Open Issues]
:[[h-entry-issues|Resolved issues before 2012-246]]
:[[IRC]]: [irc://irc.freenode.net/microformats #microformats on Freenode]
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__

== Example ==
Here is a simple blog post example:

<source lang=html4strict>
<article class="h-entry">
<h1 class="p-name">Microformats are amazing</h1>
<p>Published by <a class="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></p>

<p class="p-summary">In which I extoll the virtues of using microformats.</p>

<div class="e-content">
<p>Blah blah blah</p>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"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>"
}
]
}
}
]
}
</source>

== Get started ==
The class '''<code>h-entry</code>''' 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 optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

=== Core Properties ===
The following ''core'' h-entry properties have broad consensus and are broadly interoperably published and consumed:
* '''<code>p-name</code>''' - entry name/title
* '''<code>p-summary</code>''' - short entry summary
* '''<code>e-content</code>''' - full content of the entry
* '''<code>dt-published</code>''' - when the entry was published
* '''<code>dt-updated</code>''' - when the entry was updated
* '''<code>p-author</code>''' - who wrote the entry, optionally embedded [[h-card]](s)
* '''<code>p-category</code>''' - entry categories/tags
* '''<code>u-url</code>''' - entry permalink URL
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical entry URL
* '''<code>p-location</code>''' - location the entry was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code>u-syndication</code>''' - URL(s) of syndicated copies of this post. The property equivalent of [[rel-syndication]] ([http://erinjo.is/2014/checked-into-rockit-colabs-23 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]) ([https://kartikprabhu.com/notes/re-citizen-of-indieweb example])
* '''<code id="p-rsvp">p-rsvp</code>''' (enum, use <data> element or [[value-class-pattern]])
** "yes", "no", "maybe", "interested". Case-insensitive values, normalized to lowercase. Examples:
** <code><nowiki>... <data class="p-rsvp" value="YES">is going</data> to ...</nowiki></code>, or
** <code><nowiki>... <data class="p-rsvp" value="Maybe">might go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="no">unable to go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="iNtEreSTed">am interested/tracking/watching</data> ...</nowiki></code>
* '''<code id="u-like-of">u-like-of</code>''' - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded [[h-cite]]
* '''<code id="u-repost-of">u-repost-of</code>''' - the URL which the h-entry is considered a “repost” of. Optionally an embedded [[h-cite]].

=== 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 id="p-comment">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 id="u-photo">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.
** [https://github.com/microformats/h-entry/issues/4 Issue 4: u-photo draft->core bc way more than 3+ pub and consuming impls/sites]
* '''<code id="u-video">u-video</code>''' - special u- parsing rules for <code><video src> & <source src></code>

=== 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 awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:
* '''<code>u-audio</code>''' - special u- parsing rules for <code><audio src> & <source src></code>. Examples: [http://transportini.com/ Transportini],[https://indieweb.org/podcast#How_to_podcast_with_h-feed possibly more]
* '''<code>u-like</code>''' - similar to p-comment, URL to a like post of the current post, e.g. in a responses list or facepile.
* '''<code>u-repost</code>''' - similar to u-like, URL to a repost of the current post, e.g. in a responses list or facepile.
* '''<code>u-bookmark-of</code>''' - indicates this h-entry is a bookmark of another URL. Optionally an [[h-cite]]. See [https://indieweb.org/bookmark indieweb.org/bookmark] for examples in the wild.
* '''<code>u-featured</code>''' - 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]].
** +1 sknebel: https://github.com/microformats/h-entry/issues/14
* '''<code>p-latitude</code>''' - latitude of the location of the entry
* '''<code>p-longitude</code>''' - longitude of the location of the entry
* '''<code>p-duration</code>''' - duration of an audio or video file in the entry. https://indieweb.org/duration Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>p-size</code>''' - size in bytes of an audio or video file in the entry. https://indieweb.org/size Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>u-listen-of</code>''' - also known as a 'scrobble', indicates this h-entry is a listen of another URL. Optionally an h-cite. https://github.com/microformats/h-entry/issues/11

The following interpretation is also proposed addition:
* if the <code>p-location</code> is also an embedded [[h-card]], the entry is treated as a "checkin".
** -1 [[User:Aaronpk|Aaronpk]] 14:22, 19 January 2017 (UTC) [https://aaronparecki.com/2017/01/13/21/ this post] is not a checkin, but has an h-card as the p-location property.

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: [[h-entry#change_control|change control]]

== Property Details ==
This section is a stub.
=== p-location ===
'''<code>p-location</code>''' has been re-used from [[h-event]].

== FAQ ==
=== p-name of a note ===
<div class="discussion">
* '''What is the <code>p-name</code> of a [https://indieweb.org/note note]?'''
** You probably should avoid adding <code>p-name</code> to notes. See https://indieweb.org/note for more discussion of the topic.
</div>

=== venue an entry was posted from ===
<div class="discussion">
* '''How do you indicate a named venue where an entry was posted from? Like a restaurant or park.'''
** Use an embedded [[h-card]] microformat on a <code>p-location</code> property value.
</div>

=== address an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== lat long an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== dt-published property and HTML5 time element ===
<div class="discussion">
* '''Does the dt-published property need to be a time element?'''
** The <code>dt-published</code> property should be a <code><time></code> 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.
</div>

=== what is the bare minimum list of required properties on an h-entry ===
<div class="discussion">
* 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:
</div>
* <code>url</code>
* <code>published</code> — if there is no "published" date for the "entry", then reconsider whether it is correct (or worth) marking it up as an entry.
<div class="discussion">
* 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:
</div>
* <code>content</code> (or <code>summary</code> at least) - especially for structured content. For a plain text note, the content/summary (whichever is used) should be the same as the <code>name</code>, otherwise it will be implied from the text content of the root element.
* <code>name</code> - for explicitly named/titled entries like blog posts and articles. Otherwise the entry is assumed to be a "title-less" [https://indieweb.org/note note] (like a tweet).
* <code>author</code> - including a nested <code>[[h-card]]</code> with author details like name, photo, url.

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

* ... add uses of h-entry you see in the wild here.
* ind.ie mark up their [https://ind.ie/blog blog] listing and [https://ind.ie/blog/autumn-events-2014/ permalink] pages with h-entry
* David John Mead marks up his profile, blog posts and comments with h-card, h-entry and h-cite on [http://davidjohnmead.com davidjohnmead.com]
* [[User:Brian|Brian Suda]] marks up his blog posts up with h-entry and h-card on [http://optional.is/required/ optional.is]
* Ashton McAllen marks up his blog posts, reposts, comments and likes with h-entry, h-card and h-cite on [http://acegiak.net/ acegiak.net]
* Emma Kuo marks up her blog posts and notes with h-entry and h-card on [http://notenoughneon.com/ notenoughneon.com]
* Scott Jenson marks up his blog posts with h-entry and h-card on [http://jenson.org/ jenson.org]
* Emily McAllen marks up her blog posts with h-entry and h-card on [http://blackwoolholiday.com/ blackwoolholiday.com]
* Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on [https://snarfed.org/ snarfed.org]
* Barry Frost marks up his notes with h-entry, h-card and h-cite on [http://barryfrost.com/ barryfrost.com]
* Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on [http://caseorganic.com/ caseorganic.com]
* Johannes Ernst marks up his blog posts with h-entry on [http://upon2020.com/blog/ upon2020.com]
* Michiel de Jong marks up his profile and notes with h-entry and h-card on [https://michielbdejong.com/ michielbdejong.com]
* Mike Taylor marks up his profile and blog posts with h-card and h-entry on [https://bear.im/bearlog/ bear.im]
* Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on [http://erinjo.is/ erinjo.is]
* Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on [https://jeena.net/ jeena.net]
* Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on [http://andysylvester.com/2014/03/01/howto-setting-up-the-selfoss-feed-reader-with-microformats-support/ andysylvester.com] (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --[[User:Barnabywalters|bw]] 14:44, 13 March 2014 (UTC))
* Chloe Weil marks up her blog posts with h-entry on [http://chloeweil.com/blog chloeweil.com]
* Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on [http://christopheducamp.com/ christopheducamp.com]
* Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on [http://glennjones.net/ glennjones.net]
* Marcus Povey marks up his blog posts and profile with h-entry and h-card on [http://www.marcus-povey.co.uk/ marcus-povey.co.uk]
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* Kyle Mahan marks up his profile and notes with h-card and h-entry on [http://kylewm.com/ kylewm.com]
* Okinawan-lyrics marks up his posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* App.net marks up profile pages and permalink pages with h-entry as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* The Twitter archive browser UI uses h-entry and h-card internally, unfortunately it’s not exposed as HTML in static files anywhere
* Brett Comnes marks up his posts with h-entry and h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like ([http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his posts up with h-card and h-entry, as well as draft u-in-reply-to and experimental u-like properties ([http://sandeep.io/101 example])
* Laurent Eschenauer marks up his posts with h-entry ([http://eschnou.com/entry/first-autonomous-flight-of-my-nodecopter-62-24992.html example])
* Tom Morris marks up his posts using h-entry ([http://tommorris.org/posts/8417 example])
* Numerous newer W3C specs, e.g.
** [http://www.w3.org/TR/2013/CR-css3-values-20130404/ CSS Values and Units Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/CR-css3-conditional-20130404/ CSS Conditional Rules Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/WD-css3-page-20130314/ CSS Paged Media Module Level 3 - 2013-03-14]
** [http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/ CSS Counter Styles Level 3 - 2013-02-21]
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry.
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Aaron Parecki uses h-entry to mark up notes, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-entry on his home page, as well as h-entry on all post permalinks, e.g. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], with [[rel-prev]]/[[rel-next]] (if applicable) to indicate prev/next posts
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-entry on all notes and articles, as well as nested within notes as reply contexts [http://waterpigs.co.uk/notes/1468/ example] and comments [http://waterpigs.co.uk/notes/1482/ example].

=== offline ===
* spreadly marks up share permalink pages with h-entry, as well as minimal h-cards and experimental p-like properties

== Validating ==
* '''[http://indiewebify.me/validate-h-entry/ indiewebify.me h-entry validator]''' parses [[h-entry]] markup, finds common errors and makes suggestions for things to add, with code samples
* '''[http://shrewdness.waterpigs.co.uk/test/ Shrewdness h-entry/h-feed validator]''' shows how shrewdness interprets+displays h-entries, with original source and interim formats, works for single h-entries and feed pages

{{h-spec-section-validating}}

== 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 [https://indieweb.org/ 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.
* [https://gnu.io/social/ GNUsocial] [https://git.gnu.io/gnu/gnu-social/ source code]
* [https://hubzilla.org/hubzilla/ Hubzilla] [https://github.org/redmatrix/hubzilla source code]
* [http://friendica.com/ Friendica] [https://github.org/friendica/friendica source code]
* [http://github.com/dissolve/inkblot InkBlot]
* ...

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

<source lang=html4strict>
<article class="h-entry hentry">
<h1 class="p-name entry-title">A Tale Of Two Tags</h1>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="e-content entry-content">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
<p>The a tag is perhaps the best of HTML, yet its corresponding invisible link tag has uses too.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>
</source>

{{note|Note: you may use any valid HTML5 elements. The <code>article h1 address time</code> elements are used in the example as semantically richer suggestions, however in general <code>div span</code> work fine too. The <code>time</code> element is special though in that its <code>datetime</code> 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: <code id="hentry">hentry</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

* <code>entry-title</code> - parse as '''<code>p-name</code>'''
* <code>entry-summary</code> - parse as '''<code>p-summary</code>'''
* <code>entry-content</code> - parse as '''<code>e-content</code>'''
* <code>published</code> - parse as '''dt-'''
* <code>updated</code> - parse as '''dt-'''
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>category</code>
* <code>rel=bookmark</code> - parse as '''<code>u-url</code>'''. While not a class name nor typical microformats property, rel=bookmark was the only way to indicate an hentry permalink. Thus parsers should look for rel=bookmark hyperlinks inside an hentry, and take their "href" value as a value for a '''<code>u-url</code>''' property, including handling any relative URL resolution.
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hentry. Thus parsers should look for rel=tag hyperlinks inside an hentry, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

Proposed: ([https://github.com/microformats/h-entry/issues/7 follow-up in issue #7])
* <code>time.entry-date[datetime]</code> - in the absence of <code>published</code>, parse as '''<code>dt-published</code>'''. parse for the first <code><time></code> element with class name of <code>entry-date</code> and non-empty <code>datetime</code> attribute inside an hentry, if there is no <code>published</code> property, use that time element's <code>datetime</code> attribute value for the <code>dt-published</code> property. Evidence: default WordPress themes 2011-2014([https://wp-themes.com/twentyeleven/][https://wp-themes.com/twentytwelve/][https://wp-themes.com/twentythirteen/][https://wp-themes.com/twentyfourteen/]).
* <code>rel=author</code> - in the absence of <code>author</code>, parse as '''<code>u-author</code>'''. While not a class name nor typical microformats property, rel=author was commonly used to link to an author's URL. Thus parsers should look for rel=author hyperlinks inside an hentry (or even on the same page, preceding the hentry), use the absolute version of it as a value for the '''<code>u-author</code>''' property if there is no "author" property. (citations to "hentry" examples in the wild that <em>depend</em> on rel=author needed to accepted this proposal. Note: default WordPress themes twentyeleven, twentytwelve, twentythirteen, twentyfourteen all use rel=author but only inside class="author vcard", and thus rel=author can be ignored since authorship is already picked up by existing <code>author</code> backcompat parsing.)

=== 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|rel=bookmark]]?''

A: tl;dr: use <code>class="u-url u-uid"</code> instead of <code>rel=bookmark</code> 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.

<nowiki>*</nowiki> even though rel=bookmark in particular is article-element / sectioning scoped in HTML5[http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-bookmark], 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 <code>entry-*</code> 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#Could_hAtom_instead_use_title_content_and_summary|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: [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-128 2012-08-30 IRC conversation].

== Related Work ==
Work that re-uses or builds upon h-entry:
* [https://mailpile.pagekite.me:8080/p/Open_Message_Format Mailpile Open Message Format] is using h-entry with structured properties, e.g. p-author h-card.

== Background ==
This work is based on the existing [[hAtom]] microformat, and extensive selfdogfooding in the [http://indiewebcamp.com 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 [[h-entry-issues|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|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|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_Additions|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|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|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 ==
* [[h-feed]]
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-geo]]
* [[hCard]]

[[Category:Specifications]]

h-entry

2020-09-12T04:54:01Z

Dshanske: /* Proposed Additions */

{{DISPLAYTITLE:h-entry}}
<dfn style="font-style:normal;font-weight:bold">h-entry</dfn> 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 [[microformats|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]].

;<span id="Status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [[h-entry-issues|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|change control]] process.
;Participate
:[https://github.com/microformats/h-entry/issues Open Issues]
:[[h-entry-issues|Resolved issues before 2012-246]]
:[[IRC]]: [irc://irc.freenode.net/microformats #microformats on Freenode]
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__

== Example ==
Here is a simple blog post example:

<source lang=html4strict>
<article class="h-entry">
<h1 class="p-name">Microformats are amazing</h1>
<p>Published by <a class="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></p>

<p class="p-summary">In which I extoll the virtues of using microformats.</p>

<div class="e-content">
<p>Blah blah blah</p>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"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>"
}
]
}
}
]
}
</source>

== Get started ==
The class '''<code>h-entry</code>''' 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 optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

=== Core Properties ===
The following ''core'' h-entry properties have broad consensus and are broadly interoperably published and consumed:
* '''<code>p-name</code>''' - entry name/title
* '''<code>p-summary</code>''' - short entry summary
* '''<code>e-content</code>''' - full content of the entry
* '''<code>dt-published</code>''' - when the entry was published
* '''<code>dt-updated</code>''' - when the entry was updated
* '''<code>p-author</code>''' - who wrote the entry, optionally embedded [[h-card]](s)
* '''<code>p-category</code>''' - entry categories/tags
* '''<code>u-url</code>''' - entry permalink URL
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical entry URL
* '''<code>p-location</code>''' - location the entry was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code>u-syndication</code>''' - URL(s) of syndicated copies of this post. The property equivalent of [[rel-syndication]] ([http://erinjo.is/2014/checked-into-rockit-colabs-23 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]) ([https://kartikprabhu.com/notes/re-citizen-of-indieweb example])
* '''<code id="p-rsvp">p-rsvp</code>''' (enum, use <data> element or [[value-class-pattern]])
** "yes", "no", "maybe", "interested". Case-insensitive values, normalized to lowercase. Examples:
** <code><nowiki>... <data class="p-rsvp" value="YES">is going</data> to ...</nowiki></code>, or
** <code><nowiki>... <data class="p-rsvp" value="Maybe">might go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="no">unable to go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="iNtEreSTed">am interested/tracking/watching</data> ...</nowiki></code>
* '''<code id="u-like-of">u-like-of</code>''' - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded [[h-cite]]
* '''<code id="u-repost-of">u-repost-of</code>''' - the URL which the h-entry is considered a “repost” of. Optionally an embedded [[h-cite]].

=== 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 id="p-comment">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 id="u-photo">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.
** [https://github.com/microformats/h-entry/issues/4 Issue 4: u-photo draft->core bc way more than 3+ pub and consuming impls/sites]
* '''<code id="u-video">u-video</code>''' - special u- parsing rules for <code><video src> & <source src></code>

=== 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 awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:
* '''<code>u-audio</code>''' - special u- parsing rules for <code><audio src> & <source src></code>. Examples: [http://transportini.com/ Transportini],[https://indieweb.org/podcast#How_to_podcast_with_h-feed possibly more]
* '''<code>u-like</code>''' - similar to p-comment, URL to a like post of the current post, e.g. in a responses list or facepile.
* '''<code>u-repost</code>''' - similar to u-like, URL to a repost of the current post, e.g. in a responses list or facepile.
* '''<code>u-bookmark-of</code>''' - indicates this h-entry is a bookmark of another URL. Optionally an [[h-cite]]. See [https://indieweb.org/bookmark indieweb.org/bookmark] for examples in the wild.
* '''<code>u-featured</code>''' - 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]].
** +1 sknebel: https://github.com/microformats/h-entry/issues/14
* '''<code>p-latitude</code>''' - latitude of the location of the entry
* '''<code>p-longitude</code>''' - longitude of the location of the entry
* '''<code>p-duration</code>''' - duration of an audio or video file in the entry. https://indieweb.org/duration Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>p-size</code>''' - size in bytes of an audio or video file in the entry. https://indieweb.org/size Multiple publishers and consumers in the wild; https://github.com/snarfed/granary/issues/169 more background.
* '''<code>u-listen-of</code>''' - also known as a 'scrobble', indicates this h-entry is a listen post. Optionally an h-cite. https://github.com/microformats/h-entry/issues/11

The following interpretation is also proposed addition:
* if the <code>p-location</code> is also an embedded [[h-card]], the entry is treated as a "checkin".
** -1 [[User:Aaronpk|Aaronpk]] 14:22, 19 January 2017 (UTC) [https://aaronparecki.com/2017/01/13/21/ this post] is not a checkin, but has an h-card as the p-location property.

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: [[h-entry#change_control|change control]]

== Property Details ==
This section is a stub.
=== p-location ===
'''<code>p-location</code>''' has been re-used from [[h-event]].

== FAQ ==
=== p-name of a note ===
<div class="discussion">
* '''What is the <code>p-name</code> of a [https://indieweb.org/note note]?'''
** You probably should avoid adding <code>p-name</code> to notes. See https://indieweb.org/note for more discussion of the topic.
</div>

=== venue an entry was posted from ===
<div class="discussion">
* '''How do you indicate a named venue where an entry was posted from? Like a restaurant or park.'''
** Use an embedded [[h-card]] microformat on a <code>p-location</code> property value.
</div>

=== address an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== lat long an entry was posted from ===
<div class="discussion">
* '''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 <code>p-location</code> property value.
</div>

=== dt-published property and HTML5 time element ===
<div class="discussion">
* '''Does the dt-published property need to be a time element?'''
** The <code>dt-published</code> property should be a <code><time></code> 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.
</div>

=== what is the bare minimum list of required properties on an h-entry ===
<div class="discussion">
* 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:
</div>
* <code>url</code>
* <code>published</code> — if there is no "published" date for the "entry", then reconsider whether it is correct (or worth) marking it up as an entry.
<div class="discussion">
* 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:
</div>
* <code>content</code> (or <code>summary</code> at least) - especially for structured content. For a plain text note, the content/summary (whichever is used) should be the same as the <code>name</code>, otherwise it will be implied from the text content of the root element.
* <code>name</code> - for explicitly named/titled entries like blog posts and articles. Otherwise the entry is assumed to be a "title-less" [https://indieweb.org/note note] (like a tweet).
* <code>author</code> - including a nested <code>[[h-card]]</code> with author details like name, photo, url.

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

* ... add uses of h-entry you see in the wild here.
* ind.ie mark up their [https://ind.ie/blog blog] listing and [https://ind.ie/blog/autumn-events-2014/ permalink] pages with h-entry
* David John Mead marks up his profile, blog posts and comments with h-card, h-entry and h-cite on [http://davidjohnmead.com davidjohnmead.com]
* [[User:Brian|Brian Suda]] marks up his blog posts up with h-entry and h-card on [http://optional.is/required/ optional.is]
* Ashton McAllen marks up his blog posts, reposts, comments and likes with h-entry, h-card and h-cite on [http://acegiak.net/ acegiak.net]
* Emma Kuo marks up her blog posts and notes with h-entry and h-card on [http://notenoughneon.com/ notenoughneon.com]
* Scott Jenson marks up his blog posts with h-entry and h-card on [http://jenson.org/ jenson.org]
* Emily McAllen marks up her blog posts with h-entry and h-card on [http://blackwoolholiday.com/ blackwoolholiday.com]
* Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on [https://snarfed.org/ snarfed.org]
* Barry Frost marks up his notes with h-entry, h-card and h-cite on [http://barryfrost.com/ barryfrost.com]
* Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on [http://caseorganic.com/ caseorganic.com]
* Johannes Ernst marks up his blog posts with h-entry on [http://upon2020.com/blog/ upon2020.com]
* Michiel de Jong marks up his profile and notes with h-entry and h-card on [https://michielbdejong.com/ michielbdejong.com]
* Mike Taylor marks up his profile and blog posts with h-card and h-entry on [https://bear.im/bearlog/ bear.im]
* Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on [http://erinjo.is/ erinjo.is]
* Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on [https://jeena.net/ jeena.net]
* Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on [http://andysylvester.com/2014/03/01/howto-setting-up-the-selfoss-feed-reader-with-microformats-support/ andysylvester.com] (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --[[User:Barnabywalters|bw]] 14:44, 13 March 2014 (UTC))
* Chloe Weil marks up her blog posts with h-entry on [http://chloeweil.com/blog chloeweil.com]
* Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on [http://christopheducamp.com/ christopheducamp.com]
* Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on [http://glennjones.net/ glennjones.net]
* Marcus Povey marks up his blog posts and profile with h-entry and h-card on [http://www.marcus-povey.co.uk/ marcus-povey.co.uk]
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* Kyle Mahan marks up his profile and notes with h-card and h-entry on [http://kylewm.com/ kylewm.com]
* Okinawan-lyrics marks up his posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* App.net marks up profile pages and permalink pages with h-entry as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* The Twitter archive browser UI uses h-entry and h-card internally, unfortunately it’s not exposed as HTML in static files anywhere
* Brett Comnes marks up his posts with h-entry and h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like ([http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his posts up with h-card and h-entry, as well as draft u-in-reply-to and experimental u-like properties ([http://sandeep.io/101 example])
* Laurent Eschenauer marks up his posts with h-entry ([http://eschnou.com/entry/first-autonomous-flight-of-my-nodecopter-62-24992.html example])
* Tom Morris marks up his posts using h-entry ([http://tommorris.org/posts/8417 example])
* Numerous newer W3C specs, e.g.
** [http://www.w3.org/TR/2013/CR-css3-values-20130404/ CSS Values and Units Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/CR-css3-conditional-20130404/ CSS Conditional Rules Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/WD-css3-page-20130314/ CSS Paged Media Module Level 3 - 2013-03-14]
** [http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/ CSS Counter Styles Level 3 - 2013-02-21]
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry.
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Aaron Parecki uses h-entry to mark up notes, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-entry on his home page, as well as h-entry on all post permalinks, e.g. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], with [[rel-prev]]/[[rel-next]] (if applicable) to indicate prev/next posts
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-entry on all notes and articles, as well as nested within notes as reply contexts [http://waterpigs.co.uk/notes/1468/ example] and comments [http://waterpigs.co.uk/notes/1482/ example].

=== offline ===
* spreadly marks up share permalink pages with h-entry, as well as minimal h-cards and experimental p-like properties

== Validating ==
* '''[http://indiewebify.me/validate-h-entry/ indiewebify.me h-entry validator]''' parses [[h-entry]] markup, finds common errors and makes suggestions for things to add, with code samples
* '''[http://shrewdness.waterpigs.co.uk/test/ Shrewdness h-entry/h-feed validator]''' shows how shrewdness interprets+displays h-entries, with original source and interim formats, works for single h-entries and feed pages

{{h-spec-section-validating}}

== 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 [https://indieweb.org/ 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.
* [https://gnu.io/social/ GNUsocial] [https://git.gnu.io/gnu/gnu-social/ source code]
* [https://hubzilla.org/hubzilla/ Hubzilla] [https://github.org/redmatrix/hubzilla source code]
* [http://friendica.com/ Friendica] [https://github.org/friendica/friendica source code]
* [http://github.com/dissolve/inkblot InkBlot]
* ...

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

<source lang=html4strict>
<article class="h-entry hentry">
<h1 class="p-name entry-title">A Tale Of Two Tags</h1>
<address class="p-author author h-card vcard">
<a href="https://chandra.example.com/" class="u-url url p-name fn" rel="author">Chandra</a>
</address>
<time class="dt-published published" datetime="2012-06-20T08:34:46-07:00">June 20, 2012</time>
<div class="e-content entry-content">
<p>It was the best of visible tags, it was the alternative invisible tags.</p>
<p>The a tag is perhaps the best of HTML, yet its corresponding invisible link tag has uses too.</p>
</div>
<a href="/category/uncategorized/" rel="category tag" class="p-category">General</a>
</article>
</source>

{{note|Note: you may use any valid HTML5 elements. The <code>article h1 address time</code> elements are used in the example as semantically richer suggestions, however in general <code>div span</code> work fine too. The <code>time</code> element is special though in that its <code>datetime</code> 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: <code id="hentry">hentry</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified):

* <code>entry-title</code> - parse as '''<code>p-name</code>'''
* <code>entry-summary</code> - parse as '''<code>p-summary</code>'''
* <code>entry-content</code> - parse as '''<code>e-content</code>'''
* <code>published</code> - parse as '''dt-'''
* <code>updated</code> - parse as '''dt-'''
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>category</code>
* <code>rel=bookmark</code> - parse as '''<code>u-url</code>'''. While not a class name nor typical microformats property, rel=bookmark was the only way to indicate an hentry permalink. Thus parsers should look for rel=bookmark hyperlinks inside an hentry, and take their "href" value as a value for a '''<code>u-url</code>''' property, including handling any relative URL resolution.
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hentry. Thus parsers should look for rel=tag hyperlinks inside an hentry, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

Proposed: ([https://github.com/microformats/h-entry/issues/7 follow-up in issue #7])
* <code>time.entry-date[datetime]</code> - in the absence of <code>published</code>, parse as '''<code>dt-published</code>'''. parse for the first <code><time></code> element with class name of <code>entry-date</code> and non-empty <code>datetime</code> attribute inside an hentry, if there is no <code>published</code> property, use that time element's <code>datetime</code> attribute value for the <code>dt-published</code> property. Evidence: default WordPress themes 2011-2014([https://wp-themes.com/twentyeleven/][https://wp-themes.com/twentytwelve/][https://wp-themes.com/twentythirteen/][https://wp-themes.com/twentyfourteen/]).
* <code>rel=author</code> - in the absence of <code>author</code>, parse as '''<code>u-author</code>'''. While not a class name nor typical microformats property, rel=author was commonly used to link to an author's URL. Thus parsers should look for rel=author hyperlinks inside an hentry (or even on the same page, preceding the hentry), use the absolute version of it as a value for the '''<code>u-author</code>''' property if there is no "author" property. (citations to "hentry" examples in the wild that <em>depend</em> on rel=author needed to accepted this proposal. Note: default WordPress themes twentyeleven, twentytwelve, twentythirteen, twentyfourteen all use rel=author but only inside class="author vcard", and thus rel=author can be ignored since authorship is already picked up by existing <code>author</code> backcompat parsing.)

=== 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|rel=bookmark]]?''

A: tl;dr: use <code>class="u-url u-uid"</code> instead of <code>rel=bookmark</code> 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.

<nowiki>*</nowiki> even though rel=bookmark in particular is article-element / sectioning scoped in HTML5[http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-bookmark], 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 <code>entry-*</code> 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#Could_hAtom_instead_use_title_content_and_summary|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: [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-128 2012-08-30 IRC conversation].

== Related Work ==
Work that re-uses or builds upon h-entry:
* [https://mailpile.pagekite.me:8080/p/Open_Message_Format Mailpile Open Message Format] is using h-entry with structured properties, e.g. p-author h-card.

== Background ==
This work is based on the existing [[hAtom]] microformat, and extensive selfdogfooding in the [http://indiewebcamp.com 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 [[h-entry-issues|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|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|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_Additions|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|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|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 ==
* [[h-feed]]
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-geo]]
* [[hCard]]

[[Category:Specifications]]

multi-author

2015-03-10T00:35:58Z

Dshanske:

{{stub}}

'''<dfn>multi-author</dfn>''' refers to a site, a [[h-entry|post]], or anything else that has multiple authors, in contrast to the default [https://indiewebcamp.com/ indieweb] use-case of a person with their own site where they create everything.

The issues that come here are how to specify the relationships between authors of the same entity, such as a post, or how do you specify multiple authors on a site and identify them.

So, how, in a page with multiple authors, do you specify where their definitive information lays, as opposed to the version they want for that particular location.

For example, if Alice is publishing a site with Bob and Jim, she may wish to craft information on that site specifically geared toward that audience...for example, an email address specifically for that site. But she may wish to link to an expanded version elsewhere on her own site.

== See Also ==
* [[about-page]]
* [[h-card]]
* [[XFN]]
* [[h-entry]]

about-page

2015-03-09T23:54:46Z

Dshanske:

{{stub}}

An '''<dfn>about page</dfn>''' often describes more information about the person (or organization) that a site represents, or that a site is created by, than on the top level home page.

One of the issues is that, when you are sharing your details with others, you usually do not share the About page. You share the top level page, from which there is usually a link. There may also be some basic information on that top level page which the About page expands on.

For different people/organizations, an about page can indicate different things. For example, some use it to identify interest, contact data, a formalized bio, etc.