目录

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

例子Example

这里是简单的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 的元素。所有属性是可选的。

核心属性

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

草案属性

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

拟议增加

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

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

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

属性细节

该部分留空

p-location

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

问答

note 的 p-name

条目发贴的入口

条目发贴的地址

条目发贴的经纬度

dt-published 属性和 HTML5 time 元素

什么是h-entry上所需属性的最低限度清单

外面在用的例子

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

离线

验证

h-spec-section-validating

实现

发布或使用h-entry的软件实现，包括主题，插件或扩展：

(这部分留白需要扩展! 实践上，几乎每个在 独立网站 上的CMS 都默认支持 h-entry 。)

在添加实施时，请提供链接到其主页和开放源代码库（如果有的话）。

向后兼容性

发布商兼容性

为了实现与传统的 hAtom 保持兼容，除了具有更多面向未来的h-entry属性外，还可以使用 hAtom 类 (或 rel 值)，例如: 

<div class="h-entry hentry">
  <h1 class="p-name entry-title">My great blog post</h1>
</div>

等同hAtom 类名和rel 值的清单列在下面。

解析兼容性

只有找到经典的根类名称并将它们解析为microformats2属性，微格式解析器才应该检测经典属性。

如果找到一个 “h-entry” 在同一元素中不再查找 “hentry”。

Compat 根类名: hentry 属性: (除非另有说明，以 p- 线文本解析):

提议: (follow-up in issue #7)

Compat问答

关于 rel bookmark

还有这样的问法: 我已经有 rel=bookmark了为什么还要使用 h-entry u-url u-uid 作为永久链接?

答: 太长了懒得读：使用 class=“u-url u-uid” 而不是 rel=bookmark 作为贴子的永久链接是因为它更简单 (更少的属性)，对于上下文间工作得更好 (永久链接页，主页上的最近贴子，归档页中的贴子集合)。

rel=bookmark 是老是 hAtom 标记永久链接的方法。在那时起，有两个因素促成在微格式中减少使用 rel :

* 尽管rel=bookmark 在HTML5范围中是特别的文章元素 / 分李。http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-bookmark, 但是典型的作者不会记住这些细节，因此任何格式依赖它都不大好。

为什么重命名 entry-title entry-summary entry-content

在经典 hAtom 中的 entry-* 类名前缀，因为要考虑词汇hCard 中的标题（如工作头衔，完全不同的语义）属性以及在hCalendar中的摘要属性 (参见: hAtom FAQ).

遵循简单性simplicity 原则，在microformats2中，上述f title 的模糊性通过删除它一处理。 name现在在所有词汇表中均一致的用作 “名称” 微格式属性，因为用它来标记贴子的名称是有意义的。

同样，添加entry- 到 summary 没有添加任何有用的信息，并且在实践中，博客文章摘要与条目摘要重叠没有问题，所以简化为sunnary是有意义的。 这同样适用于entry-content简化为content。

参见: 2012-08-30 |IRC 交流.

相关工作

重用或基于 h-entry的工作:

背景

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

参见

Specifications