Tantek Çelik (Editor)
h-feed 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 microformat draft standards suitable for embedding data in HTML.
Per CC0, to the extent possible under law, the editors have waived all copyright and related or neighboring rights to this work. In addition, as of 2022-09-29, the editors have made this specification available under the Open Web Foundation Agreement Version 1.0.
- 1 Properties
- 2 Proposed Additions
- 3 Status
- 4 Use Cases
- 5 Examples in the wild
- 6 Implementations
- 7 Backward Compatibility
- 8 FAQ
- 9 See Also
h-feed properties, inside an element with class h-feed. All properties are optional.
root class name: h-feed
The following core h-feed properties have broad consensus:
p-name- name of the feed
p-author- author of the feed, optionally embed an h-cardMain article: h-card
u-url- URL of the feed
u-photo- representative photo / icon for the feed
- nested h-entry objects representing the items of the feed
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:
p-summary- based on non-trivial actual content usage of "atom:subtitle" on Blogger and WordPress.com featured blogs's Atom feeds.
p-entry- to be more consistent with the cascading of p-author or p-comment.
- 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
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 #microformats chat 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 0.1 "hfeed".
- 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 explicitly 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.
For backward compatibility, you may wish to use classic hAtom 0.1 classnames in addition to the more future-proof h-feed properties, for example:
<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>
article h1 h2 address timeelements are used in the example as semantically richer suggestions, however in general
div spanwork fine too. The
timeelement is special though in that its
datetimeattribute provides a more author/user friendly way of separating a machine readable ISO8601 datetime from a human readable summary.
hfeed is a backward compatible root class name that indicates the presence of an hAtom 0.1 feed.
Backward compatibility hAtom property class names and rel values are listed below.
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:
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)
rel=tag- parse as
p-category. 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
site-title- parse as
p-name[WordPress (Core? Typical themes?) has this class name by default, and without it buggy parsers may imply p-name as the whole h-feed (implied properties only apply to actual h-x roots, not backcompat).]
site-description- parse as
p-summary[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.
<title>of the page or the URL of the page as
- https://indieweb.org/authorship on the page to discover default authorship for any h-entry posts lacking explicit parsed
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:
<html class="h-feed"> … <title class="p-name">The Markup Blog</title> …
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.