H-entry

h-entry 是一个简单的开放格式， 用作WEB上的松散片段或者有日期戳的内容。h-entry经常用作打算联合发表的内容。例如blog贴子。h-entry是几个开放的 microformat标准之一用来内嵌数据在HTML中。

h-entry 是hAtom各式的microformats2升级版。 特别是“hentry” 根类本身就是基于 Atom的 “entry” 元素。对于“hfeed”的更新参见 h-feed.

这是一个 活规范，但已经足够成熟，鼓励更多的实现和 反馈。 该规范有部分是稳定的、草案和建议。 除非有明确的标为草案或提议，其它功能是稳定的。草案和提议的功能可能发生实质性的改变。不期望对稳定的功能特征进行改变，但作为一个活规范，可以根据实施经验 对问题和勘误进行实质性更改，这需要参与实施人员达到共识，作为明确的更改控制 过程的一部分。

Open Issues Resolved issues before 2012-246 IRC: #microformats on Freenode

Tantek Çelik 中文翻译 Eureka Chen

cc0 owfat

这里是简单的blog贴子例子:

<article class="h-entry">
  <h1 class="p-name">Microformats are amazing======
  <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>

解析为 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>"
          }
        ]]
      }
    }
  ]]
}

类 h-entry 是 根类名 表示存在一个 h-entry.

p-name, p-author, dt-published 和其它的列在 h-entry 下面的 h-entry 属性类名在下面进行定义。

注：一个entry的目的在里面写一些明确的内容（在内容属性或非文本内容或响应的其他特定属性）以及任何其它该内容上下文，包括该内容什么时候发布和/或更新，创建它的人，标签或分类，以及链接到该内容的（可能带有引用摘录的）响应和/或链接到联合副本。

h-entry 属性，在带有类 h-entry 的元素。所有属性是可选的。

• 参见 microformats2-parsing 了解更多类名属性。

以下核心h-entry属性具有广泛的共识，并且广泛地可互操作地发布和使用：

• p-name - 条目名称/标题
• p-summary - 短的条目摘要
• e-content - 条目的完整内容
• dt-published - 条目的发布时间
• dt-updated -条目更新时间
• p-author - 谁写的条目，可选嵌入 h-card(多个)
• p-category - 条目分类/标签
• u-url - 条目永久链接
• u-uid - 通用唯一标识符，通常是规范的条目URL
• p-location - 条目发贴地址，可选嵌入 h-card, h-adr, 或者 h-geo
• u-syndication - 该贴子的联合副本URL(s) ，该属性等价于rel-syndication (example)
• u-in-reply-to - 该URL的h-entry被认为是回复 (例如，没有下文则没有意义，可以在显示在评论中），可选嵌入 h-cite (reply-context) (example)
• p-rsvp (枚举, 使用<data> 元素或者 value-class-pattern)
  • “yes”, “no”, “maybe”, “interested”. 不区分大小写的值, 规范到小写。例如:
  • ... <data class="p-rsvp" value="yes">is going</data> to ..., 或者
  • ... <data class="p-rsvp" value="maybe">might go</data> to ...
  • ... <data class="p-rsvp" value="no">unable to go</data> to ...
  • ... <data class="p-rsvp" value="interested">am interested/tracking/watching</data> ...
• u-like-of - h-entry被认为是 “喜欢” (喜爱，追星) 的URL。可选嵌入 h-cite
• u-repost-of - 该h-entry被认为是 “转发”的条目。可选嵌入 h-cite.

以下草案属性正在自然（已发布和正在使用）中使用，并在重点考虑中，但尚未成为核心的一部分：

• p-comment - 可选嵌入(或嵌套?) h-cite(s), 它们中的每个都是评论/回复父 h-entry. 参见 comment-brainstorming (example)
• u-photo - 一个或多个被认为是该条目的主要内容的照片，除非存在p-location p-card, 仍然被认为是“签入”（有一张照片）。 否则，u-photo的出现意味着该条目的名称应该被解释为照片上的标题，并且摘要/内容应该被解释为照片的描述。
• u-video - 专门 u- 解析规则用于<video src> & <source src>

以下属性是基于各种使用情况（如现有链接预览标记约定）而建议添加的，但正在等待自然中跨多个站点的引用，并至少在一个阅读器/现实世界中有使用代码示例：

• u-audio - 专用于 u- 解析规则应用于<audio src> & <source src>。示例: Transportini,possibly more
• u-like - 跟p-comment类似，对当前贴子喜欢的贴子的 URL ，例如在答复列表或回复墙上。
• u-repost - 跟 u-like 类似，对当前贴子进行转发的贴子，例如在答复列表或回复墙中。
• u-bookmark-of - 揸示这个h-entry是另一个URL的书签。值可以是URL或者一个 h-cite。参见 indieweb.org/bookmark 活的例子。
• u-featured - 该条目的代表性照片或图像，例如 适用于文章或根据主题裁剪的主要照片，适合用于 link-preview。
• p-latitude - 条目的经度
• p-longitude - 条目地址的纬度

以下的解释也在拟议增加:

• 如果p-location也嵌入 h-card, 该条目作为 “签入”对待。
  • -1 Aaronpk 14:22, 19 January 2017 (UTC) this post 不是checkin, 但有一个 h-card 作为 p-location 属性。

注意：随着h-entry使用的增多，表达和使用不同种类的内容，我们预计在现实世界使用和交互时，可能会提出附加或迭代的其他属性。

该部分留空

p-location 在 h-event 中被重用。

• 什么时一个 note 的p-name?
  • 几个选项，从最简单到最复杂。
    • 跟 p-content/e-content 属性一样。
    • 跟title属性一样 ，在note永久链接贴子页。当在自己的永久链接页发布一个note时，note的contents可能会简写为页面的标题。相同的简写可用于 p-name。
    • p-content/e-content属性的第一句 作为syndication 和 link-preview的目的，最好提供第一句作为note的 p-name。类似地，如果只有一部分内容被联合到其他网站，那么该部分可以标记为p-summary。

• 你如何指定一个从哪里发贴的命名入口？象餐馆和公园。
  • 在p-location属性值上使用嵌入 h-card 微格式。

• 你如何指定一个条目从哪里发布？就餐馆和公园。
  • 如果地址是命名入口的一部分，请参阅上文，使用 h-card
  • 否则，在p-location属性值上使用嵌入 h-adr 微格式。

• 你如何指定条目发布的经纬度？
  • 如果位置有一个附加经纬度的数据，参见上面，使用h-card
  • 否则，如果有一个地址附加到经纬度，参见上面，使用 h-adr
  • 否则在p-location属性值上嵌入 h-geo 微格式。

• dt-published 属性需要在time元素里吗?
  • dt-published 属性应该在一个 <time>元素里，这样可以利用 HTML5的 “datetime” 属性。
  • 这使您可以在属性的值中指定一个人类可读日期，并在 “datetime” 属性中指定ISO8601sm器可读的日期。

• 什么是h-entry上所需属性的最低限度清单?
  • 显式没有属性的必须的，但是在实践上，h-entry 应该具有至少以下的一些属性:

• name (可以被隐含)
• url (可以被隐含)
• published — 如果“entry”没有“published”日期，则重新考虑是否正确（或值得）将其标记为条目。

• h-entry除了最低限度外还有什么属性可以附加？
  • 除最低限度外，典型的 h-entry 还应具有以下内容:

• content (或至少 summary) - 特别是对结构化内容。对于纯文本笔记，content/summary (随便用哪一个) 应该同 name相同, 否则它将隐含在根元素的文本内容中。
• name - 用于显式命名/标题条目。 否则，该条目被假定为“无标题”注释（如推文）。
• author - 包括嵌套的h-card，其中包含作者详细信息，如姓名，照片，网址。

真实世界中发布或使用h-entry的网站和服务的范例：

• … 在这里添加你在外面看到的h-entry使用。
• ind.ie mark up their blog listing and 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 davidjohnmead.com
• Brian Suda marks up his blog posts up with h-entry and h-card on optional.is
• Ashton McAllen marks up his blog posts, reposts, comments and likes with h-entry, h-card and h-cite on acegiak.net
• Emma Kuo marks up her blog posts and notes with h-entry and h-card on notenoughneon.com
• Scott Jenson marks up his blog posts with h-entry and h-card on jenson.org
• Emily McAllen marks up her blog posts with h-entry and h-card on blackwoolholiday.com
• Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on snarfed.org
• Barry Frost marks up his notes with h-entry, h-card and h-cite on barryfrost.com
• Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on caseorganic.com
• Johannes Ernst marks up his blog posts with h-entry on upon2020.com
• Michiel de Jong marks up his profile and notes with h-entry and h-card on michielbdejong.com
• Mike Taylor marks up his profile and blog posts with h-card and h-entry on bear.im
• Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on erinjo.is
• Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on jeena.net
• Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on andysylvester.com (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite –bw 14:44, 13 March 2014 (UTC))
• Chloe Weil marks up her blog posts with h-entry on chloeweil.com
• Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on christopheducamp.com
• Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on glennjones.net
• Marcus Povey marks up his blog posts and profile with h-entry and h-card on marcus-povey.co.uk
• Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on notizblog.org
• Kyle Mahan marks up his profile and notes with h-card and h-entry on kylewm.com
• Okinawan-lyrics marks up his posts with h-entry and h-card (example)
• App.net marks up profile pages and permalink pages with h-entry as of 2013-08-06 (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 (example)
• Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like (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 (example)
• Laurent Eschenauer marks up his posts with h-entry (example)
• Tom Morris marks up his posts using h-entry (example)
• Numerous newer W3C specs, e.g.
  • CSS Values and Units Module Level 3 - 2013-04-04
  • CSS Conditional Rules Module Level 3 - 2013-04-04
  • CSS Paged Media Module Level 3 - 2013-03-14
  • CSS Counter Styles Level 3 - 2013-02-21
• SemPress is a WordPress theme that supports h-card, h-feed/h-entry.
• 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. 2012/230/reply/1.
• Tantek Çelik uses h-entry on his home page, as well as h-entry on all post permalinks, e.g. 2012-243 post, with rel-prev/rel-next (if applicable) to indicate prev/next posts
• Barnaby Walters uses h-entry on all notes and articles, as well as nested within notes as reply contexts example and comments example.

• 通过h-entry扩展地标记永久链接页面，以及最小的h-cards和实验性p-like属性

• indiewebify.me h-entry validator parses h-entry markup, finds common errors and makes suggestions for things to add, with code samples
• 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

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

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

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

• GNUsocial source code
• Hubzilla source code
• Friendica source code
• InkBlot
• …

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>

<h1 class="p-name entry-title">My great blog post======

</source>

The list of equivalent hAtom classnames and rel values is provided 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-entry” is found, don't look for an “hentry” on the same element.

Compat root class name:

hentry

<br/> Properties: (parsed as p- plain text unless otherwise specified):

• entry-title

  - parse as p-name

• entry-summary

  - parse as p-summary

• entry-content

  - parse as e-content

• published

  - parse as dt-

• updated

  - parse as dt-

• author

  - including compat root

  vcard

  in the absence of

  h-card

• category

• rel=bookmark

  - parse as u-url. 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 u-url property, including handling any relative URL resolution.

• rel=tag

  - parse as p-category. 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 p-category property.

Proposed: (follow-up in issue #7)

• time.entry-date[[datetime]]

  - in the absence of

  published

  , parse as dt-published. parse for the first

  <time>

  element with class name of

  entry-date

  and non-empty

  datetime

  attribute inside an hentry, if there is no

  published

  property, use that time element's

  datetime

  attribute value for the

  dt-published

  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/).

• rel=author

  - in the absence of

  author

  , parse as u-author. 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 u-author 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

  author

  backcompat parsing.)

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

A: tl;dr: use

class="u-url u-uid"

instead of

rel=bookmark

for post permalinks because it's simpler (fewer attributes), and works better across contexts (permalink page, recent posts on home page, collection of posts on archive pages).

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

• rel by typically* document scoped in HTML5 - thus making it inappropriate for use in microformats that are aggregated, e.g. a collection of posts on a home page or in monthly archives.
• it is easier to always use class names for properties. When formats use two (or more!) attributes in HTML to specify properties, confusion results in lower data quality (of the markup and thus the stuff that is marked up). Thus per the microformats principle of simplicity, in microformats2 we only use class names for properties.

* even though rel=bookmark in particular is article-element / sectioning scoped in HTML5http://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.

The

entry-*

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

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

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

See also: 2012-08-30 IRC conversation.

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

• Mailpile Open Message Format is using h-entry with structured properties, e.g. p-author h-card.

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

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

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

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

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

Beyond that, the following requirements must be met for adding or moving features (e.g. properties and values) to proposed, draft, or stable:

;Proposed

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

;Draft

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

;Stable

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

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

• h-feed
• microformats2
• microformats2-parsing
• h-geo
• hCard

Specifications