Eureka Wiki (易易维基)

您的足迹:

差别

这里会显示出您选择的修订版和当前版本之间的差别。

到此差别页面的链接

两侧同时换到之前的修订记录 前一修订版
h-entry [2018/05/22 16:02]
eureka
h-entry [2018/05/22 18:28] (当前版本)
eureka
行 248: 行 248:
  
 =====  验证 ===== =====  验证 =====
-  *  **[[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://​indiewebify.me/​validate-h-entry/​|indiewebify.me h-entry ​验证器]]** 解析[[h-entry]] ​标记,发现共同的错误,并对要添加的东西进行代码示例的建议。 
-  *  **[[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+  *  **[[http://​shrewdness.waterpigs.co.uk/​test/​|Shrewdness h-entry/​h-feed ​验证器]]** 显示精深的解析+显示 ​h-entries, ​带有原始源和临时格式,适用于单个h-entries ​feed页面。
  
 {{h-spec-section-validating}} {{h-spec-section-validating}}
  
 =====  实现 ===== =====  实现 =====
-Software implementations that publish or consume ​h-entry, including themes, plugins, or extensions:+发布或使用h-entry的软件实现,包括主题,插件或扩展:
  
-(This section is a stub that needs expansionIn practice, nearly every CMS on every [[https://​indieweb.org/​|indie web]] site supports publishing ​h-entry ​by default.)+(这部分留白需要扩展实践上,几乎每个在 ​[[https://​indieweb.org/​|独立网站]] 上的CMS 都默认支持 ​h-entry ​)
  
-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://​gnu.io/​social/​|GNUsocial]] [[https://​git.gnu.io/​gnu/​gnu-social/​|源代码]] 
-  *  [[https://​hubzilla.org/​hubzilla/​|Hubzilla]] [[https://​github.org/​redmatrix/​hubzilla|source code]] +  *  [[https://​hubzilla.org/​hubzilla/​|Hubzilla]] [[https://​github.org/​redmatrix/​hubzilla|源代码]] 
-  *  [[http://​friendica.com/​|Friendica]] [[https://​github.org/​friendica/​friendica|source code]]+  *  [[http://​friendica.com/​|Friendica]] [[https://​github.org/​friendica/​friendica|源代码]]
   *  [[http://​github.com/​dissolve/​inkblot|InkBlot]]   *  [[http://​github.com/​dissolve/​inkblot|InkBlot]]
   *  ...   *  ...
  
-=====  ​Backward Compatibility ​== +=====  ​向后兼容性 ===== 
-====  ​Publisher Compatibility ​=== +====  ​发布商兼容性 ​=== 
-For backward compatibility with legacy ​[[hAtom]] ​consuming implementations,​ use [[hAtom]] ​classnames ​(or rel valuesin addition to the more future-proof h-entry properties, for example:+为了实现与传统的 ​[[hAtom]] ​保持兼容,除了具有更多面向未来的h-entry属性外,还可以使用 ​[[hAtom]] ​类 (或 rel ),例如:
  
-<source lang=html4strict>​+<code html4strict>​
 <div class="​h-entry hentry">​ <div class="​h-entry hentry">​
-  <h1 class="​p-name entry-title">​My great blog post======+  <h1 class="​p-name entry-title">​My great blog post</h1>
 </​div>​ </​div>​
-</source>+</code>
  
-The list of equivalent ​[[hAtom]] ​classnames and rel values is provided below.+等同[[hAtom]] ​类名和rel 值的清单列在下面。
  
-====  ​Parser Compatibility ​=== +====  ​解析兼容性 ==== 
-Microformats parsers {{should}} detect classic properties only if a classic root class name is found and parse them as microformats2 ​properties. ​+只有找到经典的根类名称并将它们解析为microformats2属性,微格式解析器才//​应该//​检测经典属性。
  
-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/>​ +如果找到一个 ​"h-entry"​ 在同一元素中不再查找 ​"​hentry"。
-Properties: (parsed as **p-** plain text unless otherwise specified):+
  
-  *  <​code>​entry-title</​code>​ - parse as **''​p-name''​** +Compat 根类名: ​''​hentry''​ 
-  *  <​code>​entry-summary</​code>​ - parse as **''​p-summary''​** +属性: (除非另有说明,以 ​**p-** ​线文本解析):​
-  *  <​code>​entry-content</​code>​ - parse as **''​e-content''​** +
-  *  <​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 **''​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. +
-   <​code>​rel=tag</​code>​ - 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: ([[https://​github.com/​microformats/​h-entry/​issues/​7|follow-up in issue #7]]) +  *  ''​entry-title''​ - 解析作 **''​p-name''​** 
-  *  ​<​code>​time.entry-date[[datetime]]</​code> ​in the absence of <​code>​published</​code>,​ parse as **''​dt-published''​**. parse for the first <​code>&​lt;​time&​gt;</​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/​]]). +  *  ​''​entry-summary'' ​解析作 ​**''​p-summary''​** 
-  *  ​<​code>​rel=author</​code> ​in the absence of <​code>​author</​code>,​ 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 proposalNote: 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.)+  *  ''​entry-content'' ​解析作 **''e-content''​** 
 +  *  ''​published'' ​解析作 **dt-** 
 +  *  ''​updated'' ​解析作 **dt-** 
 +  *  ''​author'' ​在缺少 ''​h-card''​时包括 compat根 ''​vcard''​。 
 +  *  ​''​category''​ 
 +  *  ''​rel=bookmark'' ​解析作 ​**''​u-url''​**. ​虽然不是类名或典型的微格式属性,rel=bookmark 是指示hentry永久链接的唯一方法。因此解析器应该在hentry中查找 ​rel=bookmark 超链接,并将它们的 "​href"​ 值作为**''​u-url''​**属性的值,包括处理任何相对URL解析。 
 +  *  ''​rel=tag''​ - 解析作 **''​p-category''​**.虽然不是类名,也不是典型的微格式属性,但rel=tag是标记一个hentry的典型方法。 因此,解析器应该在hentry中查找rel = tag超链接,并将其“href”值的最后一个路径段作为**''​p-category''​**属性的值。
  
-====  Compat FAQ === +提议: ([[https://github.com/​microformats/​h-entry/​issues/​7|follow-up in issue #7]]) 
-===  What about rel bookmark ==== +  *  ''​time.entry-date[[datetime]]''​ - in the absence of ''​published'',​ parse as **''​dt-published''​**. parse for the first ''&​lt;​time&​gt;''​ 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/​]]). 
-Also asked as: //Why use an h-entry ​u-url u-uid for permalinks when I have [[rel-bookmark|rel=bookmark]]?//+  *  ''​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.)
  
-A: tl;druse <​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).+====  Compat问答 === 
 +===  关于 rel bookmark ==== 
 +还有这样的问法//​我已经有 [[rel-bookmark|rel=bookmark]]了为什么还要使用 h-entry ​u-url u-uid 作为永久链接?​//
  
-rel=bookmark ​was the old [[hAtom]] way of marking up permalinks. Since then two factors have contributed to reducing use of rel inside microformats:​ +答: 太长了懒得读:使用 ''​class="​u-url u-uid"''​ 而不是 ''​rel=bookmark''​ 作为贴子的永久链接是因为它更简单 ​(更少的属性),对于上下文间工作得更好 ​(永久链接页,主页上的最近贴子,归档页中的贴子集合)
-  *  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.+rel=bookmark ​是老是 ​[[hAtom]] 标记永久链接的方法。在那时起,有两个因素促成在微格式中减少使用 rel : 
 +  *  rel 通常* 是在[[HTML5]]范围内的文档 ​因此不适合用于聚合的微格式。例如,在主页上的贴子集合或每个月的归档。 
 +  *  始终使用类名称作为属性更加容易。当格式使用两个(或多个!)在HTML中的属性来指定属性,混淆会导致数据质量 (标记和标记的内容)更差。因此根据简单[[simplicity]]的微格式原则[[principle]],在[[microformats2]]中,我们仅使用类名作为属性。
  
-===  Why rename entry-title entry-summary entry-content ==== +<nowiki>*</nowiki尽管rel=bookmark 在HTML5范围中是特别的文章元素 / 分李。[[http://​www.whatwg.org/​specs/​web-apps/​current-work/​multipage/​links.html#link-type-bookmark]], 但是典型的作者不会记住这些细节,因此任何格式依赖它都不大好。
-The <code>entry-*</codeclassnames 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.+===  为什么重命名 entry-title entry-summary entry-content === 
 +在经典 ​[[hAtom]] 中的 ''​entry-*''​ 类名前缀,因为要考虑词汇[[hCard]] 中的标题(如工作头衔,完全不同的语义)属性以及在[[hCalendar]]中的摘要属性 (参见: [[mf>​hatom-faq#​Could_hAtom_instead_use_title_content_and_summary|hAtom FAQ]]).
  
-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**.+遵循简单性[[simplicity]] 原则,在microformats2中,上述f ​**title** 的模糊性通过删除它一处理。 ​**name**现在在所有词汇表中均一致的用作 “名称” 微格式属性,因为用它来标记贴子的名称是有意义的。
  
-See also: [[http://​krijnhoetmer.nl/​irc-logs/​microformats/​20120830#​l-128|2012-08-30 IRC conversation]].+同样,添加entry到 **summary** 没有添加任何有用的信息,并且在实践中,博客文章摘要与条目摘要重叠没有问题,所以简化为**sunnary**是有意义的。 这同样适用于**entry-content**简化为**content**。
  
-=====  Related Work == +参见: [[http://krijnhoetmer.nl/irc-logs/microformats/​20120830#​l-128|2012-08-30 |IRC 交流]].
-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 ​==+=====  ​相关工作 ===== 
 +重用或基于 h-entry的工作:​ 
 +  *  [[https://​mailpile.pagekite.me:​8080/​p/​Open_Message_Format|Mailpile|开放信息格式]] 使用h-entry的结构化属性,例如 p-author h-card. 
 + 
 +=====  背景 =====
 This work is based on the existing [[hAtom]] microformat,​ and extensive selfdogfooding in the [[http://​indiewebcamp.com|indie web camp]] community. 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. 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.
  
行 338: 行 339:
 Beyond that, the following requirements must be met for adding or moving features (e.g. properties and values) to proposed, draft, or stable: 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_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. >​[[#​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. >​[[#​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. >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]]. 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]]   *  [[h-feed]]
   *  [[microformats2]]   *  [[microformats2]]