Microformats Wiki - User contributions [en]

existing-rel-values

2022-11-07T17:14:15Z

Barnabywalters: linked RFC6903 as defining spec for rel-about

{{DISPLAYTITLE: existing rel values }}

This page contains tables of known HTML rel values from specifications, formats, proposals, brainstorms, and non-trivial [[POSH]] usage in the wild. In addition, dropped and rejected values are listed at the end for comprehensiveness.

<span id="usage">usage</span>: see [[rel-faq#How_is_rel_used|how is 'rel' used]]. Regarding <span id="rev">rev</span>, see: [[rel-faq#Should_rev_even_be_used|should 'rev' even be used]].

This page is also the official rel registry ([https://html.spec.whatwg.org/multipage/links.html#other-link-types WHATWG HTML] ([http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#other-link-types original link]), [http://www.w3.org/TR/html5/links.html#other-link-types W3C HTML5]). Add new and proposed rel values to the following section:
* [[existing-rel-values#HTML5_link_type_extensions|HTML5 link type extension]]

== formats ==
These rel values are defined formats from specifications (HTML 4, microformats) are thus are <strong>recommended for general use</strong>. Alphabetically ordered by value.

Note:
* <strong>Do not</strong> add proposed rel values for HTML5 here, add them to the [[#HTML5_link_type_extensions|HTML5 link type extensions]] table.
* <strong>Do not</strong> add rel values you find in the wild to this table of rel formats, instead add them to the table in the [[existing-rel-values#POSH_usage|POSH section]].
* <strong>Do not</strong> add non-HTML rel values you find to this table of rel formats, instead add them to the table in the [[existing-rel-values#non_HTML_rel_values|non HTML rel values section]].
* <strong>Do not</strong> add rel values from obsolete/superceded proposals or drafts, instead add them to the table in the "dropped" section.

Sources:
* W3C Recommendations:
** [http://www.w3.org/TR/html401/types.html#h-6.12 HTML 4.01 section 6.12 Link types] (HTML4 Link types)
** [http://www.w3.org/TR/grddl/ Gleaning Resource Descriptions from Dialects of Languages] (GRDDL)
* [[microformats]] specifications
** [[xfn]]
** [[rel-license]]
** [[rel-nofollow]]

{| border="1"
|+
! Keyword
! Effect on <code>link</code>
! Effect on <code>a</code>, <code>area</code>
! Brief description <br />(from the relevant specification where possible)
! Link to defining specification

|-
| [[rel-acquaintance|acquaintance]]
| not allowed
| external relation
| the person represented by the current document considers the person represented by the referenced document to be an acquaintance
| [[XFN]]

|-
| [[rel-alternate|alternate]]
| external resource
| external relation
| Designates substitute versions for the document in which the link occurs. When used together with the <code>lang</code> attribute, it implies a translated version of the document. When used together with the <code>media</code> attribute, it implies a version designed for a different medium (or media).
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-appendix|appendix]]
| allowed
| allowed
| Refers to a document serving as an appendix in a collection of documents.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-bookmark|bookmark]]
| not allowed
| allowed
| Refers to a bookmark. A bookmark is a link to a key entry point within an extended document. The <code>title</code> attribute may be used, for example, to label the bookmark. Note that several bookmarks may be defined in each document.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-chapter|chapter]]
| allowed
| allowed
| Refers to a document serving as a chapter in a collection of documents.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-child|child]]
| external relation
| external relation
| The referenced person is a child of the person represented by the current document. It may also indicate that the target document is a hierarchical child, or subdocument, of the current document.
| [[XFN]], [https://www.w3.org/TR/relations.html HTML 4.0 Specification]

|-
| [[rel-colleague|colleague]]
| not allowed
| external relation
| the referenced person is a colleague of the person represented by the current document
| [[XFN]]

|-
| [[rel-contact|contact]]
| not allowed
| external relation
| the person represented by the current document considers the person represented by the referenced document to be a contact
| [[XFN]]

|-
| [[rel-contents|contents]]
| allowed
| allowed
| Refers to a document serving as a table of contents. Some user agents also support the synonym ToC (from "Table of Contents").
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-copyright|copyright]]
| allowed
| allowed
| Refers to a copyright statement for the current document.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-co-resident|co-resident]]
| not allowed
| external relation
| the referenced person lives in the same residence as the person represented by the current document
| [[XFN]]

|-
| [[rel-co-worker|co-worker]]
| not allowed
| external relation
| the referenced person is a co-worker of the person represented by the current document
| [[XFN]]

|-
| [[rel-crush|crush]]
| not allowed
| external relation
| this person considers the referenced person to be a crush (i.e. has a crush on the referenced person)
| [[XFN]]

|-
| [[rel-date|date]]
| not allowed
| external relation
| this person considers the referenced person to be a date (i.e. is dating the referenced person)
| [[XFN]]

|-
| [[rel-friend|friend]]
| not allowed
| external relation
| the person represented by the current document considers the person represented by the referenced document to be a friend
| [[XFN]]

|-
| [[rel-glossary|glossary]]
| allowed
| allowed
| Refers to a document providing a list of terms and their definitions that pertain to the current document.||[http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-help|help]]
| allowed
| allowed
| Refers to a document offering help (more information, links to other sources information, etc.)
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-its-rules|its-rules]]
| allowed
| not allowed
| Refers to a document with external ITS rules.
| [http://www.w3.org/TR/its20/#selection-global-html5 Internationalization Tag Set (ITS) Version 2.0]

|-
| [[rel-kin|kin]]
| not allowed
| external relation
| the referenced person is part of the extended family of the person represented by the current document
| [[XFN]]

|-
| [[rel-license|license]]
| allowed
| allowed
| …indicates that the <nowiki>[referenced document]</nowiki> is a license for the current page.
| [[rel-license]]

|-
| [[rel-me|me]]
| external relation
| external relation
| the referenced document represents the same person as does the current document
| [[XFN]]

|-
| [[rel-met|met]]
| not allowed
| external relation
| this person has met the referenced person
| [[XFN]]

|-
| [[rel-muse|muse]]
| not allowed
| external relation
| the referenced person inspires the person represented by the current document
| [[XFN]]

|-
| [[rel-neighbor|neighbor]]
| not allowed
| external relation
| the referenced person lives nearby the person represented by the current document
| [[XFN]]

|-
| [[rel-next|next]]
| external relation
| external relation
| Refers to the next document in a linear sequence of documents. User agents may choose to preload the "next" document, to reduce the perceived load time.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-nofollow|nofollow]]
| not allowed
| external relation
| indicates that the destination of that hyperlink {{should-not}} be afforded any additional weight or ranking by user agents which perform link analysis upon web pages (e.g. search engines).
| [[rel-nofollow]]

|-
| [[rel-parent|parent]]
| external relation
| external relation
| The referenced person is a parent of the person represented by the current document. It may also indicate that the target document is the hierarchical parent, or container, of the current document.
| [[XFN]], [https://www.w3.org/TR/relations.html HTML 4.0 Specification]

|-
| [[rel-prev|prev]]
| external relation
| external relation
| Refers to the previous document in an ordered series of documents. Some user agents also support the synonym "Previous".
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-previous|previous]]
| external relation
| external relation
| Synonym of <code>prev</code>
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-section|section]]
| allowed
| allowed
| Refers to a document serving as a section in a collection of documents.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-sibling|sibling]]
| not allowed
| external relation
| the referenced person is a sibling of the person represented by the current document
| [[XFN]]

|-
| [[rel-spouse|spouse]]
| not allowed
| external relation
| the referenced person is a spouse of the person represented by the current document
| [[XFN]]

|-
| [[rel-start|start]]
| allowed
| allowed
| Refers to the first document in a collection of documents. This link type tells search engines which document is considered by the author to be the starting point of the collection.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-stylesheet|stylesheet]]
| external resource
| not allowed
| a style sheet for the current document<br /> used with the invisible <link href> element which is not ideal for content relationships. Content relationships should be user visible and thus uses with <a href> are strongly preferred. Unfortunately the use of stylesheet in user visible content like <a href> appears to be strictly theoretical.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-subsection|subsection]]
| allowed
| allowed
| Refers to a document serving as a subsection in a collection of documents.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-sweetheart|sweetheart]]
| not allowed
| external relation
| this person considers the referenced person to be their sweetheart
| [[XFN]]

|-
| [[rel-tag|tag]]
| not allowed
| allowed
| …indicates that the <nowiki>[referenced document]</nowiki> is an author-designated "tag" (or keyword/subject) for the current page.
| [[rel-tag]]

|-
| [[rel-toc|toc]]
| allowed
| allowed
| Synonym of <code>contents</code> (from "Table Of Contents")
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-transformation|transformation]]
| allowed
| allowed
| Relates a source document to a transformation, usually represented in XSLT, that relates the source document syntax to the RDF graph syntax. Used in [[grddl|GRDDL]]
| [http://www.w3.org/TR/grddl/#transformation GRDDL]

|}

=== notes ===
*<code>rel="alternate"</code> can take further meaning from additional attributes, such as
** <code>rel="alternate" lang="fr"</code> (French language version of this page)
** <code>rel="alternate" media="print"</code> (printable version of this page)
** <code>rel="alternate" media="handheld"</code> (version of the page intended or better for handheld/portable devices like PDAs, cell phones, etc.)

*Synonyms such as "previous", "toc" are not as widely supported as the main term.

== proposals ==
A few rel values have been developed as drafts as a result of going through most of the microformats [[process]], and are thus listed here for your serious consideration. You <strong>may use these values</strong>, and if you find any problems with them please point them out on the respective "issues" page for the rel value.

{| border="1"
|+
! rel value !! summary !! proposed in !! external spec (if any)
|-
| [[rel-pronunciation|pronunciation]] || …indicates that the destination of the 'link' element is a document providing a pronunciation lexicon for speech-synthesis purposes. || [[rel-pronunciation]]
|-
| [[rel-directory|directory]] || …indicates that the destination of the hyperlink is a directory listing containing an entry for the current page. || [[rel-directory]]
|-
| [[rel-enclosure|enclosure]] || …indicates that the destination of that hyperlink is intended to be downloaded and cached. || [[rel-enclosure]] || [http://www.apps.ietf.org/rfc/rfc4287.html RFC4287]
|-
| [[rel-home|home]] || …indicates that the <nowiki>[referenced document]</nowiki> is the homepage of the site in which the current page appears. || [[rel-home]]
|-
| [[rel-payment|payment]] || …indicates that the destination of the hyperlink provides a way to show or give support (e.g. financial) for the current page|| [[rel-payment]]
|-
| vcs-* || …indicates that the destination of the hyperlink is the location of a Version Control System repository related to that page.|| || [https://joeyh.name/rfc/rel-vcs/ rel=vcs-*]
|}

== HTML5 link type extensions ==

The following values are registered as link type extensions per the [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#other-link-types requirements in the WHATWG HTML spec] and the [http://www.w3.org/TR/html5/links.html#other-link-types requirements in the W3C HTML5 spec].

Before you register a new value:
* '''Please check the [[#formats|Formats table]] and DO NOT re-register''' rel values that are already there. Please note that the W3C HTML WG has made a [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Decision] to drop <code>index</code>, <code>up</code>, <code>first</code> and <code>last</code> from the HTML5 spec itself.
* '''Please check the [[#dropped|Dropped table]] and DO NOT register''' values that are already there. If you believe a rel value was dropped from another specification without prejudice, please provide link/cite to explicit text/decision stating as such, e.g. the value was merely postponed, or perhaps expected to be spun-out into its own spec from the group developing that specification.

Note that entries in the [[#formats|Formats table]] and entries that are already in HTML5 as built-in keywords are also considered extensions with the "Ratified" status.

Please make sure that registrations added here have all the required data filled in ''including'':
* "Effect on link"
* "Effect on a and area" and
* a link to a spec that documents the keyword ''as an HTML <code>rel</code> keyword''. (A spec that merely defines the file format of the link target but does not define the <code>rel</code> keyword for use in HTML is not the kind of spec that is being required here.)

Entries lacking any of the above required data will likely be removed.

Changes to this registry will not be reflected in validators in real time. But validators will typically get automatically updated with the changes within one week or so

{| border="1"
|+
! Keyword
! Effect on <code>link</code>
! Effect on <code>a</code>, <code>area</code>
! Brief description
! Link to specification
! Synonyms
! Status

|-
| [[rel-about|about]]
| Hyperlink
| Hyperlink
| The resource linked to contains information about the current page.
| [https://www.rfc-editor.org/rfc/rfc6903.html#section-2 RFC6903]
| It might combine with [[rel-me]] or [[rel-author]] in links to an "about" section focused on an author
| proposed

|-
| [[rel-amphtml|amphtml]]
| Hyperlink
| Hyperlink
| Specify an alternate version of the document written in AMP HTML
| [https://github.com/ampproject/amphtml AMP HTML documentation]
| could be combined with rel=alternate
| proposed

|-
| [[rel-apple-touch-icon|apple-touch-icon]]
| External Resource
| Not allowed
| Specify a Webpage Icon for a “Web Clip”, or “touch icon”, for mobile devices (not limited to Apple devices).
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safariwebcontent/configuringwebapplications/configuringwebapplications.html Apple's Safari Web Content Guide]
| probably redundant with rel=icon
| proposed

|-
| [[rel-apple-touch-icon-precomposed|apple-touch-icon-precomposed]]
| External Resource
| Not allowed
| Specify a Webpage Icon for a “Web Clip”, or “touch icon”, for mobile devices (not limited to Apple devices).
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safariwebcontent/configuringwebapplications/configuringwebapplications.html Apple's Safari Web Content Guide]
| probably redundant with rel=icon
| proposed

|-
| [[rel-apple-touch-startup-image|apple-touch-startup-image]]
| External Resource
| Not allowed
| Specify a splashscreen for Web apps on iOS Safari
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safariwebcontent/configuringwebapplications/configuringwebapplications.html Apple's Safari Web Content Guide]
| maybe redundant with rel=icon with the sizes attribute?
| proposed

|-
| [[rel-archived|archived]]
| External Resource
| Hyperlink Annotation
| The target resource is archived and kept largely or solely for historical purposes.
| [https://sitemorse.com/rel-archived/ rel="archived" description]
|
| proposed

|-
| [[rel-attachment|attachment]]
| Hyperlink
| Hyperlink
| The resource linked to is "attached" to this document, similar to email attachments. Used in WordPress.
| No formal specification
|
| proposed

|-
| [[rel-authorization_endpoint|authorization_endpoint]]
| External Resource
| Not allowed
| Specify a hosted authorization server
| [https://www.w3.org/TR/indieauth/ IndieAuth spec]
|
| proposed

|-
| [[rel-canonical|canonical]]
| Hyperlink
| Hyperlink
| Specifies the canonical URL for the current document in order to help avoid duplicate content.
| [http://en.wikipedia.org/wiki/Canonical_meta_tag Canonical meta tag] [http://www.Google.com/support/webmasters/bin/answer.py?answer=139066#2 Canonicalization at Google Webmaster Central] [http://www.Bing.com/community/site_blogs/b/webmaster/archive/2009/02/12/partnering-to-help-solve-duplicate-content-issues.aspx Microsoft Webmaster Center] [http://www.YSearchBlog.com/2009/02/12/fighting-duplication-adding-more-arrows-to-your-quiver/ Yahoo! Search Blog]
|
| proposed

|-
| [[rel-category|category]]
| Hyperlink
| Hyperlink
| Refers to a category assigned to the current document or post. Implemented by WordPress for indicating a relation between a blog post and a category.
| [[rel-category]]
|
| proposed

|-
| [[rel-code-repository|code-repository]]
| Hyperlink
| Hyperlink
| indicates a code repository location. For link, it specifically indicates, in the case of server-generated content, the location of source code responsible for the generation of the current page, or, in the case of static files, where copies of the current page are housed). If the specific data/content built up at the page is stored separately from the generator (e.g., the code for a CMS vs. the specific CMS instance's SQL tables or JSON data files), this only refers to the generator and [[rel-content-repository|content-repository]] should be used to indicate the location for the storage of content. Otherwise, the code repository can be considered as also including the content. While the repository should contain its own license file, the [[rel-code-license|code-license]] rel-value is proposed as a direct pointer to the license (see also [[rel-content-license|content-license]]).
|
|
| proposed

|-
| [[rel-code-license|code-license]]
| Hyperlink
| Hyperlink
| indicates a license for code (a proposed broader replacement for [[rel-jslicense|jslicense]]). For link, it specifically indicates, in the case of server-generated content, the location of the license for all source code responsible for the generation of the current page, or, in the case of static files, the location of the license for all of these files). If the specific data/content built up at the page is stored separately from the generator (e.g., the code for a CMS vs. the specific CMS instance's SQL tables or JSON data files), this only refers to the generator and [[rel-content-license|content-license]] should be used to indication the license for the content. Otherwise, code-license can be considered as also covering the license of the content. Pointing to the repository containing the static or generator code files should be done with [[rel-code-repository|code-repository]] (and [[rel-content-repository|content-repository]] for any separate content).
|
|
| proposed

|-
| [[rel-component|component]]
| External Resource
| Not allowed
| Specify an HTML document that is treated as a component of this document.
| [https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html Web Components]
|
| proposed

|-
| [[rel-chrome-webstore-item|chrome-webstore-item]]
| External Resource
| Not allowed
| Link tag to declare for app and extensions inline installations hosted in the Chrome Web Store.
| [https://developers.google.com/chrome/web-store/docs/inline_installation Using Inline Installation]
|
| proposed

|-
| [[rel-content-repository|content-repository]]
| Hyperlink
| Hyperlink
| indicates a repository housing data content. For link, it specifically indicates, in the case of server-generated content, the location where separately housed data files used to populate the current page are stored (otherwise "code-repository" is sufficient to include content as well as code). If the specific data/content built up at the page is stored separately from the generator (e.g., the code for a CMS vs. the specific CMS instance's SQL tables or JSON data files), this only refers to the data/content files and [[rel-code-repository|code-repository]] should be used to indicate the location for the storage of the generator source files. Otherwise, [[rel-code-repository|code-repository]] can be considered as also including the content instead. While the repository should contain its own license file, the [[rel-content-license|content-license]] rel-value is proposed as a direct pointer to the license (see also [[rel-code-license|code-license]]).
|
|
| proposed

|-
| [[rel-content-license|content-license]]
| Hyperlink
| Hyperlink
| indicates a license for data content. For link, it specifically indicates, in the case of server-generated content, the location of the license for all separately housed data files used to populate the current page are stored, (otherwise "code-license" is sufficient to cover the license of content as well as code)). If the specific data/content built up at the page is stored separately from the generator (e.g., the code for a CMS vs. the specific CMS instance's SQL tables or JSON data files), this only refers to the data/content files and [[rel-code-license|code-license]] should be used to indication the license for the generator source files. Otherwise, code-license can be considered as also covering the license of the content. Pointing to the repository containing the data files should be done with [[rel-content-repository|content-repository]] (and [[rel-code-repository|code-repository]] for the static or generator code files).
|
|
| proposed

|-
| [[rel-dcterms.(property)#conformsTo|DCTERMS.conformsTo]]
| External Resource
| Not allowed
| An established standard to which the described resource conforms. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.conformsTo" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#contributor|DCTERMS.contributor]]
| External Resource
| Not allowed
| An entity responsible for making contributions to the resource. Examples include a person, an organization, or a service. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.contributor" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#creator|DCTERMS.creator]]
| External Resource
| Not allowed
| An entity primarily responsible for making the resource. Examples include a person, an organization, or a service. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.creator" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#description|DCTERMS.description]]
| External Resource
| Not allowed
| An account of the resource. Description may include but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.description" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#hasFormat|DCTERMS.hasFormat]]
| External Resource
| Not allowed
| A related resource that is substantially the same as the pre-existing described resource, but in another format. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#hasPart|DCTERMS.hasPart]]
| External Resource
| Not allowed
| A related resource that is included either physically or logically in the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#hasVersion|DCTERMS.hasVersion]]
| External Resource
| Not allowed
| A related resource that is a version, edition, or adaptation of the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isFormatOf|DCTERMS.isFormatOf]]
| External Resource
| Not allowed
| A related resource that is substantially the same as the described resource, but in another format. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isPartOf|DCTERMS.isPartOf]]
| External Resource
| Not allowed
| A related resource in which the described resource is physically or logically included. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isReferencedBy|DCTERMS.isReferencedBy]]
| External Resource
| Not allowed
| A related resource that references, cites, or otherwise points to the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isReplacedBy|DCTERMS.isReplacedBy]]
| External Resource
| Not allowed
| A related resource that supplants, displaces, or supersedes the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isRequiredBy|DCTERMS.isRequiredBy]]
| External Resource
| Not allowed
| A related resource that requires the described resource to support its function, delivery, or coherence. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isVersionOf|DCTERMS.isVersionOf]]
| External Resource
| Not allowed
| A related resource of which the described resource is a version, edition, or adaptation. <br />Changes in version imply substantive changes in content rather than differences in format. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#license|DCTERMS.license]]
| External Resource
| Not allowed
| A legal document giving official permission to do something with the resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.license" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#mediator|DCTERMS.mediator]]
| External Resource
| Not allowed
| An entity that mediates access to the resource and for whom the resource is intended or useful. In an educational context, a mediator might be a parent, teacher, teaching assistant, or care-giver. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.mediator" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#publisher|DCTERMS.publisher]]
| External Resource
| Not allowed
| An entity responsible for making the resource available. Examples include a person, an organization, or a service. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.publisher" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#references|DCTERMS.references]]
| External Resource
| Not allowed
| A related resource that is referenced, cited, or otherwise pointed to by the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#relation|DCTERMS.relation]]
| External Resource
| Not allowed
| A related resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#replaces|DCTERMS.replaces]]
| External Resource
| Not allowed
| A related resource that is supplanted, displaced, or superseded by the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#requires|DCTERMS.requires]]
| External Resource
| Not allowed
| A related resource that is required by the described resource to support its function, delivery, or coherence. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#rightsHolder|DCTERMS.rightsHolder]]
| External Resource
| Not allowed
| A person or organization owning or managing rights over the resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.rightsHolder" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#source|DCTERMS.source]]
| External Resource
| Not allowed
| A related resource from which the described resource is derived. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#subject|DCTERMS.subject]]
| External Resource
| Not allowed
| The topic of the resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-disclosure|disclosure]]
| Not allowed
| External Resource
| The 'disclosure' Link Relation Type designates a list of patent disclosures or a particular patent disclosure itself made with respect to material for which such relation type is specified.
| [http://tools.ietf.org/html/draft-yevstifeyev-disclosure-relation The 'disclosure' Link Relation Type]
|
| proposed

|-
| [[rel-discussion|discussion]]
| Hyperlink
| Hyperlink
| Refers to discussion of the current document or post.
| [[rel-discussion]]
|
| proposed

|-
| [[rel-donation|donation]]
| Hyperlink
| Hyperlink
| Indicates that the destination of the hyperlink provides a way to show or give support (e.g. financial) for the current page on a voluntary basis
| No formal specification
| Closely related to [[rel-payment]]
| proposed

|-
| [[rel-dns-prefetch|dns-prefetch]]
| External Resource
| Not allowed
| Tells the browser to perform dns lookup for host names ahead of use.
| [https://developer.mozilla.org/En/Controlling_DNS_prefetching Mozilla documentation] [http://dev.chromium.org/developers/design-documents/dns-prefetching Google documentation]
|
| proposed

|-
| [[rel-edit|edit]]
| Hyperlink
| Not allowed
| Tells the browser where the current page can be edited
| [http://universaleditbutton.org/Registered_MIME_type#Alternate_Linking_Scheme Universal Edit Button Alternate Linking Scheme]. Implemented in at least [http://mediawiki.org MediaWiki].
|
| proposed

|-
| [[rel-edituri|EditURI]]
| External Resource
| Not allowed
| A blogging auto discovery value, commonly used by WordPress
| [http://bitworking.org/projects/atom/draft-gregorio-09.html#Edit AtomAPI]
|
| proposed

|-
| [[rel-enclosure|enclosure]]
| External Resource
| External Resource
| Indicates that the referred resource is intended to be downloaded and cached.
| [[rel-enclosure]]
|
| proposed

|-
| [[rel-entry-content|entry-content]]
| Not allowed
| External Resource
| Indicates that the referenced document is an alternative display source for an Internet Explorer Web Slice.
| [http://msdn.microsoft.com/en-us/library/cc304073(VS.85).aspx#_alternative Web Slice format specification 0.9]
|
| proposed

|-
| [[rel-external|external]]
| Not allowed
| Hyperlink
| Indicates that the referenced document is not part of the same site as the current document.
| [[rel-external]]
|
| proposed

|-
| [[rel-first|first]]
| Hyperlink
| Hyperlink
| Indicates that the document is part of a sequence, and that the link is leading to the document that is the first logical document in the sequence.
| [https://www.w3.org/TR/2011/WD-html5-20110113/links.html#link-type-first W3C Working Draft 13 January 2011]
|
| proposed

|-
| [[rel-gbfs|gbfs]]
| External Resource
| Not allowed
| The location of the gbfs auto-discovery file
| [https://github.com/NABSA/gbfs/blob/master/gbfs.md General Bikeshare Feed Specification]
|
| proposed

|-
| [[rel-gtfs-static|gtfs-static]]
| External Resource
| Not allowed
| Indicates the associated GTFS Static file
| [https://developers.google.com/transit/gtfs/reference General Transit Feed Specification Reference]
|
| proposed

|-
| [[rel-gtfs-realtime|gtfs-realtime]]
| External Resource
| Not allowed
| Indicates the associated GTFS-Realtime file
| [https://developers.google.com/transit/gtfs-realtime/reference GTFS-realtime Reference]
|
| proposed

|-
| [[rel-home|home]]
| Hyperlink
| Hyperlink
| Refers to the top level document for the current document. It can be combined with 'alternate' to indicate a feed for the site of the current page.
| [[rel-home]]
| [[rel-root]]
| proposed

|-
| [[rel-hub|hub]]
| Hyperlink
| Hyperlink
| Refers to a hub that enables registration for notification of updates to the current page.
| [http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html#discovery PubSubHubbub Spec] [https://www.w3.org/TR/websub/ WebSub spec]
|
| proposed

|-
| [[rel-import|import]]
| External Resource
| Not allowed
| HTML Imports are a way to include and reuse HTML documents in other HTML documents.
| [http://www.w3.org/TR/html-imports HTML Imports]
|
| proposed

|-
| [[rel-in-reply-to|in-reply-to]]
| Hyperlink
| Hyperlink
| Refers to an original post that the current page is a comment on or reply to.
| [[rel-in-reply-to]]
|
| proposed

|-
| [[rel-root|root]]
| Hyperlink
| Hyperlink
| The target document is the root node of the hierarchical tree structure that hosts the current document
| No formal specification
| [[rel-home]]
| proposed

|-
| [[rel-index|index]]
| Hyperlink
| Hyperlink
| Refers to a document providing a list of topics with pointers that pertain to the current document.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]
|
| proposed

|-
| [[rel-issues|issues]]
| Hyperlink
| Hyperlink
| Refers to issues regarding the current document or specification.
| [[rel-discussion]]
|
| proposed

|-
| [[rel-jslicense|jslicense]]
| Hyperlink
| Hyperlink
| Refers to a document with JavaScript source code and license information (also called a [http://www.gnu.org/licenses/javascript-labels.html JavaScript License Web Labels] page). We might want choose a keyword for this that is more general -- there are many situations besides JavaScript in which it is desirable or required by license agreements (e.g., GNU GPL) to make an offer of both the source code and a copy of a license when distributing object code versions of a given work.
| [[rel-jslicense]]
|
| proposed

|-
| [[rel-last|last]]
| Hyperlink
| Hyperlink
| Indicates that the document is part of a sequence, and that the link is leading to the document that is the last logical document in the sequence.
| [https://www.w3.org/TR/2011/WD-html5-20110113/links.html#link-type-last W3C Working Draft 13 January 2011]
|
| proposed

|-
| [[rel-lightbox|lightbox]]
| Not allowed
| Img Pop-Up
| Images with this attribute are displayed in a larger way than embedded in a website (or how you specified it) when clicked (e.g. with installed "Lightbox 2"-Plugin). When adding [group] to rel="lightbox" all images get a clickable button for next/prev; insert into <code><a rel="lightbox[group]"><img src="http:example.com/img.jpg"></a></code>
| [http://lokeshdhakar.com/projects/lightbox2/ Lightbox 2] (needs actual specification to be kept in this list, this link is just documentation of one implementation)
|
| proposed

|-
| [[rel-lightvideo|lightvideo]]
| Not allowed
| Video Pop-Up
| Loads the video in a lightbox effect
| [https://www.drupal.org/node/252276 Lightbox2 - How to display video content]
|
| proposed

|-
| [[rel-main|main]]
| Hyperlink
| Hyperlink
| The current page is a subsection or a less important page than the target resource
| No formal specification
| It can be a synonym of [[rel-parent]] when the latter refers to a document and not a person. It differs however from [[rel-home]] and [[rel-root]], as the latter refer only to the topmost resource in the hierarchical tree structure (and in this case they may be combined with [[rel-main|main]]). Note that [[rel-main]] does not necessarily refer to a higher node in a tree structure, as the target resource can simply be a more important sibling node.
| proposed

|-
| [[rel-manifest|manifest]]
| External Resource
| Not allowed
| Imports or links to a manifest
| [http://w3c.github.io/manifest/#linking W3C Manifest for web application]
|
| proposed

|-
| [[rel-mask-icon|mask-icon]]
| External Resource
| Not allowed
| Specify a Webpage Icon for a “Pinned Tabs” on Safari 9.
| probably redundant with rel-icon
|
| proposed

|-
| [[rel-meta|meta]]
| External Resource
| Not allowed
| External metadata about the HTML document
| [http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/#section-rdf-in-HTML W3C's RDF/XML Syntax Specification]
|
| proposed

|-
| [[rel-micropub|micropub]]
| External Resource
| Not allowed
| the micropub endpoint for creating new posts
| [https://www.w3.org/TR/micropub/ Micropub scecification]
|
| proposed

|-
| [[rel-noopener|noopener]]
| Not allowed
| Annotation
| Requires that any browsing context created by following the hyperlink must not have an opener browsing context.
| [https://html.spec.whatwg.org/multipage/semantics.html#link-type-noopener 4.6.6.11 Link type ”noopener"]
|
| proposed

|-
| [[rel-openid.delegate|openid.delegate]]
| External Resource
| Not allowed
| When the page that contains the link is used as an OpenID indentifier, the relying party perform sOpenID 1.1 authentication with the link target as the identifier instead.
| [http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication OpenID Authentication 1.1]
|
| proposed

|-
| [[rel-openid.server|openid.server]]
| External Resource
| Not allowed
| The OpenID server for the relying party to contact for OpenID 1.1 authentication
| [http://openid.net/specs/openid-authentication-1_1.html#anchor4 OpenID Authentication 1.1]
|
| proposed

|-
| [[rel-openid2.local_id|openid2.local_id]]
| External Resource
| Not allowed
| When the page that contains the link is used as an OpenID indentifier, the relying party perform sOpenID 2.0 authentication with the link target as the identifier instead.
| [http://openid.net/specs/openid-authentication-2_0.html#rfc.section.7.3.3 OpenID Authentication 2.0]
|
| proposed

|-
| [[rel-openid2.provider|openid2.provider]]
| External Resource
| Not allowed
| The OpenID server for the relying party to contact for OpenID 2.0 authentication
| [http://openid.net/specs/openid-authentication-2_0.html#rfc.section.7.3.3 OpenID Authentication 2.0]
|
| proposed

|-
| [[rel-p3pv1|p3pv1]]
| External Resource
| Not allowed
| References a machine-readable privacy policy description in the P3P format
| [http://www.w3.org/TR/P3P/#syntax_link P3P spec]
|
| proposed

|-
| [[rel-pgpkey|pgpkey]]
| External Resource
| Not allowed
| Associates a PGP key with a Web page so that the Web page URL can be used as the commenter's URL in PGP-signed blog comments and the blogging system receiving the comment can fetch the key and verify the signature as belonging to the owner of the URL.
| [http://golem.ph.utexas.edu/~distler/blog/archives/000320.html PGP-Signed Comments]
|
| proposed

|-
| [[rel-pingback|pingback]]
| External Resource
| Not allowed
| gives the address of the pingback server that handles pingbacks to the current document
| [http://www.hixie.ch/specs/pingback/pingback Pingback]
|
| proposed

|-
| [[rel-preconnect|preconnect]]
| External Resource
| Not allowed
| Indicates an origin that will be used to fetch required resources. Initiating an early connection, which includes the DNS lookup, TCP handshake, and optional TLS negotiation, allows the user agent to mask the high costs of connection establishment latency.
| [http://www.w3.org/TR/resource-hints/ Resource Hints Working Draft]
|
| proposed

|-
| [[rel-prerender|prerender]]
| External Resource
| External Resource
| Prerenders the Web page targeted by the link including running it scripts.
| [[rel-prerender]]
|
| proposed

|-
| [[rel-profile|profile]]
| External Resource
| Contextual External Resource
| indicate[s] that the destination of that hyperlink is a metadata profile (e.g. an [[XMDP]] profile) for the current page or portion thereof. See also [[xmdp-brainstorming]].
| [http://microformats.org/wiki/rel-profile rel-profile]
|
| proposed

|-
| [[rel-publisher|publisher]]
| External Resource
| External Resource
| Indicates that the referenced document is a metadata profile (e.g., a social-media/real-name profile such as a Google+ profile) for the publisher of the current page, or some portion of the current page.
| [https://support.google.com/plus/answer/1713826?hl=en Google help page]
|
| proposed

|-
| [[rel-radioepg|radioepg]]
| External Resource
| External Resource
| Indicates that the referenced document is a RadioDNS Service Information document (ETSI TS 102 818 s10.2.3) containing information on the radio station that publishes the current page
| [https://radiodns.org/developers/documentation RadioDNS Documentation]
|
| proposed

|-
| [[rel-rendition|rendition]]
| External Resource
| External Resource
| Indicates some example rendering, interpretation, or depiction of the source. User agents may choose to execute, display, or render the target in-place; or navigate to the target.
| [http://www.globalmentor.com/specs/html-rel-rendition/ HTML rel rendition]
|
| proposed

|-
| [[rel-reply-to|reply-to]]
| External Resource
| Hyperlink
| indicates any mailbox(es) (i.e. email addresses) to which responses are to be sent. ''Note: this is distinct from the 'in-reply-to' value which refers to the originating document, not to the address where comments should be sent.
| [http://tools.ietf.org/html/rfc2822 RFC2822] (originally [http://tools.ietf.org/html/rfc822#section-4.4.3 RFC822])
|
| ratified

|-
| [[rel-schema.DCTERMS|schema.DCTERMS]]
| External Resource
| Not allowed
| Maps the prefix "DCTERMS" for use in other Dublin-Core related link relations (such as DCTERMS.creator) and meta keywords
| [http://dublincore.org/documents/dc-html/#sect-4.2 Section 4.2 of "Expressing Dublin Core metadata using HTML/XHTML meta and link elements"]
| see also [https://wiki.whatwg.org/wiki/MetaExtensions "WhatWG MetaExtensions Wiki] for usage examples in meta keywords
| proposed

|-
| [[rel-service|service]]
| External Resource
| Not allowed
| Atom Publishing Protocol editing service autodiscovery.
| [http://wiki.whatwg.org/wiki/ServiceRelExtension Documentation on the WHATWG wiki]
|
| proposed

|-
| [[rel-shortlink|shortlink]]
| External Resource
| Not allowed
| Specifies the preferred shortened URL for the page.
| [http://code.google.com/p/shortlink/wiki/Specification shortlink spec]
|
| proposed

|-
| [[rel-sidebar|sidebar]]
| Hyperlink
| Hyperlink
| Indicates that the referenced document is intended to be shown in a secondary browsing context.
| [[rel-sidebar]]
|
| proposed

|-
| [[rel-sitemap|sitemap]]
| External Resource
| Not allowed
| Provides a link to an XML document describing the layout of the site.
| [[rel-sitemap]]
|
| proposed

|-
| [[rel-subresource|subresource]]
| External Resource
| Not allowed
| An external resource intended for use within the current page.
| [http://www.chromium.org/spdy/link-headers-and-server-hint/link-rel-subresource Chromium documentation]
|
| proposed

|-
| [[rel-sword|sword]]
| Hyperlink
| Not allowed
| SWORD is a lightweight protocol for remotely depositing content into repositories. .[http://swordapp.org/ The SWORD project]
| [[rel-sword]]
|
| proposed

|-
| [[rel-syndication|syndication]]
| Hyperlink
| Hyperlink
| Refers to a page which is a syndicated copy of the current page.
| [[rel-syndication]]
|
| proposed

|-
| [[rel-timesheet|timesheet]]
| External Resource
| Not allowed
| Applies a timesheet to the document.
| [http://www.w3.org/TR/timesheets/#smilTimesheetsNS-Elements-Timesheet non-normative section in the Timesheet spec]
|
| proposed

|-
| [[rel-token_endpoint|token_endpoint]]
| External Resource
| Not allowed
| Specify an HTTP endpoint that Micropub clients can use to obtain an access token given an authorization code
| [https://www.w3.org/TR/indieauth/ IndieAuth spec]
|
| proposed

|-
| [[rel-webmention|webmention]]
| External Resource
| Hyperlink
| gives the address of the webmention endpoint that handles webmentions to the current document
| [https://www.w3.org/TR/webmention/ Webmention specification]
|
| proposed

|-
| [[rel-widget|widget]]
| External Resource
| External Resource
| Autodiscovery for W3C widgets
| [http://dev.w3.org/2006/waf/widgets/Overview.html#linking-to-a-widget-package-from-a-html- non-normative section in the Widget packaging spec]
|
| proposed

|-
| [[rel-wlwmanifest|wlwmanifest]]
| External Resource
| Not allowed
| Windows Live Writer manifest autodiscovery
| [http://msdn.microsoft.com/en-us/library/bb463263.aspx documentation on MSDN]
|
| proposed

|-
| [[rel-image_src|image_src]]
| External Resource
| Not allowed
| Specify a Webpage Icon for use by Facebook, Yahoo, Digg, etc.
| Unknown, but see for instance [http://www.niallkennedy.com/blog/2009/03/enhanced-social-share.html this]
| probably redundant with rel=icon
| proposed

|-
| [[rel-cmis-acl|http://docs.oasis-open.org/ns/cmis/link/200908/acl]]
| External Resource
| External Resource
| Identifies the resource containing a CMIS ACL document for the link context
| [http://docs.oasis-open.org/cmis/CMIS/v1.0/cs01/cmis-spec-v1.0.html#_Toc243905525 CMIS 1.0, Section 3.4.3.4]
|
| proposed

|-
| [[rel-stylesheet/less|stylesheet/less]]
| External Resource
| Not allowed
| Less CSS framework stylesheets.
| [http://lesscss.org/#-client-side-usage Less CSS usage]
|
| proposed

|-
| [[rel-yandex-tableau-widget|yandex-tableau-widget]]
| External Resource
| Not allowed
| Lets webmasters configure the appearance of their own site widgets in Yandex.Browser
| [https://api.yandex.com/tableau/ Yandex's Tableau API]
|
| proposed

|}

== brainstorming ==
Several rel values are being brainstormed as potential microformats and are thus listed here. If you find you have a use for such semantics in real world examples, <strong>consider trying out</strong> these values and provide feedback on the respective brainstorming page(s) with your results and experiences.

You may list new proposed rel values here, and even better if you can list and link to POSH uses in the wild.

{| border="1"
|+
! rel value !! summary !! brainstormed in and usage in the wild

|-
| [[rel-accessibility|accessibility]] || indicate[s] that the destination of that hyperlink contains accessibility information for the current page. || [http://www.brucelawson.co.uk/2009/rel-accessibility/ blog post] which itself uses the rel value in a <link> tag in the head of the document.

|-
| [[rel-author|author]] || indicate[s] that the destination of that hyperlink represents the author of the current page. Combines with [[rel-me|rel-me]] to chain authorship information. || Google has said it will index rel-Author in this [http://googlewebmastercentral.blogspot.com/2011/06/authorship-markup-and-web-search.html blog post], with further [http://www.google.com/support/webmasters/bin/answer.py?answer=1229920 discussion of the rel-me connection] See also [http://dev.w3.org/html5/spec/Overview.html#link-type-author the HTML5 spec]

|-
| [[rel-bibliography|bibliography]] || indicate[s] that the destination of that hyperlink is a bibliography for the current page. || [http://microformats.org/discuss/mail/microformats-discuss/2007-October/010863.html mailing list post, 2007-10-15]

|-
| [[rel-cite|cite]] || indicate[s] that the destination of that hyperlink is an authoritative source or a precedent to the current page. || [[distributed-conversation-brainstorming]]

|-
| [[rel-group|group]] || the referenced document represents a group to which the person represented by the current document belongs || [[group-brainstorming]]

|-
| <span id="longdesc">[[rel-longdesc|longdesc]]</span> || Alternative to the img longdesc attribute, for use on visible links || [http://www.google.com/search?q=rel%3D%22longdesc%22 Google search for rel=longdesc in the wild] shows many sources of proposals. Please edit this to list the earliest and perhaps most recent/comprehensive proposal. No known real world POSH usage in the wild yet.

|-
| [[rel-map|map]] || Link to a map. Possibly embedded within an adr, hCard, geo or hCalendar. Parsers {{may}} attempt to parse the URL if it is a link to a known map site (e.g. Geohash, Google Maps, Multimap) and extract co-ordinates and other useful data. || (to [[User:TobyInk|TobyInk]] by email)

|-
| [[rel-member|member]] || the referenced document represents a member of the group represented by the current document || [[group-brainstorming]]

|-
| [[rel-m_PageScroll2id|m_PageScroll2id]] || JS to scroll to a defined ID || [[group-brainstorming]]

|-
| [[rel-prefetch|prefetch]] || indicates the URL and content-type of a resource that is likely to be a required resource when the next action or navigation is triggered. Initiating an early fetch allows the user agent to mask the request latency of the resource and make it available sooner to the application.|| [https://igrigorik.github.io/resource-hints/#prefetch resource hints draft]

|-
| [[rel-preload|preload]] || indicates the URL and content-type of a resource that should be fetched as early as possible by the user agent. Initiating an early fetch allows the user agent to mask the request latency of the resource and make it available sooner to the application.|| [https://igrigorik.github.io/resource-hints/#preload resource hints draft]

|-
| [[rel-prerender|prerender]] || indicates the URL of the next navigation target. Initiating a prerender allows the user agent to deliver an instant navigation experience: the user agent downloads the top-level resource and its assets, and performs all of the processing steps required to show the page without actually showing it to the user.|| [https://igrigorik.github.io/resource-hints/#prerender resource hints draft]

|-
| [[rel-profile|profile]] || indicate[s] that the destination of that hyperlink is a metadata profile (e.g. an [[XMDP]] profile) for the current page or portion thereof || [[xmdp-brainstorming]]

|-
| [[rel-shortlink|shortlink]] || the referenced document represents the current document but with a shorter URL || [http://samj.net/2009/04/introducing-relshort-better-alternative.html blog post]
|-
| source || the referenced document represents the source code for the current document or project || [[source-brainstorming]] [http://adactio.com/journal/6667/ blog post]

|-
| vcalendar-parent || link from an event to a containing event || [[User:TobyInk/hcalendar-1.1|hCalendar 1.1 draft]]
|-
| vcalendar-child || link from an event to a contained event || [[User:TobyInk/hcalendar-1.1|hCalendar 1.1 draft]]
|-
| vcalendar-sibling || link from an event to a related event with the same container || [[User:TobyInk/hcalendar-1.1|hCalendar 1.1 draft]]

|-
| [[rel-status|status]] || the referenced document represents the status (or source of status updates) for the author of this document || [http://monkinetic.com/2009/11/24/status-autodiscovery-relstatus.html blog post]

|-
| https://api.w.org/ || Link to Wordpress API || [https://wordpress.org/themes/twentysixteen/ Official Wordpress theme]

|}

=== more brainstorming ===
See also:
* [[genealogy-brainstorming]] for some thoughts on possible additional values for family relationships (use existing [[XFN]] [[rel-parent|parent]], [[rel-child|child]], [[rel-sibling|sibling]], [[rel-spouse|spouse]], [[rel-kin|kin]] values first though)
* [[xpn-brainstorming]] for some thoughts on possible additional values for professional relationships (use existing [[XFN]] [[rel-co-worker|co-worker]], [[rel-colleague|colleague]] values first though)

== POSH usage ==
There are numerous rel values used as [[POSH]], both in the wild, whose origins are not necessarily known, nor are their meanings consistent. There are also numerous rel values from external proposals of varying degrees of merit. It is useful to document their existence and summarize their implied meanings/usage intent as research that may be used to perhaps take one or more of them thru the microformats [[process]] if there is both sufficient interest and sufficient in the wild usage.

Note: If a value is missing from this table, it may have either already been promoted by writing it up as a proposal, or demoted by being explicitly dropped. Please check the other tables first before adding to this table.

Note: this list is incomplete, please help complete it from the following sources:

External sources:
* [http://developer.mozilla.org/about/meta Meta Information in DevMo Docs] (DevMo)
* [http://wiki.mozilla.org/Microsummaries Microsummary]
* [http://lachy.id.au/dev/markup/specs/wclr/ Web Communication Link Relationships] (WCLR)
* [http://www.w3.org/MarkUp/Relationships.html W3C Link Relationship values draft] (LRdraft) - from a draft of the HTML spec circa 1991.
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/section-links.html#linkTypes HTML5 draft] '''Liable to change'''
* [http://wiki.foaf-project.org/Autodiscovery FOAF Project Wiki: Autodiscovery] (FOAF)
* [http://www.apps.ietf.org/rfc/rfc4685.html RFC4685]
* [http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html Google Blog]

{| border="1"
|+
! rel value !! summary !! origin !! proposal(s)

|-
| [[rel-archive|archive]] || index of archived entries || unknown, perhaps Wordpress open source blogging software || WCLR

|-
| [[rel-archives|archives]] || Provides a link to a collection of records, documents, or other materials of historical interest. || || HTML5

|-
|[[rel-author|author]]||see brainstorming above for suggested use by google||unknown || DevMo / HTML5

|-
| [[rel-canonical|canonical]] || To help search engines disambiguate the same page with multiple representations || Google || [http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html Google]/[http://www.bing.com/community/blogs/webmaster/archive/2009/02/12/partnering-to-help-solve-duplicate-content-issues.aspx Microsoft]/[http://www.ysearchblog.com/2009/02/12/fighting-duplication-adding-more-arrows-to-your-quiver/ Yahoo!], [http://blog.ask.com/2009/02/ask-is-going-canonical.html Ask Jeeves]

|-
| [[rel-comment|comment]] || … || … || WCLR

|-
| [[rel-contribution|contribution]] || … || … || WCLR

|-
| [[rel-edituri|EditURI]]
| Location of the xml-rpc gateway for a Wordpress install that allows external programs to add, edit and delete posts. Used by "[http://codex.wordpress.org/Weblog_Client WordPress blog client]" software for automating posting and updating blog content from your desktop. || Seen in [http://www.wordpress.org/ WordPress], e.g. [http://www.tom-watson.co.uk/]. || Description stubbed in [[rel-edituri]].

|-
| [[rel-endorsed|endorsed]] || … || … || WCLR

|-
| [[rel-fan|fan]] || xxxx. || … || [[hcard-user-profile-authoring]]

|-
| [[rel-feed|feed]] || Gives the address of a syndication feed for the current document. || … || WCLR/ HTML5

|-
| [[rel-footnote|footnote]] || Location of the footnote on a link to a footnote. || Markdown preprocessors such as [http://maruku.rubyforge.org/ Maruku] || HTML5

|-
| [[rel-icon|icon]] || Imports an icon to represent the current document. (Allowed in <code>link</code> only) || [http://dev.w3.org/html5/spec-LC/links.html#rel-icon HTML5] || WCLR/HTML5

|-
| [[rel-kinetic-stylesheet|kinetic-stylesheet]] || Imports a [http://kssproject.org/ KSS] 'kinetic stylesheet' to bind dynamic behavior to elements || Used in the [http://plone.org Plone] Content Management System || …

|-
| [[rel-lightbox|lightbox]] || Hook - Indicates that following the link will trigger a "lightbox" script (Allowed in <code>link</code> only) || ([http://www.google.co.uk/search?q=rel%3D%22lightbox%22 Google search for rel=lightbox in the wild]) Use "lightbox" instead of "clearbox" or "prettyPhoto" || …

|-
| [[rel-made|made]] || … || … || LRdraft

|-
| [[rel-meta|meta]] || … || [http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/#transport 1999 W3C RDF syntax REC] || FOAF

|-
| [[rel-microsummary|microsummary]]|| … || … ||[http://wiki.mozilla.org/Microsummaries Microsummary], be aware of: [[page-summary-formats#Issues_2|microsummary issues]]

|-
| [[rel-noreferrer|noreferrer]] || indicates that no referrer information is to be leaked when following the link. || [http://dev.w3.org/html5/spec-LC/links.html#rel-noreferrer HTML5] || HTML5

|-
| [[rel-openid-delegate|openid.delegate]] || … || ([http://www.google.co.uk/search?q=%22rel%3Dopenid%22 Google search for rel=openid.* in the wild]) || …

|-
| [[rel-openid-server|openid.server]] || … || ([http://www.google.co.uk/search?q=%22rel%3Dopenid%22 Google search for rel=openid.* in the wild]) || …

|-
| [[rel-permalink|permalink]] || indicate a permanent link for some, or all, content within the document. obsolete; use <code>bookmark</code> instead. || … || WCLR

|-
| [[rel-pgpkey|pgpkey]] || (see also rel-publickey) || … || [http://golem.ph.utexas.edu/~distler/blog/archives/000320.html], [http://golem.ph.utexas.edu/~distler/blog/archives/000325.html]

|-
| [[rel-pingback|pingback]] || Gives the address of the pingback server that handles pingbacks to the current document. (Allowed in <code>link</code> only) || … || WCLR/ HTML5

|-
| [[rel-popover|popover]] || Used by a JS widget to display a large, descriptive tooltip. || [http://twitter.github.com/bootstrap Twitter's Bootstrap] [http://twitter.github.com/bootstrap/javascript.html#popovers Popover.js] || …

|-
| [[rel-prefetch|prefetch]] || Specifies that the target resource should be pre-emptively cached. (Allowed in <code>link</code> only) || … || HTML5

|-
| [[rel-privacy|privacy]] || Specifies that the target resource is the privacy policy. || … || …

|-
| [[rel-publickey|publickey]] || (see also rel-pgpkey) || … || [http://rasterweb.net/raster/2002/12/12/20021212072812/]

|-
| [[rel-referral|referral]] || … || … || WCLR

|-
| [[rel-related|related]] || … || … || WCLR

|-
| [[rel-replies|replies]] || indicates a continued thread || unknown || [http://www.apps.ietf.org/rfc/rfc4685.html RFC4685]

|-
| [[rel-respond-proxy|respond-proxy]] || Working with respond.js - proxy on external server || [https://github.com/scottjehl/Respond] || [https://github.com/scottjehl/Respond]

|-
| [[rel-respond-redirect|respond-redirect]] || Working with respond.js - redirect location on local server || [https://github.com/scottjehl/Respond] || [https://github.com/scottjehl/Respond]

|-
| [[rel-resource|resource]] || … || … || WCLR

|-
| [[rel-search|search]] || … || unknown || unknown

|-
| [[rel-sitemap|sitemap]] || Links to a site map document. || … || http://www.sitemaps.org/

|-
| [[rel-sponsor|sponsor]] || … || … || WCLR

|-
| [[rel-tooltip|tooltip]] || Used by a JS widget to display a tooltip similar (though more customizable) to what is shown by browsers if the 'title' attribute is present. || [http://twitter.github.com/bootstrap Twitter's Bootstrap] [http://twitter.github.com/bootstrap/javascript.html#tooltips Tooltip.js] (and likely other JS tools) || …

|-
| [[rel-trackback|trackback]] || … || unknown, perhaps open source Movable Type blogging software || WCLR

|-
| [[rel-unendorsed|unendorsed]] || (probably redundant to [[rel-nofollow|nofollow]]) || … || WCLR

|-
| [[rel-user|user]] || … || … || WCLR
|-
| [[rel-wlwmanifest|wlwmanifest]] || Used by "[http://explore.live.com/windows-live-writer Windows Live Writer]," a Microsoft [http://codex.wordpress.org/Weblog_Client blog client] for automating posting and updating blog content from your desktop. || Seen in [http://www.wordpress.org/ WordPress], e.g. [http://www.tom-watson.co.uk/]. Similar values are probably used by other blog content management systems as well. || …

|}

=== WCLR ===

The WCLR proposal is described by its author (in e-mail, 2007-09-25) as:

<blockquote>
<p>…now effectively obsolete, since HTML5 and Microformats cover all the worthwhile relationships in that already.</p>

These are [http://www.whatwg.org/specs/web-apps/current-work/multipage/section-links.html#linkTypes covered by HTML5 already]:

* permalink -> bookmark
* archive -> archives
* feed
* pingback
* unendorsed -> nofollow

The rest now seem unnecessary.
</blockquote>

Nonetheless, there may be some mileage in using them in microformats, at least until HTML5 is widely available.

== Dublin Core ==
In the past, Dublin Core values have been added to this page in the table about HTML5 features, but no examples, nor an actual specification explicitly stating how the value(s) should be used in HTML could be found. The linked specifications below have been updated so we should start considering Dublin Core values accordingly.

{| border="1"
|+
! rel value !! summary !! source
|-
| schema.DC || a specification of all metadata terms maintained by the Dublin Core Metadata Initiative, with regard to the fifteen terms of the Dublin Core Metadata Element Set already published || [http://www.dublincore.org/documents/dcq-html/ Dublin Core]

|-
| schema.DCTERMS || a specification of all metadata terms maintained by the Dublin Core Metadata Initiative, reflecting the changes described more fully in the 2012 document "Maintenance changes to DCMI Metadata Terms" [http://dublincore.org/usage/decisions/2012/dcterms-changes/] || [http://www.dublincore.org/documents/dcq-html/ Dublin Core]
|-
|}

'''Issues need updating given new information from linked resources.'''

Notes:
* Dublin Core. This search may help: [http://www.google.co.uk/search?as_q=rel%3Dschema.*&hl=en&num=10&btnG=Google+Search&as_epq=&as_oq=&as_eq=&lr=&as_ft=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=http%3A%2F%2Fdublincore.org&as_rights=&safe=images].
** '''examples from that search only use invisible <code><link href></code> element'''. At first glance it appears the results from the search show only uses with the invisible <code><link href></code> element which is not ideal for content relationships. Content relationships should be user visible and thus uses with <code><a href></code> are strongly preferred.
*** [http://www.ietf.org/rfc/rfc2731.txt RFC2731] defines <code>rel="schema.AC"</code> and <code>rel="schema.RC"</code> with the pattern <code>rel="schema.PREFIX"</code> as a syntax for defining namespaces for use in meta[@name], *[@rel], *[@rev] and (as per eRDF) *[@class] attributes. A link to a Dublin Core metadata schema is generally not suitable for end users, so <code><link href></code> appears to be more appropriate than <code><a href></code> for those that use Dublin Core metadata schemas.
*** The scheme proposed above provides metadata namespace declarations. As described by DCMI specifications, such indications '''cannot''' be provided w/o a suitable namespace. In order to give complete pieces of information, the correct description set must be: <code><link rel="schema.DCTERMS" href="http://purl.org/dc/terms/"></code> (for the namespace declaration, followed by) <code><meta name="DCTERMS.<nowiki>[element]</nowiki>" content="<nowiki>[element.value]</nowiki>"></code> for related elements.
**** Note: [http://purl.org/dc/terms/ schema.DCTERMS] is conventionally related to an upgraded elements list than [http://purl.org/dc/elements/1.1/ schema.DC] and should be preferred as rel values. Both are discussed here for subject completeness)
** '''proposal to use in content currently only theoretical'''. Thus unfortunately the use of Dublin Core in user visible content like <code><a href></code> appears to be strictly theoretical. See [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011445.html microformats-discuss/2008-January/011445.html] for a proposal to use Dublin Core in user visible content.
*** '''recent improvements'''. DCMI solves some trouble concerning metadata through the ''description set model''. Some of these informations cannot currently be provided in any standard ways other than DC, namely dates, validity and periodicity. Following this public bug report ([https://www.w3.org/Bugs/Public/show_bug.cgi?format=multiple&id=22520]), the correct namespace declaration for DC and DCTERMS metadata are now considered valid HTML code. We '''must''' encourage this practice both for internal usefulness and for shared practices.

* The Dublin Core document [http://dublincore.org/documents/dc-html/ "Expressing Dublin Core metadata using HTML/XHTML meta and link elements"] is a specification for, and gives examples of, both <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> and <link rel="schema.DCTERMS" href="http://purl.org/dc/terms/">. Note that Dublin Core encourages the use of DCTERMS elements over DC. A list of projects which use Dublin Core metadata is maintained [http://dublincore.org/projects/ here].
* [http://dublincore.org/documents/dc-html/ "Expressing Dublin Core metadata using HTML/XHTML meta and link elements"] also includes examples of <link rel="DCTERMS.[element]" href="">, where [element] = subject, isReferencedBy, creator, and publisher. The <link> tag is used instead of the <meta> tag whenever the content is a URL. (Note that this use is different from, but related to, <link rel="schema.DCTERMS" href="">.) Potentially, ''any'' of the 55 DCTERMS elements could be used in this way, and this could include use in HTML 5.
** As said before, HTML5 validators now allow the use of <code><link rel="schema.DCTERMS" href="http://purl.org/dc/terms/"></code> for namespace declarations.

* According to DCMI specification linked above, as well as [http://dublincore.org/documents/dc-html/ "Expressing Dublin Core metadata using HTML/XHTML meta and link elements"] documentation, HTML5 @rel attribute proposed values table has been updated. It now includes a subset of DCMI ''/terms/'' namespace properties, more specifically those whose value can (or must) be logically expressed by a resource, so that the "href" attribute value becomes a non-literal value surrogate referring to the resource itself.
** Elements from ''/elements/1.1/'' namespace have not been included on purpose. According to [http://wiki.dublincore.org/index.php/FAQ/DC_and_DCTERMS_Namespaces "FAQ/DC and DCTERMS Namespaces"], the old namespace is maintained for legacy purposes only and it is not as suitable for non-literal values as the ones denoted by <code><link></code> elements.

== Use with HTTP Link Header ==
You can also use any of the rel values (that are allowed for link elements) with HTTP Link Headers,

Example: returning a Javascript file with a license (since JS itself has no way to indicate a license)
<source lang=text>
Link: <http://creativecommons.org/publicdomain/zero/1.0/>; rel="license"
</source>

For multiple licenses (e.g. CC-SA and GPL), simply use multiple <code>Link:</code> headers.
<source lang=text>
Link: <http://creativecommons.org/licenses/by-sa/3.0/>; rel="license"
Link: <http://www.gnu.org/licenses/gpl.html>; rel="license"
</source>

Example: similarly, linking to a copyright statement for an image:
<source lang=text>
Link: <http://example.org/copyright.html>; rel="copyright"
</source>
or providing a brief inline copyright statement:
<source lang=text>
Link: <data:text/plain;charset=utf-8,Copyright 2013 ExampleCo, All Rights Reserved.>; rel="copyright"
</source>

== unspecified ==
Some rel values have been added to this page perhaps in one of the tables above, but no examples, nor an actual specification explicitly stating that the value(s) should be used in the HTML 'rel' attribute could be found. They are listed here in the hopes someone can discover more specific/precise URLs to examples or specifications about them (preferably both). Until such precise URLs to examples/specs are provided, the values can be treated as they are purely theoretical and thus of little interest.

A simple list here is sufficient.

== non HTML rel values ==
There are markup languages other than HTML that also have a rel attribute, often based upon the HTML rel attribute.
It is useful to document some of these other languages and their rel values for both reference purposes, and to provide background research for the possible development and re-use of these values in HTML, as [[poshformats]] or [[microformats]]

Sources:
* [[Atom]] [[RFC4287]] specification.
* See http://www.iana.org/assignments/link-relations.html for more.
* See [http://amundsen.com/media-types/maze/format/#link-relations Maze+XML]
* See [http://amundsen.com/media-types/collection/format/#link-relations Collection+JSON]
* See [http://www.opensearch.org/Specifications/OpenSearch/1.1#Url_rel_values OpenSearch]
* See [http://tools.ietf.org/html/rfc6861 The Create-Form and Edit-Form Link Relations (RFC6861)]
* See [http://rels.messages.io Workflow-Related Link Relations at Messages.io]

{| border="1"
|+
! rel value !! summary<br />(from the relevant specification where possible)) !! defining specification

|-
| self
| From http://www.ietf.org/rfc/rfc4287.txt : <blockquote>The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.</blockquote>
| [[Atom]] http://www.ietf.org/rfc/rfc4287.txt

|-
| http://gdata.youtube.com/schemas/2007#in-reply-to || See http://code.google.com/apis/youtube/2.0/developers_guide_protocol_comments.html || YouTube extension to Atom

|-
| collection || Refers to a resource which represents a collection of which the current resource is a member.

When used in the Maze+XML media type, the associated URI returns the available collection of mazes.
|| Maze+XML, Collection+JSON, OpenSearch

|-
| compensatingtx || Link to a resource representing information about a compensating transaction for each member transaction of a [http://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf Long-Lived Compensating Transaction] || See [http://rels.messages.io/#compensatingtx Compensating Transaction Link Relation]

|-
| east || Refers to a resource to the "east" of the current resource.

When used in the Maze+XML media type, the associated URI points to a neighboring cell resource to the east in the active maze.

|| Maze+XML

|-
| events || Link to a collection resource representing a list of subscribe-able events. || See [http://rels.messages.io/#events Events Link Relation]

|-
| exit || Refers to a resource that represents the exit or end of the current client actvity or process.

When used in the Maze+XML media type, the associated URI points to the final exit resource of the active maze.

|| Maze+XML

|-
| north || Refers to a resource that is "north" of the current resource.

When used in the Maze+XML media type, the associated URI points to a neighboring cell resource to the north in the active maze.

|| Maze+XML

|-
| south || Refers to a resource that is "south" of the current resource.

When used in the Maze+XML media type, the associated URI points to a neighboring cell resource to the south in the active maze.

|| Maze+XML

|-
| [[rel-via|via]] || Identifies a resource that is the source of the information in the context. || Atom 1.0 Syndication format (RFC 4287)

|-
| west || Refers to a resource that is "west" of the current resource.

When used in the Maze+XML media type, the associated URI points to a neighboring cell resource to the west in the active maze.

|| Maze+XML

|-
| item || The target IRI points to a resource that is a member of a collection represented by the context IRI. || Collection+JSON

|-
| create-form || When included in a resource, the "create-form" link relation MAY identify a target resource that represents the form to append a new member to the link context. || See [http://tools.ietf.org/html/rfc6861 The Create-Form and Edit-Form Link Relations (RFC6861)]

|-
| edit-form || When included in a resource, the "edit-form" link relation identifies a target resource that represents the form for editing associated resource. || See [http://tools.ietf.org/html/rfc6861 The Create-Form and Edit-Form Link Relations (RFC6861)]

|-
| lightframe || Opens the target in a lightbox. On inclusion it provides a simple target the lightframe and loads the content in a lightbox effect || Lightbox

|-
| superbox[image] || jQuery Superbox! is a script which allows you display windows with the lightbox effect. || superbox

|-
| wp-video-lightbox || wp-video-lightbox! is a rel to anchor tag script display videos with the lightbox effect. || wp-video-lightbox

|-
| youtube || Opens the target youtube video in using the Swipebox Plugin || Swipebox

|-
| shadowbox || shadowbox is a jQuery script for images displaying with the "lightbox" effects. || shadowbox

|-
| permission || When included in a resource, the "permission" link relation MAY identify a target resource that represents the list of entities that can access or modify the resource in the link context. || See [http://cdoc.io/spec.html#permission-link-relation Collection Document Media Type Specification]

|-
| sub || When included in a resource representation of an event, the "sub" (subscription) link relation MAY identify a target resource that represents the ability to subscribe to the pub/sub event-type resource in the link context. || See [http://rels.messages.io/#sub Subscription Link Relation]

|-
| unsub || When included in a resource representation of an event, the "unsub" (subscription cancellation) link relation MAY identify a target resource that represents the ability to un-subscribe from the pub/sub event-type resource in the link context. || See [http://rels.messages.io/#unsub Subscription Cancellation Link Relation]

|-
| version-history
| When included on a versioned resource, this link points to a resource containing the version history for this resource.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| latest-version
| When included on a versioned resource, this link points to a resource containing the latest (e.g., current) version.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| working-copy
| When included on a versioned resource, this link points to a working copy for this resource.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| working-copy-of
| When included on a working copy, this link points to the versioned resource from which this working copy was obtained.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| predecessor-version
| When included on a versioned resource, this link points to a resource containing the predecessor version in the version history.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| successor-version
| When included on a versioned resource, this link points to a resource containing the successor version in the version history.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| ... || ... || ...

|}

== dropped ==
The following rel values were in earlier version(s) of specification(s) and it is presumed by their absence from the most recent version of the respective specification(s) that they have been deprecated or obsoleted.

In general, you {{should not}} use any dropped values.

If any such values have been superceded by standard values (see the first table on this page), then you {{must not}} use the dropped versions.

In particular:
* if a rel value was in a draft and is missing (without explanation) from the final spec, or
* if a rel value was in a previous version of and is missing (without explanation) from an update to the specification (even a draft update)

Then absent any other information or explanation, it is presumed that the group/editors working on that specification decided to explicitly drop it (either in development, or in the updated version) and thus it should be obsoleted (not re-registered).

If you wish to add them, please research <em>why</em> such values were omitted from latter specifications before doing so. If you do discover the reasoning, please add a short statement or link to thereof into the appropriate place in the following table.

If there is more data, e.g. a link to an email of discussion of the spec development that explains ''why'' the rel value was dropped, and it explicitly states, e.g. it was without prejudice, or merely post-poned, or perhaps expected to be spun-out into its spec (or some other explicit positive reason), then it makes to link/cite that explicit text as part of a proposal.

Sources:
* [http://www.w3.org/MarkUp/html3/ HTML3] (HTML3) / has been superceded by [http://www.w3.org/MarkUp/Wilbur/ HTML 3.2] - which itself has been superceded by [http://www.w3.org/TR/REC-html40 HTML 4.0] - which itself has been updated by [http://w3.org/TR/html401 HTML 4.01], commonly referred to as "HTML 4" in this wiki and other places.)
* [http://www.w3.org/TR/relations.html Proposed HTML 4.0 link types] (HTML4dropped) - obsoleted/superceded by the HTML 4.0 Recommendation. Any values that were in the "Proposed HTML 4.0 link types" document but didn't make it into the HTML 4.0 Recommendation were thus explicitly dropped and should be avoided.

{| border="1"
|+
! rel value !! summary !! defining specification !! why dropped

|-
|[[rel-banner|banner]]||Was used to reference another document to be used as banner for this document (i.e. a form of "include" statement).|| HTML3 ||unknown

|-
| [[rel-begin|begin]] || identifies the author-defined start of a sequence of documents of which the current document is a node.
|| HTML4dropped||unknown

|-
| [[rel-biblioentry|biblioentry]] || identifies a bibliographic entry || HTML4dropped||unknown

|-
| [[rel-bibliography|bibliography]] || identifies a bibliography || HTML4dropped||unknown

|-
| [[rel-child|child]] (obsolete/superceded) || the target document is a hierarchical child, or subdocument, of the current document|| HTML4dropped||unknown

|-
| [[rel-citation|citation]] || the target is a bibliographic citation || HTML4dropped||unknown

|-
| [[rel-collection|collection]] || the target document is an collection that contains the current document || HTML4dropped||unknown

|-
| [[rel-definition|definition]] || identifies a definition of a term || HTML4dropped||unknown

|-
| [[rel-disclaimer|disclaimer]] || identifies a hypertext link to a legal disclaimer || HTML4dropped||unknown

|-
| [[rel-editor|editor]] || identifies a hypertext link to an editor || HTML4dropped||unknown

|-
| [[rel-end|end]] || identifies the author-defined end of a sequence of documents of which the current document is a node. || HTML4dropped||unknown

|-
| [[rel-footnote|footnote]] || the anchor is a footnote marker and the target is a footnote || HTML4dropped||unknown

|-
| [[rel-navigate|navigate]] || the target document contains information such as a image map that will help users to gain a sense of how and where to found information || HTML4dropped||unknown

|-
| [[rel-origin|origin]] || synonym for <code>top</code> || HTML4dropped||unknown

|-
| [[rel-parent|parent]] (obsolete/superceded) || the target document is the hierarchical parent, or container, of the current document|| HTML4dropped||unknown

|-
| [[rel-pointer|pointer]] || the target is a pointer to the real target. This value can be used by a user agent to perform a pre-fetch of the specified target for evaluation until the real target is reached || HTML4dropped||unknown

|-
| [[rel-publisher|publisher]] || identifies a hypertext link to a publisher || HTML4dropped||unknown

|-
| [[rel-sibling|sibling]] (obsolete/superceded) || the target document is a child of a common parent, or a hierarchical peer of the current document|| HTML4dropped||unknown

|-
| [[rel-top|top]] || the target document is the logical top node of the tree (see also <code>begin</code>) || HTML4dropped||unknown

|-
| [[rel-trademark|trademark]] || identifies a hypertext link to a trademark notice || HTML4dropped||unknown

|-
| [[rel-translation|translation]] || the target is a translation to another language || HTML4dropped||unknown

|-
| [[rel-urc|urc]] || identifies a Universal Resource Citation || HTML4dropped||unknown

|-
|}

== dropped without prejudice ==
In one known instance (from HTML4 to HTML5), some rel values were in an earlier version of a specification (or a proposal) and were dropped from a latter (draft) version, and it was noted that these values were dropped with the intent that they could still be proposed in a registry and thus they explicitly were not deprecated or obsoleted. This section documents such values as separate from the [[#dropped|dropped]] section.

In general, you {{should not}} use any dropped values.

If any such values have been superceded by standard values (see the first table on this page), then you {{must not}} use the dropped versions.

Rel values that were dropped without prejudice from a specification will be considered similar to new values that have never been specified.

If you know of additional rel values that were dropped without prejudice from an update to a specification, please cite a URL and quote from the group developing the specification that officially states from that group that the dropping of the values was done without prejudice, or equivalent statement (such as explicit allowance of external registration, proposal, and/or development).

This table serves a historical purpose. If you wish to propose a value from this table, please copy it and leave it in place.

Sources:
* Several rel values were [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7475#c15 explicitly dropped from HTML5]. Per: [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Issue 118 Decision] ('''emphasis''' added): <blockquote><p>"The final proposal argues for the removal of some relation values, to wit, it suggests removal of '''index, up, first and last'''. It was pointed out in survey comments that these relations are already registered in the IANA link relation registry. Presumably, '''these relations could also be entered in whatever other registry or registries HTML5 adopts for this purpose'''.</p>...<p>"Next Steps</p>...<p>"Since the relations to be removed are already registered at the IANA link relation registry, no further action is needed to include them there. WG members are '''free to register or record these relations elsehwere''' [sic], as well."</p></blockquote>

{| border="1"
|+
! rel value
! summary
! defining specification
! why dropped

|-
| [[rel-first|first]]
| Synonym for <code>start</code>
| HTML4dropped - never in an official spec
| [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Explicitly dropped from HTML5 interim draft yet permitted for external registry]

|-
| [[rel-index|index]]
| Refers to a document providing an index for the current document.
| was in [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]; the token has been re-registered within the [[#HTML5_link_type_extensions|HTML5 link type extensions]] and is now valid.
| [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Explicitly dropped from HTML5 interim draft yet permitted for external registry]

|-
| [[rel-last|last]]
| Refers to the last document in a collection of documents.
| HTML4dropped - never in an official spec
| [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Explicitly dropped from HTML5 interim draft yet permitted for external registry]

|-
| [[rel-up|up]]
| When the document forms part of a hierarchy, this link references the immediate parent of the current document. Synonym for <code>parent</code>.
| was in [http://www.w3.org/MarkUp/html3/dochead.html HTML3] - but [http://www.w3.org/TR/html401/types.html#type-links dropped in HTML4]
| [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Explicitly dropped from HTML5 interim draft yet permitted for external registry]

|-
|}

See related [http://dev.w3.org/html5/spec/links.html#linkTypes HTML5: Link types] for existing HTML5 specified rel values.

== rejected ==
Some rel values have been proposed and rejected. They are listed here to make that explicit. Authors {{must not}} use rejected rel values.

Source: [[rejected-formats]].

{| border="1"
|+
! rel value !! origin / proposal !! why rejected
|-
| [[rel-logo|logo]]
| [http://relogo.org Relogo.org]
| [[rejected-formats#Logo]]
|-
|[[rel-pavatar|pavatar]] || [http://pavatar.com/ pavatar] || [[rejected-formats#Pavatar]]
|-
|}

== tools ==
See [[implementations]].

== addtional external research ==
Here are some additional historical references to the development or rel-values which may be useful when researching values, especially why specific values may have been proposed but abandoned.
* 1996-06-07 [http://www.w3.org/MarkUp/draft-ietf-html-relrev-00.txt Hypertext links in HTML] (copies: [http://ftp.ics.uci.edu/pub/ietf/html/draft-ietf-html-relrev-00.txt ftp.ics.uci.edu])
* 1996-11-13 [http://www.w3.org/Architecture/NOTE-link Describing and Linking Web Resources]
* 1997-01-23 [http://lists.gnu.org/archive/html/lynx-dev/1997-01/msg00537.html LYNX-DEV Lynx and the LINK tag]
* 1997-01-24 [http://lists.w3.org/Archives/Public/w3c-sgml-wg/1997Jan/0357.html Taxonomy list]
* 1997-03-28 [http://www.w3.org/TR/WD-htmllink-970328 W3C Working Draft: Hypertext Links and Meta Information in HTML]

=== previous attempts at documenting ===
There have been previous attempts at documenting known rel values, most of which fell out of date due to being dependent on a single author maintaining them. They're listed here purely for historical reasons, and are not sufficient to be references of their own (since they're just individual curations of other references)
* [http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html Link Type Definitions Glossary] by fantasai
* ...

== related ==
{{rel-related-pages}}
* [[elemental-microformats]]
* [[existing-rev-values]]
* [[existing-class-names]]

== copyright ==

{{cc-pd-license}}

hcalendar-faq-fr

2022-02-16T16:45:01Z

Barnabywalters:

<h1>hCalendar FAQ</h1>

Cette page est destinée à documenter les Q&R à propos de [[hcalendar-fr|hCalendar]].
Si vous avez une nouvelle question à poser, considérez SVP de poser d'abord votre question sur le microformats canal [[irc]] (de préférence) ou sur la [http://microformats.org/mailman/listinfo/microformats-discuss/ liste de discussion microformats]. Les nouvelles questions et réponses devraient être ajoutée à la fin de la liste. Si vous avez une nouvelle question mais pas de réponse, ajoutez-la sur [[hcalendar-issues-fr|hCalendar problématiques]].

<h2>Editer cette Page</h2>
SVP, n'utilisez pas de "?" ou tout autre signe de ponctuation dans les titres - cela aide à maintenir des URLs vers leurs identifiants plus courts et plus faciles à lire, à copier-coller, etc. Voir [[how-to-play-fr|comment jouer]] pour en savoir plus sur les lignes de conduite wiki.

== date et heure ==
=== pourquoi mon événement se termine un jour plus tôt que ce que je veux ===
''Pourquoi mon événement se termine un jour plus tôt que ce que je veux ?''
* DTEND n'est pas inclusif. Si vous voulez qu'un événement se termine le 2 janvier, alors vous aurez besoin de régler DTEND sur 2006-01-03, un jour plus tard. Ceci parce que l'événement se terminera à la première seconde de la date fournie, aussi si vous spécifiez 2006-01-02, alors cela dit que la fin de l'événement est à minuiut entre le premier et le second.

=== puis-je utiliser des tirets et deux-points dans mes DatesISO ===
''Puis-je utiliser des tirets et deux-points dans mes DatesISO ?''
* hCalendar spécifie le [http://fr.wikipedia.org/wiki/ISO_8601 format date heure ISO8601], et les deux exemples sont valides, vous pouvez l'utiliser sans ou avec des tirets/deux points/espaces. Remarquez néanmoins que tant la [http://www.w3.org/TR/NOTE-datetime note du w3C] et la RFC 3339 recommandent l'usage du premier format, étendu (délimité).

=== dois-je spécifier l'information détaillée d'heure et de zone horaire===
''Dois-je spécifier l'information détaillée d'heure et de zone horaire ?''
* Incluez autant d'information que nécessaire, à minima incluez AAAA-MM-JJ

=== pourquoi dois-je utiliser un T entre la date et l'heure ===
''Pourquoi dois-je utiliser un T entre la date et l'heure ?''
* Vous ne pouvez PAS utiliser un caractère espace-blanc, le 'T' est obligatoire pour séparer la date de l'heure.

=== comment sont représentés les événements récurrents ===
''Comment sont représentés les événements récurrents ?'' demandé aussi comme ''Comment puis-je représenter un événement qui se répète en hCalendar ?''
* Si vous jetez un oeil à l'[http://microformats.org/wiki/hcalendar-examples-fr#Exemple_3_2 Exemple 3], il y a un moyen proposé utilisant une propriété <em>RRULE</em> avec une sous-propriété <em>freq</em>. C'est un début - plus de brainstorming sur [http://microformats.org/wiki/hcalendar-brainstorming#Recurring_Events hcalendar-brainstorming].

=== comment balisez-vous juste l'année ===
'''Comment balisez-vous juste l'année à l'inverse d'une date complète ? par exemple pour représenter l'âge ou pour discuter de "l'année passée" ?''
* Cela dépend du contexte. Si par "l'année passée", vous voulez dire l'année *calendaire* passée, alors marquez la du 1er janvier au 31 décembre. Si vous voulez dire les 365 derniers jours, alors marquez là selon n'importe quelle date en rapport. etc.

=== comment dois-je baliser un date-time avec le fuseau horaire ===
''Comment dois-je baliser un date-time avec le fuseau horaire approprié ?''
* Il y a deux moyens de faire ça. D'abord vous pouvez ajouter votre fuseau horaire à la fin de votre date-time comme ceci : 2006-01-01T12:00:00-0600. [[http://aa.usno.navy.mil/faq/docs/world_tzones.html Voir ici une carte du monde des décalages horaires]]. Aussi, soyez sûr d'ajuster le décalage à prendre en compte pour l'[[http://fr.wikipedia.org/wiki/Heure_d%27%C3%A9t%C3%A9 heure d'été]] pour les événements dans les dates et lieux applicables. L'autre option est de convertir votre date-time avec une zone horaire à l'intérieur d'un UTC date-time. iCalendar requiert que les heures soient en UTC, mais hCalendar permet aussi d'encoder vos dates-times comme des ISO date-times propres avec leurs décalages de zones horaires.

== endroit / lieu / location ==
=== comment fournissez-vous une meilleure donnée de lieu pour un évenement que les lat et long ===
''Pouvez-vous fournir des données d'endroits plus précises pour un évenement hCalendar comme la latitude et la longitude?''
* Oui, c'est possible, en ajoutant une couche [[hcard-fr|hCard]] avec le balisage location (voir [[hcalendar-brainstorming#hCard_locations|le brainstorming sur hCard locations]]), par ex. en utilisant votre exemple de lat long (prendre les valeurs comme données, quelqu'un se sentira libre de les réparer pour que ce soit des valeurs réelles). Les exemples de code sont supposés être à l'intérieur d'un élément avec un nom de classe "vevent". Voir la page [[hcalendar-location-hcard-example]] pour les détails. Pour plus de discussions sur les données géographiques, d'endroits et recherche à l'intérieur de formats actuels et futurs potentiels, voir la page [[location-formats-fr|location formats]].

=== comment représentez-vous la langue d'un lieu ===
''Comment représentez-vous la langue d'un LOCATION ?'' - aussi connu comme le paramètre language.
* Utilisez l'attribut (X)HTML "lang". Voir par exemple [[hcard-authoring-fr#R.C3.A9gler_la_langue_si_diff.C3.A9rente|l'explication dans la page publication hCard sur la façon d'utiliser "lang"]].

== détails de balisage ==
=== pourquoi les noms de classe racine "vcalendar" et "vevent" ===
''Pourquoi les noms de classe racine "vcalendar" et "vevent" et pas "hcalendar" ?''
* [[hcalendar-fr|hCalendar]] est basé sur la spec iCalendar (RFC 2445), qui est elle-même basée sur vCalendar. Les noms des objets sont restés cohérents et sont basés sur les noms originaux provenant de vCalendar.

=== existe-t'il un exemple de hCalendar dans un tableau ===
''Existe-t'il un exemple de hCalendar dans un tableau ?''
* Jetez un oeil sur [[hcalendar-examples-in-wild-fr#programmes_de_conf.C3.A9rence|hCalendar exemples dans la jungle : programmes de conférence]].

=== est-ce qu'acronym pour dtstart serait juste aussi bien que abbr ===
''Est-ce qu'acronym pour DTSTART serait juste aussi bien que <abbr> ?''
* Il pourrait l'être, mais il n'y en pas besoin. L'élément <abbr> est aussi préféré car il est mieux défini. L'élement <acronym> et en particulier, le terme "acronym" signifie différentes choses pour différentes personnes, et de ce fait nous ne l'utilisons pas dans [[hcalendar-fr|hCalendar]].

=== et si un navigateur ne supporte pas abbr ===
''Que se passe t'il si un navigateur ne supporte pas <abbr>?''
* alors les contenus lisibles par les humains dans l'élément sont affichés, ce qui est le comportement désirable.

== stylisme et affichage ==
=== comment j'ajoute du style à un groupe d'événements ===
''Que dois-je faire si je veux ajouter un style au groupe d'événements calendriers, tout spécialement si le calendrier contient du contenu dynamique ?''
* Vous pouvez écrire des règles de style qui incorporent à la fois le contexte d'un groupe donné (disons qu'il est dans une liste ordonnée avec un noms de classe "group" par exemple) et les événements par ex. :<code>ol.group .vevent { /* insérer un style commun ici */ } </code>

=== et si vous ne voulez pas que le calendrier s'affiche ===
''Que faites-vous si vous ne voulez pas que le calendrier ou la carte s'affiche ?''
* Si vous ne voulez pas que le calendrier ou la carte soient affichés, pourquoi les publiez vous sur le Web ?

=== et si vous ne voulez pas que des propriétés s'affichent ===
''Et si vous ne voulez pas que des propriétés spécifiques s'affichent ?''
* Bien que cela ne soit pas recommandé, vous pouvez utiliser trivialement CSS pour cacher (ou autrement altérer l'affichage) de certaines propriétés. Par exemple, si vous voulez cacher l'endroit "location" de tous vos VEVENTs vous écririez une règle comme celle-ci : <code> .vevent .location { display:none } </code>. Ceci n'empêchera pas néanmoins aux propriétés de pouvoir être lues à partir du source HTML ; ou d'être vues par les personnes qui n'ont pas d'autorisation CSS ; ou d'être découvertes par les moteurs de recherche ou autres robots.

=== comment spécifiez-vous un tooltip sur un datetime ===
''Si nous utilisons <abbr> title pour l'ISODate, comment spécifions-nous un tooltip différent ?''
* Pour des raisons de transparence et de visibilité des métadonnées, il est recommandé que vous NE SPECIFIEZ pas un tooltip différent. Néanmoins, si vous devez le faire dans votre contenu particulier ou application, vous pouvez faire ainsi avec un span imbriqué par ex. <code> <abbr title="20050221"><span title="tooltip text">21 février</span></abbr></code>

== interactions avec d'autres noms de classes ==
=== Comment dois-je utiliser un nom de classe à l'intérieur d'un événement hCalendar sans qu'il ne devienne une propriété ===
''Comment j'utilise une classe à l'intérieur de <span class="vcalendar"> quand je ne veux pas que l'élément que j'utilise dessus soit une propriété du calendrier ?''
* Utilisez un nom de classe qui ne soit pas défini dans le nom de propriété iCalendar.

=== que se passe t'il si la classe est utilisée à la fois à l'intérieur et en dehors d'un hCalendar ===
''Que se passe t'il si la classe est utilisée à la fois dans et en dehors de <span class="vcalendar"> ?''
* Cela fonctionne bien.

== outils ==
=== quels programmes ou services convertissent iCalendar vers hCalendar ===
''Y'a t'il quelques programmes de services qui convertissent iCalendar vers hCalendar ?''
*A cette heure, il n'y a pas de plans pour créer un programme. Il y a plusieurs problématiques lors de la conversion, principalement COMMENT l'information est représentée en HTML. Parce que vous pouvez simplement utiliser simplement n'importe quel élément que pourrait choisir le convertisseur. Ce n'est pas pour dire qu'un convertisseur ne devrait pas être construit, mais c'est hors du champ des microformats.

=== pourquoi Outlook n'importe pas mon fichier ics ===
''Pourquoi Outlook n'importera pas mon fichier ics''
* Outlook est méticuleux sur quelques propriétés. Avec outlook, UID, DTSTAMP et METHOD sont obligatoires. Assurez-vous d'avoir balisé votre hCalendar avec un class="uid" et un class="dtstamp" dans un class="vevent". Voir [[icalendar-implementations-fr]] pour plus de détails et de quirks sur les implémentations particulières de iCalendar.

=== au moment de transformer un hCalendar en un fichier .ics, les datetimes devraient-elles être converties en UTC ===
''Au moment de transformer un hCalendar en un fichier .ics, dois-je convertir l'heure en UTC ?''
* Oui, le format iCalendar ne permet pas que l'heure soit publiée avec un décalage. Les hCalendars peuvent être publiés avec des décalages, parce que cela promeut l'exactitude, parce que cela est plus facilement vérifiée (la mathématique des fuseaux horaires est difficile), mais les outils qui tranforment hCalendar en iCalendar doivent tranformer les heures en UTC.

== autres formats de calendrier ==
===en quoi hCalendar est différent de xCalendar ===
''En quoi [[hcalendar-fr|hCalendar]] est différent de xCalendar, cad. les instructions iCalendar XML soumises sous l'[http://www.ietf.org/ID.html IETF Internet-Draft] ?''
hCalendar et xCalendar sont en fait très similaires en ce sens qu'ils sont tous deux fondés sur le standard iCalendar, RFC2445. Néanmoins, xCalendar est un moyen de représenter les fichiers iCalendar en utilisant des noms d'éléments et d'attributs XML non-standards. Ceci est inapproprié et difficile à servir sur les pages web. xCalendar est encore un document séparé encapsulé, dans le contexte sur le web, ce qui requiert encore un autre nom d'espace. Rien ne ressemblerait même à un fichier xCalendar XML dans le contexte sa navigation ordinaire, à moins que ce ne soit XSLTifié en quelque chose d'autres, par ex. hCalendar. D'un autre côté, [[hcalendar-fr|hCalendar]] est facilement embarquable dans des pages web normales XHTML, facile à styliser avec CSS, il sépare proprement l'information date présentable humainement vs les dates parsables par les machines en ISO-8601, etc. Avec hCalendar, les contenus de calendriers et événements apparaissent à la fois à l'utilisateur humain *et* aux implémentations machines conscientes du hCalendar, parseurs, indexeurs, etc., sur le web d'*aujourd'hui*.

== non supporté actuellement ==
=== est-il possible de représenter des groupes d'événements ===
''Est-il possible de représenter des groupes d'événements ?''- par ex. des ateliers sur une conférence.
* Non, pas à cette heure. iCalendar a vraiment un mécanisme équivalent : le propriété RELATED-TO avec un attribut RELTYPE de PARENT/CHILD/SIBLING (parent étant le défaut). Néanmoins, cette fonctionnalité de iCalendar n'est pas spécifiée actuellement dans hCalendar. Voir [[hcalendar-brainstorming#grouping_events|hCalendar brainstorming: grouping events]].

==Pages en rapport==
{{hcalendar-related-pages-fr}}

hcalendar-faq

2022-02-16T16:43:52Z

Barnabywalters:

<h1> hCalendar FAQ </h1>

This page is for documenting Q&A about [[hcalendar|hCalendar]]. If you have a new question to ask, Please consider first asking your question on the microformats [[IRC]] channel (preferably) or the [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] list. 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 [[hcalendar-issues|hCalendar 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.

== date and time ==
=== Why does my event end a day earlier than I want ===
''Why does my event end a day earlier than I want?''
* DTEND is not inclusive. If you want an event to end on January 2nd, then you will need to set DTEND to 2006-01-03, one day later. This is because the event will END the first second of the date provided, so if you specify 2006-01-02, then that says that the end of the event is at midnight between the 1st and 2nd.

=== Can I use hyphens and colons in my ISODates ===
''Can I use YYYY-MM-DDThh:mm:ss dates or do I have to use the YYYYMMDDThhmmss format?''
* hCalendar specifies [http://en.wikipedia.org/wiki/ISO8601 ISO8601 datetime format], and both examples are valid, you can use with or without hyphens/colons/spaces. Note, however, that both the [http://www.w3.org/TR/NOTE-datetime w3C note] and RFC 3339 recommend the use of the former, extended (delimited) format.

=== Do I have to specify detailed time and timezone information ===
''Do I have to specify detailed time and timezone information?''
* Include as much information as necessary, minimally include YYYY-MM-DD

=== Why do I have to use a T between the date and time ===
''Why do I have to use a 'T' between the date and time in ISO Dates?''
* You can NOT use a white-space character, the 'T' is mandatory to separate the date from the time.

=== How are recurring events represented ===
''How are recurring events represented?'' also asked as ''How do I represent a repeating event in hCalendar?''
* If you take a look at [http://microformats.org/wiki/hcalendar-examples#Example_3 Example 3], there is a proposed means using an <em>RRULE</em> property along with a <em>freq</em> sub-property. It's a start - more brainstorming at [http://microformats.org/wiki/hcalendar-brainstorming#Recurring_Events hcalendar-brainstorming].

=== How do you markup just the year ===
''How does one markup just the year as opposed to an entire date? e.g. to represent age, or discussing "the past year" ?
* Depends on the context. If by "the past year", you mean the past *calendar* year, then mark it up as January 1st through December 31st. If you mean the past 365 days, then mark it up according to whatever date it is relative to. Etc.

=== How do I markup a datetime with timezone ===
''How do I mark-up a date-time with the proper timezone?''
* There are two ways to do this. First, you can add your timezone offset to the end of your date-time like this: 2006-01-01T12:00:00-0600. [[http://aa.usno.navy.mil/faq/docs/world_tzones.html See a world timezone offset map here]]. Also, be sure to adjust offset to account for [[http://en.wikipedia.org/wiki/Daylight_saving_time Daylight Saving Time]] for events within applicable dates and locations. The other option is to convert your date-time with a timezone into a UTC date-time. iCalendar requires that times be in UTC, but hCalendar also allows for encoding your date-times as proper ISO date-times with timezone offsets.

== location ==
=== How do you provide better location data for an event than lat long ===
''Can you provide more precise location data for an hCalendar event such as latitude and longitude?'' also asked as ''What is the best way to represent a full address in the Location?''
* Yes, it is possible, by overlaying an [[hcard|hCard]] with the location markup (see [[hcalendar-brainstorming#hCard_locations|the brainstorming on hCard locations]]), e.g. using your lat long example (taking the values as given, someone feel free to fix these to be the real values). The code example(s) are presumed to be inside an element with a class name of "vevent". See the [[hcalendar-location-hcard-example]] page for details. For more discussions of location data, geographic data, and research into current and potential future formats, see the [[location-formats|location formats]] page.

=== How do you represent the language of a location ===
''How do you represent the language of a LOCATION?'' - AKA the language parameter.
* Use the (X)HTML "lang" attribute. See for example [[hcard-authoring#Set_the_lang_when_different|the explanation in hCard authoring of how to use "lang"]].

== markup details ==
=== Why are the root class names vcalendar and vevent ===
''Why are the root class names "vcalendar" and "vevent" and not "hcalendar"?''
* [[hcalendar|hCalendar]] is based on the iCalendar spec (RFC 2445), which itself is based on vCalendar. The names of objects have remained consistent throughout and are based on the original names from vCalendar.

=== Is there an example of hCalendar in a table ===
''Is there an example of hCalendar in a table?''
* Take a look at: [[hcalendar-examples-in-wild#conference_schedules|hCalendar examples in the wild: conference schedules]].

=== Would acronym for dtstart be just as good as abbr ===
''Would the use of <acronym> for DTSTART be just as good as <abbr>?''
* It could be, but there is no need. The <abbr> element is also preferred as it is better defined. The <acronym> element, and in particular, the term "acronym" means different things to different people, and thus we are not using it in [[hcalendar|hCalendar]].

=== What if a browser lacks support for abbr ===
''What happens if a browser doesn't support <abbr>?''
* Then the human readable contents inside the element are displayed, which is the desirable behavior.

== styling and display ==
=== How do I add styling to a group of events ===
''What do I do if I want to add styling to a group of calendar events, especially if the calendar contains dynamic content? ''
* You can write style rules that incorporate both the context of said group (say it is in an ordered list with class name "group" for example) and the events, e.g.:<code>ol.group .vevent { /* insert common styling here */ } </code>

=== What if you do not want the calendar to be displayed ===
''What do you do if you don't want the calendar or card to be displayed?''
* If you don't want the calendar or card to be displayed, why are you publishing it on the Web?

=== What if you do not want some properties to show up ===
''What if you don't want specific properties to show up?''
* Though not recommended, you can trivially use CSS to hide (or otherwise alter the display) of certain properties. E.g. if you want to hide the "location" from all your VEVENTs you would write a rule like this: <code> .vevent .location { display:none } </code>. This won't, however, keep the properties from being read in the HTML source; or seen by people who don't have CSS enabled; or discovered by search engines or other robots. Remember: invisible (meta)data is bad.

=== How do you specify a tooltip on a datetime ===
''If we use <abbr> title for the ISODate, how do we specify a different tooltip?''
* For reasons of metadata transparency and visibility, it is recommended that you DO NOT specify a different tooltip. However, if in your particular content or application you must, you can do so with a nested span e.g. <code> <abbr title="20050221"><span title="tooltip text">Feb. 21st</span></abbr></code>

== interactions with other class names ==
=== How do I use a class name inside an hCalendar event without it becoming a property ===
''How do I use a class inside <span class="vcalendar"> when I don't want the element I use it on to be a property of the calendar?''
*Use a class name that isn't a defined iCalendar property name.

=== What happens if a class name is used both inside and outside an hCalendar ===
''What happens if the class is used both inside and outside <span class="vcalendar">?''
* That works fine.

== tools ==
=== What programs or services convert iCalendar to hCalendar ===
''Are there any programs of services that convert from iCalendar to hCalender?''
*At the moment there are no plans to create a program. There are several issues when converting, mainly HOW the information is represented in HTML. Since you can use just about any element which could the converter choose. This is not to say a converter shouldn't be built, but it is out of the scope of microformats.

=== Why does Outlook not import my ics file ===
''Why won't Outlook import my ics file''
* Outlook is picky about some properties. With some versions of Outlook, UID, DTSTAMP and METHOD are mandatory. Be sure you have marked-up your hCalendar with a class="uid" and a class="dtstamp" in a class="vevent". See [[icalendar-implementations]] for more details and quirks of particular iCalendar implementations.

=== When transforming hCalendar to ics should datetimes be converted to UTC ===
''When transforming an hCalendar to a .ics file, do I have to convert the time to UTC?''
* Yes. The iCalendar format does not permit the time to be published with an offset. hCalendars can be published with offsets, because this promotes accuracy, as it can more easily be verified (timezone math is hard), but tools which transform hCalendar to iCalendar must transformat times to UTC.

== other calendar formats ==
=== How is hCalendar different from xCalendar ===
''How is [[hcalendar|hCalendar]] different from xCalendar, i.e. iCalendar XML guidelines submitted as an [http://www.ietf.org/ID.html IETF Internet-Draft]?''
* hCalendar and xCalendar are actually very similar in that they are both based on iCalendar standard, RFC2445. However, xCalendar is a way of representing iCalendar files using non-standard XML element names and attributes. This is inadequate and unwieldly for serving on web pages. xCalendar is still a separate, encapsulated document in the context of the web, that requires yet another namespace. Nobody would ever look at an xCalendar XML file in the context of their ordinary browsing, unless it's XSLTed into something else, e.g. hCalendar. On the other hand, [[hcalendar|hCalendar]] is easily embeddable into normal XHTML web pages, easily stylable with CSS, cleanly separates human presentable date information vs. machine parsable ISO-8601 dates, etc. With hCalendar, calendar and events content appears both to the human user *and* to hCalendar-aware machine implementations, parsers, indexers, etc., on *today's* web.

== not supported currently ==
=== Is it possible to represent groups of events ===
''Is it possible to represent groups of events?'' - e.g workshops at a conference.
* Not at this time. iCalendar does have such a mechanism: the RELATED-TO property with a RELTYPE attribute of PARENT/CHILD/SIBLING (parent being the default). However, this feature of iCalendar is not currently specified in hCalendar. See [[hcalendar-brainstorming#grouping_events|hCalendar brainstorming: grouping events]].

== Related Pages ==
{{hcalendar-related-pages}}

press

2022-02-16T16:43:33Z

Barnabywalters:

__NOTOC__
<h1> Press </h1>

This page documents the press that [[microformats]] has received. See also microformats [[articles]], [[screencasts]], [[presentations]], [[podcasts]], and [[books]]. Note that some of this press may be in response to [[press-faq|the press FAQ]].

Some sources of conventional press:

* [http://news.google.com/news?q=microformat+OR+microformats&scoring=n Google News search for "microformat(s)"] ([http://news.google.es/news?hl=es&ned=es&scoring=n&q=microformatos+OR+microformat news.google.es search for "microformat(os)"])
* [http://www.google.com/alerts?hl=en&q=microformat+OR+microformats&ie=UTF8&t=1 Google alert (e-mail) for "microformat(s)"]

==Press enquiries==
If you are a journalist, wanting to write or broadcast about microformats, please ask on our [[IRC]] channel or [[mail|microformats-discuss mailing list]].
== March 2009 ==
* 2009-03-11 [http://cmscritic.com/microformats-a-set-of-simple-open-data-formats-built-upon-existing-and-widely-adopted-standards "Microformats"]by CMS Critic
== October 2007 ==
=== URLs of mentions ===
* 2007-10-04 http://www.elmundo.es/navegante/2007/10/04/tecnologia/1191529660.html
* <span class="vevent"><span class="description"><span class="dtstart">2007-10-04</span><span class="summary">Techcrunch-fr </span> : le point sur les microformats (<span class="url">http://fr.techcrunch.com/2007/10/04/fr-le-point-sur-les-microformats/</span>)</span></span>

== September 2007 ==
=== URLs of mentions ===
* 2007-09-21 [http://www.internetnews.com/dev-news/article.php/3701096 "Microformats: Toward a Semantic Web"] by Internetnews.com.

* <span class="vevent"><span class="description"><span class="dtstart">2007-09-12</span> <span class="summary">"Microformats : vendre en ligne sans boutique" - Salon ecommerce Paris - Guide du Participant</span>: <span class="url">http://www.flickr.com/photos/christopheducamp/1405921949/</span></span></span>

* <span class="vevent"><span class="description"><span class="dtstart">2007-09-11</span><span class="summary">InternetNews.com</span>: Microformats Hop on Semantic Web 'Griddle' (<span class="url">http://www.internetnews.com/dev-news/article.php/3699101</span>)</span></span>

== August 2007 ==
=== URLs of mentions ===
* <span class="vevent"><span class="description"><span class="dtstart">2007-08-06</span> <span class="summary">PC Magazine</span>: <span class="url">http://www.pcmag.com/article2/0,1895,2167604,00.asp</span></span></span>
* <span class="vevent"><span class="description"><span class="dtstart">2007-08-03</span> <span class="summary">SitePoint</span>: <span class="url">http://www.sitepoint.com/blogs/2007/08/03/have-microformats-finally-arrived</span></span></span>
* <span class="vevent"><span class="description"><span class="dtstart">2007-08-01</span> <span class="summary">WIRED</span>: <span class="url">http://blog.wired.com/monkeybites/2007/08/google-maps-tak.html</span></span></span>
* <span class="vevent"><span class="description"><span class="dtstart">2007-08-01</span> <span class="summary">CMSWire</span>: <span class="url">http://www.cmswire.com/cms/web-20/back-to-the-future-of-the-web-what-mattered-most-001526.php</span></span></span>

== July 2007 ==
=== URLs of mentions ===
* <span class="vevent"><span class="description"><span class="dtstart">2007-07-20</span> <span class="summary">CMSWire</span>: http://www.cmswire.com/cms/enterprise-20/openid-and-microformats-become-socially-acceptable-001494.php</span></span>
* <span class="vevent"><span class="description"><span class="dtstart">2007-07-10</span> <span class="summary">Wired</span>: http://blog.wired.com/monkeybites/2007/07/tim-berners-lee.html</span></span>
* <span class="vevent"><span class="description"><span class="dtstart">2007-07-02</span> <span class="summary">Seatle Times</span>: http://seattletimes.nwsource.com/html/businesstechnology/2003770628_techsocial02.html</span></span>
* <span class="vevent"><span class="description"><span class="dtstart">2007-07-02</span> <span class="summary">Web Worker Daily</span>: http://webworkerdaily.com/2007/07/02/powncing-on-the-twitter-bird-or-not/</span></span>

=== noted and quoted ===
Remove the above two level 3 headings when all URLs of mentions are noted and quoted here.

<ul>
<li class="vevent">
<span class="description"><span class="dtstart">2007-07-18</span> <span class="summary">Forbes article on Plaxo Pushes for ''Open Social Web'' references below microformats announcements</span> (<span class="url">http://www.forbes.com/businesswire/feeds/businesswire/2007/07/18/businesswire20070718005301r1.html</span>).</span>
</li>
<li class="vevent">
<span class="dtstart">2007-07-17</span> <span class="summary">Plaxo Pushes For "Open Social Web": Endorses and implements key open standards, OpenID and microformats</span> (<span class="url">http://www.plaxo.com/about/releases/release-20070718</span>) <blockquote class="description"><p>...the company has implemented the microformats hCard and hCal as part of the all-new Plaxo 3.0 making it even easier for members to share information and support more mashups in the future. Public profiles, a new feature of the service, now use the hCard format for contact info, giving users the ability use their profile information on any of the growing list of services that consume hCard data.</p></blockquote>
</li>
<li class="vevent">
<span class="dtstart">2007-07-03</span> <span class="summary">"What's next for the Internet" in "CNNMoney.com" syndication of an article from "Business 2.0 Magazine" by Michael V. Copeland.</span> (<span class="url">http://money.cnn.com/magazines/business2/business2_archive/2007/07/01/100117068/index.htm?postversion=2007070305</span>) <blockquote class="description"><p>"We've had the problem of overpromising in this industry; a lot of us who were working on semantic Web technologies early on saw the potential and got a little excited. It has taken much longer to realize than we thought. One thing Web 2.0 has taught everybody is that simpler is better. Find something useful and iterate on that." <nowiki>[- Nova Spivack]</nowiki></p><p>Tom Coates, whose day job at Yahoo involves working on just these issues, thinks the Web 2.0 crowd is already taking care of the problem. He points to tagging and [[microformats]] that add some of the same metadata to webpages that semantic technologies offer.</p><p>"I call it the dirty semantic Web," Coates says from his London office. "It may not be the pristine Berners-Lee view of the world, but it is headed in the right direction." </p></blockquote>
</li>
</ul>

== June 2007 ==

=== URLs of mentions ===

To be processed into the below noted and quoted format:
* <span class="vevent"><span class="description"><span class="dtstart">2007-06-26</span> <span class="summary">Web Worker Daily</span>: <span class="url">http://webworkerdaily.com/2007/06/26/location-location-location-get-the-best-out-of-3-presence-apps/</span></span></span>
* <span class="vevent"><span class="description"><span class="dtstart">2007-06-25</span> <span class="summary">Ars Technica</span>: <span class="url">http://arstechnica.com/journals/microsoft.ars/2007/06/25/rumor-internet-explorer-8-beta-coming-by-year-end</span></span></span>

=== noted and quoted ===

Remove the above two level 3 headings when all URLs of mentions are noted and quoted here.

<ul>
<li class="vevent">
<span class="dtstart">2007-06-29</span> <span class="summary">"The Tech Lab: Bradley Horowitz" in "BBC News, Technology"</span> (<span class="url">http://news.bbc.co.uk/1/hi/technology/6252716.stm</span>
<blockquote class="description"><p>Where we find people codifying big blocks of entities - whether in a movie database or books or restaurants, or business entities - I am comfortable taking a pragmatic approach so long as the companies contributing their respective intellectual property are committed to open standards and strategies.</p><p>It will happen through small pieces loosely joined, and it is emerging already. Different domain <span class="notspam">specia<span class="srsly"></span>lists</span> will grab different domain patches.</p><p>Once we begin to have this information we can then put it in [[microformats]] on the web, which are machine-readable. So then in an automated fashion crawlers can take advantage of that structure. </p><p>...</p><p>The web itself is sloppy, loose and unstructured - and these, by the way, are virtues!</p><p>But in making it easy to add [[microformats]], which are just machine-readable, coded bits of structure, we let machines talk to machines and ambiguity over which restaurant I am blogging about, or which film, or which person, will end.</p><p>This represents a huge step toward the vision of the semantic web, and will not only create entirely new applications, but will also solve problems that users today have come to accept as part of "life on the web."</p><p>This structure should be optional, not imposed. The onus is on us, the builders of the tools, to make it brain dead simple to add this structure.</p></blockquote>
</li>

<li class="vevent">
<span class="dtstart">2007-06-29</span> <span class="summary">'''"<span lang="fr">Les microformats donnent du sens aux pages web</span>"''' in "01 Informatique" - issue 1911 by Frederic Bordage</span>. [http://www.flickr.com/photos/christopheducamp/682883268/in/photostream/] with a french interview of Tantek Çelik [http://www.flickr.com/photos/christopheducamp/682882852/in/photostream/]<span style="float:right">[http://www.flickr.com/photos/christopheducamp/682882852 http://farm2.static.flickr.com/1348/682882852_15a6587a30_m.jpg]</span>
<blockquote class="description" lang="fr"><p>Web Sémantique. Ces formats transforment les pages web en bases de données structurées. L'indexation devient ainsi plus riche et plus pertinente. ''"Une approche du web sémantique pragmatique et simple à mettre en oeuvre"''. C'est ainsi que François Goube, PDG du moteur de recherche JobiJoba.com qualifie les microformats. (...)</p></blockquote>
<blockquote class="description" lang="en"><p>Translation : These microformats enhance web pages, and lead them to structured data. As a search engine, it makes more sense. ''"Integrating Microformats is a really simple and pragmatic way to start with semantic web"'', said Francois Goube, CEO of JobiJoba.com : a European JobSearch engine.</p></blockquote>
</li>

<li class="vevent">
<span class="dtstart">2007-06-21</span> <span class="summary">"Microformats: People First, Machines Second" in "Electronic Design" by William Wong. ED Online ID #15742.</span> (<span class="url">http://www.elecdesign.com/Articles/ArticleID/15742/15742.html</span>
<blockquote class="description"><p>It's amazing what you can find bouncing around the Internet. I stumbled across microformats while looking for something else. Microformats are a way of embedding semantic information on a Web page. They're designed to augment human-readable versions so software can easily and accurately extract the same information. Also, they're based on a small set of open data formats built upon existing and widely adopted standards.</p></blockquote>
</li>
</ul>

== January 2007==

* <span class="vevent"><span class="description"><span class="dtstart">2007-01-15</span> <span class="summary">''Government Computer News'' (UK); Microformats get real by Joab Jackson</span>: <span class="url">http://www.gcn.com/blogs/tech/42930.html</span></span></span>
* <span class="vevent"><span class="description"><span class="dtstart">2007-01-03</span> <span class="summary">Information Week; Firefox 3: From HTML Renderer To Information Broker by Mitch Wagner</span>: <span class="url">http://www.informationweek.com/blog/main/archives/2007/01/firefox_3_from.html</span> Discusses the implications of native microformat support in Firefox.</span></span>
* <span class="vevent"><span class="description"><span class="dtstart">2007-01-02</span> <span class="summary">Read/ Write Web; Mozilla Does Microformats: Firefox 3 as Information Broker</span>: <span class="url">http://www.readwriteweb.com/archives/mozilla_does_microformats_firefox3.php</span></span></span>
* <span class="vevent"><span class="description"><span class="dtstart">2007-01-01 </span><span class="summary">''Linux Format Magazine'' (UK); What on earth... are Microformats?</span>: <span class="url">http://www.flickr.com/photos/christopheducamp/500478421/</span></span></span>

== Blog Mentions ==
While not conventionally thought of as press or news, mentions by blogs can often be significant and may superficially resemble press due to their reverse chronological, most recent post first organization.
* [http://s.technorati.com/microformat+OR+microformst Technorati search for "microformat(s)"]

== Related pages ==
<div id="2006"><div id="2005">
{{press-related pages}}
</div></div>

== See Also ==
* [[articles]]
* [[books]]
* [[presentations]]
* [[podcasts]]
* [[quotes]]
* [[screencasts]]
* [[external-resources]] for external resources related to microformats.

turns-nine-upgrade-to-microformats2

2022-02-16T16:42:41Z

Barnabywalters:

published on tantek.com and the [[blog]]:
* http://tantek.com/2014/171/b1/microformats-org-turns-nine
* http://microformats.org/2014/06/20/microformats-org-turns-9-upgrade-to-microformats2

= microformats.org turns 9 - upgrade to microformats2 and more =

Nine years ago we launched microformats.org with a basic premise: that it is possible to express meaning on the web in HTML in a simple way—far simpler than the complex alternatives (XML) being promoted by mature companies and standards organizations alike.

None of the other alternatives promoted in the 2000s (even by big companies like Google and Yahoo) survive to this day in any meaningful way:
* [[Google Base]]
* [[Google Data]]
* Yahoo's [[CommonTag]].org
* too many XML approaches to count

From this experience, we conclude that what large companies support (or claim to prefer) is often a trailing indicator (at best).

Large companies tend to promote more complex solutions, perhaps because they can afford the staff, time, and other resources to develop and support complex solutions. Such approaches fundamentally lack empathy for independent developers and designers, who don't have time to keep up with all the complexity.

If there's one value that's at the heart of microformats' focus and continued evolution of [[simplicity]], it is that empathy for independent developers and designers, for small consulting shops, for curious hobbyists who are most enabled and empowered by the simplest possible solutions to problems.

We now know that no amount of large company marketing and evangelism can make up for a focus on ever simpler solutions which take less time to learn, use, and reliably maintain. As long as we focus on that, we will create better solutions.

== Community Changes ==
Speaking of taking less time, we've learned some community lessons about that too. Perhaps the most important is that as a community we are far more efficiently productive using <em>just</em> [[IRC]] and the wiki, than any amount of use of email. In fact, the microformats drafts that were developed wtih the most email (e.g. hAudio) turned out to be the hardest to follow and discuss (too many long emails), and sadly ended up lacking the simplicity that real world publishers wanted (e.g. last.fm).

Email tends to bias design and discussions towards those who have more time to read and write long emails, and (apparently) enjoy that for its own sake, than those who want to quickly research & brainstorm, and get to actually <em>creating, building, and deploying</em> things with microformats.

Thus we're making these changes effective today:
* [[IRC]] for all microformats discussions, whether research, questions, or brainstorming
* [[email]] only for occasional announcements and to direct people to IRC.
* [[wiki]] for capturing questions, brainstorming, conclusions, and different points of view

We're going to update the site to direct all discussion (e.g links) to the IRC channel accordingly.

Hope to see you there: [ircs://irc.libera.chat:6697/microformats #microformats on libera.chat]

== Upgrading to microformats2 ==
Over the past few years [[microformats2]] has proven itself in practice, with numerous sites both publishing and consuming, several open source parsing libraries, and a growing test suite. All the lessons learned from the evolution from original microformats, from RDFa, and from microdata have been incorporated into microformats2 which is now the simplest to both publish and parse.

It's time to throw the switch and upgrade everything to [[microformats2]]. This means three things:

=== Upgrading microformats.org ===
First, we're starting by upgrading the links on the microformats.org home page to point to the microformats2 drafts, which are ready for use.

We'll be incrementally upgrading the markup of the microformats.org site itself to use microformats2 markup.

=== Upgrade sites ===
Second, if you publish any kind of semantic information, start upgrading your web pages to microformats2 across the board.

If you're concerned about what search engines claim to support, there are two approaches to choose from:
# Know that search engines are a trailing indicator, and as microformats2 usage grows, they'll index it as well.
# Or: Use <em>one</em> classic microformat (supported by all major [[search engines]]) at top of your page, e.g. on the <code><body></code>, in addition to your microformats2 markup throughout your pages. Search engines only really care to summarize the primary topic or purpose of a web page in their "rich snippets" or "cards", and thus that's sufficient.

Check out the latest [[validators]] which now include some microformats2 support as well!

=== Upgrade tools ===
Third, this is a call to upgrade all microformats supporting tools to microformats2. As nearly all of these are open source, this is an open call for contributions, updates, patches, etc. for:
* [[Operator]]
* [[H2VX]]
* [[validators]]
* [[hCard creator]]
* [[hCalendar creator]]
* [[hReview creator]]
* ...

If it generates microformats, upgrade it to <em>instead</em> generate microformats2.

If it consumes microformats, upgrade it to <em>also</em> consume microformats2 (which may be most easily done by making use of one of the microformats2 parsers that has backward compatible parsing built in).

== Goal ==
As we enter the tenth year of microformats.org let's make it our collective goal to upgrade our pages, our sites, and our tools to microformats2.

Our goal is to complete all the above upgrades by microformats.org's tenth birthday, if not sooner. Let's get to work.

Thanks to Barnaby Walters and fellow microformats [[admins]] Kevin Marks & Ted O'Connor for reviewing drafts of this post. Thanks to Kevin especially for some copy edits!

hreview-faq

2022-02-16T16:42:12Z

Barnabywalters:

= hReview FAQ =

This page is for documenting Q&A about [[hreview|hReview]]. If you have a new question to ask, Please consider first asking your question on the [ircs://irc.libera.chat:6697/microformats microformats irc channel] (preferably) or the [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] list.

== Q&A ==

# What is the purpose of the hReview microformat (i.e. why is it important for it to exist)?

# What are the advantages of using the hReview microformat?

# ''How do you specify more detail for the 'type' field, e.g. for an item of type "product" that is a book, or a movie (on DVD or in a theater), or a music CD? -- paraphrased from [[User:Dougal Campbell|Dougal Campbell]] 11:54, 21 Jun 2005 (PDT)''
#* The 'type' field was kept delibrately coarse and simple. Any attempt to build a thorough and meaningful taxonomy of all specific types of things that can be reviewed would be futile. Instead, the set of reviewed item types is kept small and fairly generic. Specific "typing" information about the item being reviewed should be published as tags as defined in [[hreview|hReview]]. E.g. a review of a book would be tagged with a [http://en.wikipedia.org/wiki/Book book tag]: <code><a rel="tag" href="http://en.wikipedia.org/wiki/Book">book</a></code> . Similarly a movie that was a DVD should be tagged with both: <code><a rel="tag" href="http://en.wikipedia.org/wiki/Movie">movie</a> <a rel="tag" href="http://en.wikipedia.org/wiki/DVD">DVD</a></code> . Or a music CD: <code><a rel="tag" href="http://en.wikipedia.org/wiki/music">music</a> <a rel="tag" href="http://en.wikipedia.org/wiki/CD">CD</a></code> .
# ''What is the difference between the 'website' and 'url' type? --[[User:Dougal Campbell|Dougal Campbell]] 11:54, 21 Jun 2005 (PDT)''
#* A 'website' presumably includes everything located on that site, whereas 'url' refers only to the particular page located at the given 'url'.
# ''What if I want to use hReview to review a podcast? Which type should I use?''
#* As a podcast is typically a specific URL (often ending with ".mp3") the "url" item type should be used when publishing an hReview of a podcast.
# ''What is the proper 'type' to use for a restaurant?''
#* A restaurant is a "business".
# ''Is there a standard way to add information that isn't in the default list of fields? It seems like book reviews should include the author's name, but there's no obvious way to add it to the markup. The example reviews include it in the text, but it's not part of their markup. [[User:Chris Hibbert|Chris Hibbert]]''
#* See [http://microformats.org/discuss/mail/microformats-discuss/2005-September/000985.html email answer on microformats-discuss] - [http://tantek.com/log/ Tantek]
# ''How do I state the scale of the rating field? [http://k.digitalfarmers.com/ Kal Ström]''
#* Please read the [http://microformats.org/wiki/hreview#Field_details rating field description]. The default scale is 1 (worst) to 5 (best) and either can be changed by the author. See the [http://microformats.org/wiki/hreview#Multidimensional_Restaurant_Review multidimensional restaurant review] for an example of this. - [http://tantek.com/log/ Tantek]
# ''Is there some recommendation as to the url for movies, imdb perhaps?'' - [[User:Judson Dunn|Judson Dunn]] 12:40, 17 Dec 2005 (PST)
#* Many users use imdb.com URLs to refer to movies. Others use amazon.com or other DVD etc. product URLs to refer to movies. Some even use the URLs to specific movie sites themselves, e.g. whatisthematrix.com. Some also use URLs to movie traliers on movie trailer sites. You should use whatever you think best represents the specific item you are reviewing. Microformats.org does not make a recommendation to use one of the above in particular. - [http://tantek.com/log/ Tantek]
# ''Can the item being reviewed have more than one photo?''
#* Yes. In general if the specification does not explicitly forbid it, a property may take multiple values (or be specified multiple times).
# ''Is there a recommended way to use hReview to "rate" stocks?''
#* Typically what you are rating is not the stock, but the company behind the stock, which would simply be an item of 'type' 'business', and you would include an [[hcard|hCard]] for the company. If you are actually rating a specific stock (for example in the case where a company has more than one type of stock for trade), then in essence you are reviewing a 'product' which is bought and sold. In that case, you can specify the item 'type' to be a 'product', and then use a standard stock market name for the stock symbol, e.g. "[http://finance.yahoo.com/q?s=T NYSE:T]" for AT&T stock, "[http://finance.yahoo.com/q?s=MSFT NasdaqNM:MSFT]" for Microsoft stock, "[http://finance.yahoo.com/q?s=%5EDJI DJI:^DJI]" for the Dow Jones Industrial Average. More such scoped names for stocks can be found by looking them up on [http://finance.yahoo.com/ Yahoo! Finance], and you could even use a stock's Yahoo! Finance URL as the item's 'url' in the hReview, e.g. as linked from the examples listed.
#* In addition, see the FAQ#1 above. As a "stock" is a particular kind of product, you should probably tag the item in the hReview with a set of tags, e.g.:
#** <code><nowiki><a href="http://technorati.com/tag/stock" rel="tag">stock</a></nowiki></code>
#** <code><nowiki><a href="http://technorati.com/tag/msft" rel="tag">msft</a></nowiki></code>
#** ... etc.
# ''Should rated tags show up alongside other tags in an hReview?''
#* Both rated tags and normal tags apply to the item being reviewed, and thus both are in the total set of tags for the item. As far as where they should show up, that is up to the user interface of the software or service that is displaying the hReviews.
# ''Are decimal-number ratings allowed? (ie 4.5)''
#* One decimal point of precision is added in hReview 0.3 based on analysis of common rating behaviors on the Web.
# ''How do you markup a page for an item that has multiple reviews on that page (without having to repeat the information about the item in each review? Ning could use this, specifically in their default http://reviewit.ning.com/ , see also http://hreviewit.ning.com''
#* Possibly use the object inclusion method from [[resume-brainstorming]].
# ''For a music review, is there a standard for designating/tagging the Artist name separate from the Album name or Track name etc?''
#* It depends on what specifically you are reviewing. If you are reviewing the Artist as a whole, then the Artist is the item. If you are reviewing a specific Album, then the Album is the item. If you are reviewing a particular Track, then the Track is the item. You can then just use tags for the rest of the information.
#*# ''Is there a standard way of specifying what the tag is addressing semantically? That is, say I were reviewing the album OK Computer from Radiohead - the item is of course OK Computer - and I can have a tag to Radiohead - but is there an accepted practice as marking it as an "artist" tag?''
#*#* The short answer is no, tags are a relatively flat set of "aspects" of the item, and you can't give tags a "type" like that. The longer answer is, you could tag it Radiohead using a tagspace (see [[rel-tag]] for details) that specifically defined Radiohead as an artist, e.g. perhaps the [http://en.wikipedia.org/wiki/Radiohead Wikipedia page for Radiohead].
# ''Does anyone have a examples of hReview documents? I.e. both valid and invalid examples to test a parser against?''
#* Please see [[hreview-examples-in-wild|hReview Examples in the Wild]].

==Related pages==
{{hreview-related-pages}}

faqs-for-rdf-fr

2022-02-16T16:40:26Z

Barnabywalters:

<h1>FAQs Microformat pour les Fans de RDF</h1>

__TOC__

== Que sont les Microformats ==
Les Microformats sont un ensemble simple et ouvert de formats de données construits sur des standards existant et largment adoptés, en particulier le XHTML utilisé ''correctement''. Les processus, principes et pratiques du groupe (ouvert) des microformats sont ce qui font les microformats des "microformats", mais ils se concentrent sur l'utilisation du XHTML tel qu'il est conçu, comme un langage sémantique (même s'ils peuvent être aussi implémentés sur d'autres formats XML, comme Atom).

Bien que l'initiative des microformats mettent la priorité sur la lisibilité-par-les-humains, avec l'aide du mécanisme [http://www.w3.org/2004/01/rdxh/spec GRDDL], il est possible de visualiser les microformats comme spécifique à un domaine des feuilletons [http://www.w3.org/RDF/ RDF].

Voir aussi : [http://microformateurs.org/about/ Introduction aux Microformats]

== Par exemple... ==

Cet [[hcard-example1-steps-fr|exemple]] montre comment le microformat hCard peut être utilisé pour exprimer des données vCard.

==== Mais je produis du RDF, pourquoi devrais-je m'y intéresser ====
Les Microformats peuvent baisser la barrière pour placer des données explicites sur les Web. Ceci est complètement dans la lignée des objectifs du [http://www.w3.org/2001/sw/ Web Sémantique].

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, Mars 2000] :
<blockquote>
Je crois que l'un des meilleurs moyens de faire la transition vers RDF, si ce n'est pas une stratégie de déploiement à long terme pour RDF, est de gérer l'information dans un format consommable-par-un-humain (XHTML) annoté avec juste assez d'information pour extraire les déclarations RDF que l'information humaine voudra charrier à l'avenir. En d'autres mots : utiliser une base de données relationnelle ou quelque sorte de donnée native RDF et de recracher dynamiquement du HTML, représente beaucoup d'infrastructure pour opérer et ne vaut probablement pas la peine de s'y intéresser pour beaucoup de cas intéressants. Nous savons tous que nous devons produire une version lisible-par-les-humains de la chose... pourquoi ne pas utiliser la soure primaire ?
</blockquote>

== J'ai un vocabulaire RDF que j'aimerais utiliser comme un microformat. Comment puis-je le produire ==

Avant de produire quoi que ce soit d'autre, lisez le [[process-fr|Processus]. En général, le processus microformat est guidé par les données. Il démarre par du contenu déjà publié, plutôt que d'un format d'un modèle ou d'un schéma existant. Vous devriez aussi regarder la liste de ce qui a déjà été couvert et le travail en cours sur la [[Main-Page-fr|page d'accueil principale du wiki]].

Ce peut être bien que ce que vous avez en tête n'est pas approprié pour l'utilisation en tant que microformat, mais ce peut être encore une bonne idée de développer une représentation XHTML (sémantique). Les microformats existants démontrent un moyen "standards-friendly" de faire ça.

Voir aussi : [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML] (à traduire)

== Ainsi, cela concerne l'utilisation de valeurs de classe CSS à ajouter à la sémantique ==

Non. Le XHTML exprime déjà la sémantique, l'attribut '''HTML''' <code>class</code> est juste l'un des nombreux mécanismes. Extrait de la [http://www.la-grange.net/w3c/html4.01/cover.html spécification HTML 4] :

<blockquote>
L'attribut class, au contraire, assigne un ou plusieurs noms de classe à un élément ; on peut dire de l'élément qu'il appartient à ces classes.
</blockquote>

Voir aussi : [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Les attributs "Class" font plus que styliser]

== Qu'en est-il des espaces-noms pour les attributs, devrais-je utiliser "xxx:term" ? ==
En général, les microformats rejettent l'utilisation de préfixes explicites d'espace-nom dans les documents car ce n'est pas nécessaire pour résoudre le 80/20 des problèmes que les microformats cherchent à résoudre. L'approche générale adoptée est de ne pas essayer de généraliser vers l'extension de [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], mais plutôt de définir des formats plus spécifiques-au-domaine.

== Mais il n'y aura pas de conflits de nommage ==
L'aspect social des microformats [[process-fr|Processus] est tel que les conflits devraient être empêchés. Le but est de garder les choses aussi simples que possible en se concentrant seulement sur les problèmes '''existants''' bien définis, plutôt que d'essayer de faire "bouillir l'océan" (résoudre le cas général hypothétique).

== Ainsi comment fais-je pour obtenir les données ==
Voir [http://www.w3.org/TeamSubmission/grddl/ GRDDL] ([http://www.w3.org/2004/01/rdxh/spec plus ancienne version])

Voir aussi : [http://www.w3.org/2006/05/08-htmltf-minutes.html#item03 hGRDDL proposal]

== N'y a t'il pas un conflit entre la sémantique de XFN et FOAF==

L'utilisation de la page URI dans XFN pour identifier une personne semble être en conflit avec l'approche par référence de FOAF, et d'esquinter le potentiel pour dire des choses à propos de la page elle-même. Néanmoins en pratique ce n'est pas un problème. Il est possible de parser le document sous XFN (en utilisant par ex. [http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl grokXFN.xsl]) pour extraire les déclarations apparentées à la personne par ex.
<pre>
_:personA foaf:homepage <http://exemple.org/cette-page> .
_:personA foaf:knows _:personB .
_:personB foaf:homepage <http://exemple.org/page-liée> .
</pre>
- et parser ''indépendamment'' le document en utilisant d'autres mappings de formats (par ex. [http://www.w3.org/2000/06/dc-extract/dc-extract.xsl dc-extract.xsl]) pour obtenir d'autres déclarations, par ex.
<pre>
<http://exemple.org/cette-page> dc:creator "Le Créateur" .
</pre>

Voir aussi : [http://www.w3.org/2003/g/td/xfn-workalike XFN sur le GRDDL], [http://www.oreillynet.com/pub/wlg/8281 XFN Delusions of Grandeur], [http://www.microformats.org/blog/2005/11/02/xfn-grandeur/ XFN Grandeur], [http://dannyayers.com/archives/2005/11/03/xfn-vs-foaf/ XFN vs. FOAF]

== Quels autres travaux ont été produits avec les microformats et RDF ==
* [http://www.w3.org/2003/g/td/xfn-workalike XFN sur le GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ travaux de mises à jour de la spécification avec les Microformats]

== Y'a t'il des Schémas pour les Microformats ==
Une sorte. La spécification primaire est XHTML, mais HTML4 fournit un mécanisme (l'attribut 'profile' de l'élément <head>) pour pointer vers un profil de méta-donnée qui définit les propriétés et valeurs. Il existe un format (fondé sur HTML) spécifié pour les profils microformat - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Notez que les URLs de XMDP pour spécifier les termes sont compatibles avec celles utilisées par RDF, avec "#term" à la fin.

== Quels sont les vocabulaires RDF (et XSLT) disponbiles correspondants aux microformats ==
Voir les [http://esw.w3.org/topic/MicroModels MicroModels] (sur le wiki ESW)

== Est-ce que ce n'est pas simplement de la friction ==
Non. Parce que les microformats (devraient) incluent les URI(s) pour chaque profil utilisé, et les profils sont clairement définis, les données explicites contenues dans un document peuvent être extraites par un parsage.

=== Qui d'autre est en train de regarder RDF et les microformats==
Beaucoup de monde. Y compris : [http://www.w3.org/People/Connolly/ Dan Connolly], [http://internetalchemy.org/ Ian Davis], [http://sw.deri.org/~jbreslin/ John Breslin], [http://dannyayers.com Danny Ayers]....

== Comment puis-je m'impliquer ==
Si vous utilisez le web, vous *êtes* déjà impliqué ! Le prochain endroit à visiter est le site [http://microformats.org/ microformats.org] et peut-être vous enregistrer sur quelques [http://microformats.org/discuss/ listes de discussion] (en particulier celle de [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss]). Il existe aussi un canal [ircs://irc.libera.chat:6697/microformats #microformats sur libera.chat]. Nous avons aussi besoin de traducteurs pour amorcer la communauté francophone des [http://microformateurs.org/ microformateurs].

process-faq-fr

2022-02-16T16:39:31Z

Barnabywalters:

<h1>microformats processus FAQ</h1>
Cette page est là pour documenter les Q&R concernant le [[process-fr|processus]] des microformats. Si vous avez une nouvelle question à poser, considérez svp de la poser tout d'abord sur le [ircs://irc.libera.chat:6697/microformats canal irc microformats] (de préférence) ou sur la liste de discussion [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss]. Les nouvelles questions et réponses devraient être ajoutées en fin de liste. Si vous avez une nouvelle question mais pas de réponse, ajoutez-là svp à [[process-issues-fr|processus-problématiques]].

<h2>Editer cette Page</h2>
SVP, n'utilisez pas de "?" ou tout autre signe de ponctuation dans les titres - cela aide à maintenir les URLs vers leurs identifiants fragments plus courts et plus faciles à lire, copier/coller. Voir [[how-to-play-fr|comment jouer]] pour en savoir plus sur les lignes de conduite de modification du wiki.

<h2> Q&R </h2>
__TOC__
=== Pourquoi perdre du temps à barboter dans le HTML friable ===
''Would it not be better for microformats to standardize markup based on the domain model than waste time wading through flakey html?''
* The "gather real world examples" for analysis step of the [[process-fr|process]] is specifically focusing on the <em>data</em> published, and <strong style="text-transform:uppercase">not</strong> the <em>markup</em> patterns (or lack thereof). This is why the <strong>*-examples</strong> step says: <blockquote><p>"Document the schemas implied by the content examples."</p></blockquote>Every word in that sentence matters. <em>implicit</em> schemas, that is, you have to look at the <em>content</em> of the examples and note what abstract notions/fields/properties that people are publishing. That's very deliberate in that it is <strong style="text-transform:uppercase">much</strong> less important (if at all) what flakey html is being used.<p>Analysis of current publishing practices helps us prioritize what problems are worth solving (i.e. there is already demonstrated incentive for people to publish such information) as opposed to what problems are purely theoretical, or wishful thinking (e.g. if only everyone would publish metadata ABC then we could build applications XYZ). In fact, this is probably one of the most important parts of the process. Domain models that don't account for what is published on the real web tend to be less useful on the real web as has been demonstrated by the numerous a priori XML formats that have been proposed but never got any adoption. The XML formats that have gained adoption are those that modeled the data of existing content publishing behaviors (e.g. the Atom format).

<h2>En rapport</h2>
* [[process-fr|processus]]
* [[process-issues-fr|processus-problématiques]]
* [[process-brainstorming-fr|processus-brainstorming]]

faq-template-fr

2022-02-16T16:39:16Z

Barnabywalters:

<h1> ((FORMAT-OU-NOM-SUJET)) FAQ </h1>

Cette page est destinée à documenter les Q&R à propos de ((WIKILIEN-VERS-FORMAT-OU-SUJET))
Si vous avez une nouvelle question à poser, considérez SVP de poser d'abord votre question sur le [ircs://irc.libera.chat:6697/microformats microformats canal irc] (de préférence) ou sur la [http://microformats.org/mailman/listinfo/microformats-discuss/ liste de discussion microformats]. Les nouvelles questions et réponses devraient être ajoutée à la fin de la liste. Si vous avez une nouvelle question mais pas de réponse, ajoutez-la sur ((WIKILIEN-VERS-FORMAT-OU-SUJET-issues-fr)).

<h2>Editer cette Page</h2>
N'utilisez pas SVP de "?" ou tout autre signe de ponctuation dans les titres - cela aide à maintenir des URLs vers leurs identifiants plus courts et plus faciles à lire, à copier-coller, etc. Voir [[how-to-play-fr|comment jouer]] pour en savoir plus sur les lignes de conduite wiki.

<h2> Q&R </h2>

=== ((RESUME-QUESTION-SANS-PONCTUATION)) ===
''((QUESTION COMPLETE))''
* REPONSE COMPLETE

<h2>en rapport</h2>
* ((WIKILIEN-VERS-FORMAT-OU-SUJET))
* ((WIKILIEN-VERS-FORMAT-OU-SUJET-issues-fr))

irc-ja

2022-02-16T16:38:49Z

Barnabywalters: /* Microformats IRC */

__NOTOC__


= Microformats IRC =

microformatsに関するIRCチャンネルがあります。[ircs://irc.libera.chat:6697/microformats freenodeネットワークの#microformats]にjoinしてください。文字エンコーディングはUTF-8を推奨します。

また、主に日本語を使う人のためのチャンネルが[irc://irc.freenode.net/microformats-ja freenodeネットワークの#microformats-ja]にあります。文字エンコーディングはUTF-8です。

There's typically someone there at any point during the day, though there isn't always active discussion. Sometimes, though this is the best place to debate issues that need lots of back and forth discussion.

== ログ ==
チャンネルのログ: http://rbach.priv.at/Microformats-IRC/

ログはAtomフィードでも取得可能です: http://microformat.makedatamakesense.com/log_feed/

== IRCにいる人々 ==

IRCによくいる人のリストとその人の通常のタイムゾーンについては[[irc-people|list of IRC regulars]]を見てください。

以下は日本語が通じる人のリストです。

* [[User:Vantguarde|vant]] (+0900)
**can read/write/talk in English. Et mon francais n'est pas très bon, mais je le comprend un peu.
* [[User:IwaiMasaharu|iwaim]] (+0900)
* [[User:TaichiKaminogoya|goya]] (+0900)

== 挨拶 ==
チャンネルにjoinしたときに簡単な自己紹介を流すことができます。<tt>?def</tt>コマンドを持ちいて次のように自己紹介文を登録してください。

<code>?def jdoe is John Doe and can be found online at <nowiki>http://www.example.com</nowiki></code>

JiBotに関する情報は[http://joiwiki.ito.com/joiwiki/index.cgi?jibot jibotのウェブサイト]をご覧下さい。

== ボット ==

The IRC channel uses these bots:
* [[mfbot]]
* [[mflogbot]]
* [http://joiwiki.ito.com/joiwiki/index.cgi?jibot jibot]

==Meetups==

The idea of having IRC meetups (that is, a set time for meeting on IRC) has been suggested by [[User:RyanKing|Ryan King]], as it appears to work well for the WordPress community and may help us from time-to-time. As of yet, there are no plans to have meetups, though.

==Clients==

The following clients are recommended by #microformats participants:

===Windows===

* [http://www.mirc.com/ mIRC] - Popular Windows client. Trial version only.
* [http://xchat.org/ X-Chat] - Popular cross-platform client. [http://www.silverex.org/download/ Free Windows version] available.
* [http://www.adiirc.com/ AdiIRC] - Simple C# based IRC client.
* [http://www.miranda-im.org/ Miranda] - Lightweight, muti-protocol instant messenger.

===Mac===

* [http://colloquy.info Colloquy] -- open source, free
* [http://sourceforge.net/projects/fire Fire] -- open source, free
* [http://www.snak.com/ Snak]
* [http://xchataqua.sourceforge.net/twiki/bin/view/Main/WebHome XChat Aqua] -- X11 based IRC chat
* [http://homepage.mac.com/philrobin/conversation/ Conversation]
* [http://www.chipersoft.com/minerva/ Minerva]
* [http://www.aquaticx.com/ Xirc]

===Cross-platform===
* [http://www.hacksrus.com/~ginda/chatzilla/ Chatzilla] - Cross-platform IRC extension for Firefox
* [http://irssi.org/ Irssi] - Unix client, often run from a shell, sometimes [http://f0rked.com/articles/irssi in conjunction with 'screen'].
* [http://gaim.sourceforge.net/ Gaim] - Cross-platform multi-protocol instant messenger.
* [http://jirc.hick.org/jirc/ jIRCii]

gender

2021-06-22T21:59:34Z

Barnabywalters: /* see also */ linked pronouns

{{DISPLAYTITLE:gender}}

As of 2011-08, [[vCard4]] has been published with a "gender" property:
* http://tools.ietf.org/html/rfc6350#section-6.2.7
Largely based on the research here and [https://wiki.mozilla.org/VCard4#section_6.2.7._GENDER feedback documented on the Mozilla vCard4 wiki page].

Per the microformats [[process]]:
* [[gender-examples]]
* [[gender-formats]]
* [[gender-brainstorming]]

== see also ==
* [[vcard-suggestions#Gender]]
* [[genealogy-brainstorming#Gender]]
* [[hcard-faq#How_is_gender_represented]]
* [[pronouns]]
* [[interested-in]]
* [[looking-for]]
* [[relationship-status]]

== related articles ==
* 2011-09-30 NYT: [http://www.nytimes.com/2011/10/02/fashion/choosing-a-pronoun-he-she-or-other-after-curfew.html The Freedom To Choose Your Pronoun]

microformats2-experimental-properties

2021-06-22T21:59:11Z

Barnabywalters: /* p-x-pronoun-* */

== h-as-* ==
ActivityStreams-based post types, usually done in combination with h-entry.

=== Usage ===

* [http://glennjones.net/ glennjones.net] ([http://glennjones.net/notes/2015-07-11 example: h-as-note])

Formerly:
* tantek.com - used to (~2014) use h-as-article and h-as-note but decided this type of explicit typing was unnecessary from a format perspective so dropped them. [[User:Tantek|Tantek]] 19:52, 11 July 2015 (UTC)

== h-x-username ==

=== Usage ===

* [http://glennjones.net/ glennjones.net] ([http://glennjones.net/notes/2015-07-11 example])
* [http://tantek.com/ tantek.com] ([http://tantek.com/2015/191/t1/indiewebcamp-pre-party example])

how is this different from [[h-card]]'s p-nickname ? [[User:Kevin Marks|Kevin Marks]]

== p-x-dietary-preference ==

For dietary preferences (vegetarian, vegan etc.) - the intention is to help event organisers organise catering by aggregating together the dietary preferences of attendees.

=== Suggested values ===
* ovo-lacto vegetarian
* lacto vegetarian
* ovo vegetarian
* vegan
* pescatarian
* omnivore
* gluten-free
* lactose-free

=== Usage ===
* [https://tommorris.org/ tommorris.org]

== p-x-pronoun-* ==

See the [[pronouns]] page for more pronoun discussion, examples, and alternative properties.

Properties to identify a user's preferred pronouns

; p-x-pronoun-nominative: the user's preferred nominative pronoun (e.g. he, she, they)
; p-x-pronoun-oblique: the user's preferred oblique pronoun (e.g. him, her, them)
; p-x-pronoun-possessive: the user's preferred possessive pronoun (e.g. his, hers, theirs)

=== Usage ===

* [https://waterpigs.co.uk/ waterpigs.co.uk]
* [https://unrelenting.technology/ unrelenting.technology]
* [[User:GRegorLove|gRegor]] on https://gregorlove.com/about

== p-x-sexual-orientation ==

For when we eventually build the open web dating service.

;Suggested values:
:* straight or heterosexual
:* bisexual
:* pansexual
:* gay or lesbian or homosexual
:* asexual

=== Usage ===
* [https://tommorris.org/ tommorris.org]

microformats2-experimental-properties

2021-06-22T21:59:01Z

Barnabywalters: /* p-x-pronoun-* */ linked to pronouns

== h-as-* ==
ActivityStreams-based post types, usually done in combination with h-entry.

=== Usage ===

* [http://glennjones.net/ glennjones.net] ([http://glennjones.net/notes/2015-07-11 example: h-as-note])

Formerly:
* tantek.com - used to (~2014) use h-as-article and h-as-note but decided this type of explicit typing was unnecessary from a format perspective so dropped them. [[User:Tantek|Tantek]] 19:52, 11 July 2015 (UTC)

== h-x-username ==

=== Usage ===

* [http://glennjones.net/ glennjones.net] ([http://glennjones.net/notes/2015-07-11 example])
* [http://tantek.com/ tantek.com] ([http://tantek.com/2015/191/t1/indiewebcamp-pre-party example])

how is this different from [[h-card]]'s p-nickname ? [[User:Kevin Marks|Kevin Marks]]

== p-x-dietary-preference ==

For dietary preferences (vegetarian, vegan etc.) - the intention is to help event organisers organise catering by aggregating together the dietary preferences of attendees.

=== Suggested values ===
* ovo-lacto vegetarian
* lacto vegetarian
* ovo vegetarian
* vegan
* pescatarian
* omnivore
* gluten-free
* lactose-free

=== Usage ===
* [https://tommorris.org/ tommorris.org]

== p-x-pronoun-* ==

See the [[pronouns] page for more pronoun discussion, examples, and alternative properties.

Properties to identify a user's preferred pronouns

; p-x-pronoun-nominative: the user's preferred nominative pronoun (e.g. he, she, they)
; p-x-pronoun-oblique: the user's preferred oblique pronoun (e.g. him, her, them)
; p-x-pronoun-possessive: the user's preferred possessive pronoun (e.g. his, hers, theirs)

=== Usage ===

* [https://waterpigs.co.uk/ waterpigs.co.uk]
* [https://unrelenting.technology/ unrelenting.technology]
* [[User:GRegorLove|gRegor]] on https://gregorlove.com/about

== p-x-sexual-orientation ==

For when we eventually build the open web dating service.

;Suggested values:
:* straight or heterosexual
:* bisexual
:* pansexual
:* gay or lesbian or homosexual
:* asexual

=== Usage ===
* [https://tommorris.org/ tommorris.org]

pronouns-formats

2021-06-22T21:57:43Z

Barnabywalters: Stubbed with vcard mailing list discussion

This page is for documenting existing, stable standards and formats for publishing [[pronouns|pronoun]] information.

== vCard ==

* [https://mailarchive.ietf.org/arch/msg/vcarddav/FCjVznQHsmtPPLmv2z69OcxL8u0/ VCARDDAV mailing list discussion on adding a pronoun property]

pronouns-brainstorming

2021-06-22T21:51:11Z

Barnabywalters: Stubbed, moved content from h-card-brainstorming

This page is for proposing and experimenting with markup for publishing [[pronouns|pronoun]] information, as well as documenting experimental markup already in use.

== Experimental Examples ==

Ashton McAllan marks up her pronouns as:
<source lang=html4strict>
<span class="p-x-pronoun-nominative">she</span> /
<span class="p-x-pronoun-oblique">her</span> /
<span class="p-x-pronoun-posessive">hers</span>
</source>
in her [[h-card]] on http://acegiak.net/

Each pronoun is listed individually with it's form allowing parsers and programs to identify them for different uses. Other languages may include different forms of pronoun. This solution is suggested after reading [https://en.wikipedia.org/wiki/Personal_pronoun the Wikipedia Personal Pronouns article]

[[User:GRegorLove|gRegor Morrill]] marks up his pronouns similarly (note corrected spelling of "possessive"):
<source lang=html4strict>
<p>Pronouns: <span class="p-x-pronoun-nominative">he</span>/
<span class="p-x-pronoun-oblique">him</span>/
<span class="p-x-pronoun-possessive">his</span></p>
</source>
on http://gregorlove.com/about/

[https://www.jvt.me/ Jamie Tanna] followed this same pattern, and [https://www.jvt.me/posts/2019/04/10/pronouns-microformats/ blogged about implementing it, and why].

[[User:Jgarber|Jason Garber]] marks up his pronouns using the pattern:
<source lang=html4strict>
<p>
I use the pronouns
<a href="https://my.pronoun.is/he/him/his">
<span class="p-x-pronoun-nominative">he</span>/
<span class="p-x-pronoun-oblique">him</span>/
<span class="p-x-pronoun-possessive">his</span>
</a>.
</p>
</source>

[http://vanderven.se/martijn/ Martijn van der Ven] marks up his pronouns (more clearly on [http://vanderven.se/martijn/gender/ his gender page]) using only a dictionary URL:
<source lang=html4strict>
<p>
I use male pronouns (
<a href="https://nl.wiktionary.org/wiki/hij#Persoonlijk_voornaamwoord" lang="nl" class="u-pronoun">hij</a>,
<a href="https://sv.wiktionary.org/wiki/han#Pronomen" lang="sv" class="u-pronoun">han</a>,
<a href="https://en.wiktionary.org/wiki/he#Pronoun" class="u-pronoun">he</a>,
<a href="https://de.wiktionary.org/wiki/er#Personalpronomen" lang="de" class="u-pronoun">er</a>
) but also accept gender-neutral pronouns (
<a href="https://sv.wiktionary.org/wiki/hen#Pronomen" lang="sv" class="u-pronoun">hen</a>,
<a href="https://en.wiktionary.org/wiki/they#Pronoun" class="u-pronoun">they</a>
). If you are writing about me and are in doubt: ask.
</p></source>

* There is no way Martijn sees himself supporting 4 cases for English (subjective, objective, reflexive, and possessive), 5 cases for German (nominative, accusative, genitive, dative, and possessive), and a possible 13 cases for Finnish in the future. Doubtful anyone else will be doing that either: at least 1 implementation (by [https://unrelenting.technology/ Greg V]) of English p-x-pronoun-* exists in the wild that only specifies 2 cases.
* Simplifying for human visitors who can instantly get started with my pronoun of choice is seen as more important than catering to theoretical computer parsers.
* His thought process [http://wiki.zegnat.net/microformats/pronoun has been documented].
* [https://00dani.me/ Danielle McLean] is also using <code>u-pronoun</code>, linking to the popular [https://pronoun.is/ Pronoun Island] registry page for her pronouns: <code><nowiki><a class="u-pronoun" href="https://pronoun.is/she/her">she/her</a></nowiki></code>.
** Started looking for a way to mark-up pronouns because the p-sex/p-gender-identity combo is “[https://chat.indieweb.org/2017-10-29/1509268972735000 unbelievably terrible]”.
** [https://chat.indieweb.org/2017-10-29/1509269322353000 Agreed with Martijn’s arguments] for why a link is better than per-case mark-up.
* [[User:Sknebel|sknebel]] [https://chat.indieweb.org/microformats/2018-08-19#t1534703222243600 notes] (2018-08-19) that he would prefer to see text (that possibly leads him to Google for proper use) than just URLs in the parser output. Although the URLs are useful, [https://chat.indieweb.org/microformats/2018-08-19#t1534705418184500 a simple name:url pair] would increase the usefulness.
** Possibly something like <code>.[up]-pronoun.h-pronoun > .u-url</code> paired with <code>.[up]-pronoun.h-pronoun > .p-name</code>. [[h-cite]] would be prior art as also expressing “a reference to <i>[something]</i> in some way with name and url”. [https://chat.indieweb.org/microformats/2018-08-19/1534705492641900]

== Other Platforms ==
A [https://github.com/tootsuite/mastodon/issues/3211 GitHub issue about adding pronoun fields] to [https://indieweb.org/Mastodon Mastodon] was [https://chat.indieweb.org/microformats/2018-08-19#t1534700249077000 discussed in #microformats] on 2018-08-19. The comments in the issue bring up some points previously brought up by Martijn in regards to how useful it would be for machines. Also includes interesting survey data showing that just listing the minimal amount of cases does not show all inflections, e.g. does “ne/nim” refer to “ne/nem/neir/neirs/nemself” or “ne/nem/nayr/nayrs/nemself”?

h-card-brainstorming

2021-06-22T21:49:04Z

Barnabywalters: /* Explorations */ moved pronoun content to pronouns-brainstorming

{{stub}}

{{DISPLAYTITLE:h-card Brainstorming }}
This page is for brainstorming about various uses, details of, and additions to [[h-card]].

This page contains <em>proposals</em>. For the current state please see [[h-card]].

__TOC__
Brainstorm proposals that illustrate how to use the existing hCard spec will likely be incorporated into existing hCard documentation such as:
* [[h-card-authoring]]
* [[h-card-examples]]
* ... and potentially additional documentation.

== Explorations ==
Add new explorations here as === === triple level headings

=== Pronouns ===
See [[pronouns-brainstorming]]

== See Also ==
* [[h-card]]
* [[hcard-brainstorming]] - for additional proposals to bring forth to h-card

pronouns-examples

2021-06-22T21:47:28Z

Barnabywalters: /* Sites and Services */ bagcheck.com example

This page documents specific examples of how [[pronouns|pronoun]] information is currently published on the web, as well as UIs which support pronoun fields.

== Sites and Services ==
Examples of sites/software which allow their users to specify their pronouns, either to be displayed in a profile, or to configure pronouns used by the software to refer to the user.

* [https://bagcheck.com/blog/01-the-gender-question Bagcheck] chose to ask which pronoun you want to use:
** Preferred Possessive Pronoun: ( )Her ( )His ( )Their
* MediaWiki.org has radio button choice on Preferences: "(I prefer not to say)", "She edits wiki pages", "He edits wiki pages"
* MetaFilter updated their user profile field from "Gender" to "Gender and/or pronouns" [http://metatalk.metafilter.com/24423/Making-room-for-pronouns-on-the-profile-page]
* …

== Incidentally in Profiles ==
Examples of pronoun information published by people on sites which don’t explicitly implement pronoun support, e.g. as part of a description field in their profile.

* https://twitter.com/rknLA <q>he/him</q> in profile
* [https://twitter.com/abbieandahalf @abbieandahalf] has "they/them" in their Twitter bio
* [https://twitter.com/brianloveswords @brianloveswords] has "he/him" in his Twitter bio
* [https://twitter.com/lindseybieda @lindseybieda] has "she/her" in her Twitter bio
* [https://twitter.com/jneen_ @jneen_] has http://pronoun.is/she in her Twitter bio
* [http://my.pronoun.is my.pronoun.is] (or just [http://pronoun.is pronoun.is]) is a little website that offers a way to show your pronouns on a silo profile using a link, e.g. [http://my.pronoun.is/they/them my.pronoun.is/they/them]
* …

== Personal Sites ==
See also: [https://indieweb.org/pronoun#IndieWeb_Examples pronoun#Indieweb Examples]

Examples of people who publish pronoun information on their personal sites, sometimes with experimental microformats2 properties.

* http://acegiak.net as of 2015-02-18 using experimental <code>p-x-pronoun-*</code> property classes in an h-card
* http://gregorlove.com/about as of 2015-03-12 using experimental <code>p-x-pronoun-*</code> property classes in an h-card
* http://vanderven.se/martijn/ on 2017-05-21 using experimental <code>u-pronoun</code> property classes in an h-card to link to language-specific wiktionary.org pages for each pronoun
* https://00dani.me/ using experimental a <code>u-pronoun</code> property class linking to a pronoun.is page
* https://aaronparecki.com/about/ plain text <q>He / Him</q> inside an h-card
* https://www.jvt.me on [https://www.jvt.me/posts/2019/04/10/pronouns-microformats/ 2019-04-10] using experimental <code>[x-]pronoun-*</code> property classes in an h-card
* [https://sixtwothree.org sixtwothree.org] on 2019-08-27 using experimental <code>x-pronoun-*</code> property classes in an h-card, also linked to my.pronoun.is
* beesbuzz[.]biz/about on 2018-11-16, and to the representative h-card on 2019-12-06 using experimental <code>p-pronouns</code> and <code>p-pronoun-*</code> property classes inside an h-card: <q>she/her or they/them</q>
* https://tantek.com h-card on 2020-10-22 using p-pronouns for the full set as a string, and p-pronoun h-pronoun for each individual pronoun linked to a URL explaining its use.
* https://waterpigs.co.uk using experimental <code>x-pronoun-*</code> classes in an h-card: <q>Pronouns: he/him/his</q>
* …

pronouns-examples

2021-06-22T21:46:32Z

Barnabywalters:

This page documents specific examples of how [[pronouns|pronoun]] information is currently published on the web, as well as UIs which support pronoun fields.

== Sites and Services ==
Examples of sites/software which allow their users to specify their pronouns, either to be displayed in a profile, or to configure pronouns used by the software to refer to the user.

* MediaWiki.org has radio button choice on Preferences: "(I prefer not to say)", "She edits wiki pages", "He edits wiki pages"
* MetaFilter updated their user profile field from "Gender" to "Gender and/or pronouns" [http://metatalk.metafilter.com/24423/Making-room-for-pronouns-on-the-profile-page]
* …

== Incidentally in Profiles ==
Examples of pronoun information published by people on sites which don’t explicitly implement pronoun support, e.g. as part of a description field in their profile.

* https://twitter.com/rknLA <q>he/him</q> in profile
* [https://twitter.com/abbieandahalf @abbieandahalf] has "they/them" in their Twitter bio
* [https://twitter.com/brianloveswords @brianloveswords] has "he/him" in his Twitter bio
* [https://twitter.com/lindseybieda @lindseybieda] has "she/her" in her Twitter bio
* [https://twitter.com/jneen_ @jneen_] has http://pronoun.is/she in her Twitter bio
* [http://my.pronoun.is my.pronoun.is] (or just [http://pronoun.is pronoun.is]) is a little website that offers a way to show your pronouns on a silo profile using a link, e.g. [http://my.pronoun.is/they/them my.pronoun.is/they/them]
* …

== Personal Sites ==
See also: [https://indieweb.org/pronoun#IndieWeb_Examples pronoun#Indieweb Examples]

Examples of people who publish pronoun information on their personal sites, sometimes with experimental microformats2 properties.

* http://acegiak.net as of 2015-02-18 using experimental <code>p-x-pronoun-*</code> property classes in an h-card
* http://gregorlove.com/about as of 2015-03-12 using experimental <code>p-x-pronoun-*</code> property classes in an h-card
* http://vanderven.se/martijn/ on 2017-05-21 using experimental <code>u-pronoun</code> property classes in an h-card to link to language-specific wiktionary.org pages for each pronoun
* https://00dani.me/ using experimental a <code>u-pronoun</code> property class linking to a pronoun.is page
* https://aaronparecki.com/about/ plain text <q>He / Him</q> inside an h-card
* https://www.jvt.me on [https://www.jvt.me/posts/2019/04/10/pronouns-microformats/ 2019-04-10] using experimental <code>[x-]pronoun-*</code> property classes in an h-card
* [https://sixtwothree.org sixtwothree.org] on 2019-08-27 using experimental <code>x-pronoun-*</code> property classes in an h-card, also linked to my.pronoun.is
* beesbuzz[.]biz/about on 2018-11-16, and to the representative h-card on 2019-12-06 using experimental <code>p-pronouns</code> and <code>p-pronoun-*</code> property classes inside an h-card: <q>she/her or they/them</q>
* https://tantek.com h-card on 2020-10-22 using p-pronouns for the full set as a string, and p-pronoun h-pronoun for each individual pronoun linked to a URL explaining its use.
* https://waterpigs.co.uk using experimental <code>x-pronoun-*</code> classes in an h-card: <q>Pronouns: he/him/his</q>
* …

pronouns-examples

2021-06-22T21:46:11Z

Barnabywalters: /* Sites and Services */ de-IWified

This page documents specific examples of how [[pronouns|pronoun]] information is currently published on the web, as well as UIs which support pronoun fields.

== Sites and Services ==
Examples of sites/software which allow their users to specify their pronouns, either to be displayed in a profile, or to configure pronouns used by the software to refer to the user.

* MediaWiki.org has radio button choice on Preferences: "(I prefer not to say)", "She edits wiki pages", "He edits wiki pages"
* MetaFilter updated their user profile field from "Gender" to "Gender and/or pronouns" [http://metatalk.metafilter.com/24423/Making-room-for-pronouns-on-the-profile-page |published=2017-05-15]
* …

== Incidentally in Profiles ==
Examples of pronoun information published by people on sites which don’t explicitly implement pronoun support, e.g. as part of a description field in their profile.

* https://twitter.com/rknLA <q>he/him</q> in profile
* [https://twitter.com/abbieandahalf @abbieandahalf] has "they/them" in their Twitter bio
* [https://twitter.com/brianloveswords @brianloveswords] has "he/him" in his Twitter bio
* [https://twitter.com/lindseybieda @lindseybieda] has "she/her" in her Twitter bio
* [https://twitter.com/jneen_ @jneen_] has http://pronoun.is/she in her Twitter bio
* [http://my.pronoun.is my.pronoun.is] (or just [http://pronoun.is pronoun.is]) is a little website that offers a way to show your pronouns on a silo profile using a link, e.g. [http://my.pronoun.is/they/them my.pronoun.is/they/them]
* …

== Personal Sites ==
See also: [https://indieweb.org/pronoun#IndieWeb_Examples pronoun#Indieweb Examples]

Examples of people who publish pronoun information on their personal sites, sometimes with experimental microformats2 properties.

* http://acegiak.net as of 2015-02-18 using experimental <code>p-x-pronoun-*</code> property classes in an h-card
* http://gregorlove.com/about as of 2015-03-12 using experimental <code>p-x-pronoun-*</code> property classes in an h-card
* http://vanderven.se/martijn/ on 2017-05-21 using experimental <code>u-pronoun</code> property classes in an h-card to link to language-specific wiktionary.org pages for each pronoun
* https://00dani.me/ using experimental a <code>u-pronoun</code> property class linking to a pronoun.is page
* https://aaronparecki.com/about/ plain text <q>He / Him</q> inside an h-card
* https://www.jvt.me on [https://www.jvt.me/posts/2019/04/10/pronouns-microformats/ 2019-04-10] using experimental <code>[x-]pronoun-*</code> property classes in an h-card
* [https://sixtwothree.org sixtwothree.org] on 2019-08-27 using experimental <code>x-pronoun-*</code> property classes in an h-card, also linked to my.pronoun.is
* beesbuzz[.]biz/about on 2018-11-16, and to the representative h-card on 2019-12-06 using experimental <code>p-pronouns</code> and <code>p-pronoun-*</code> property classes inside an h-card: <q>she/her or they/them</q>
* https://tantek.com h-card on 2020-10-22 using p-pronouns for the full set as a string, and p-pronoun h-pronoun for each individual pronoun linked to a URL explaining its use.
* https://waterpigs.co.uk using experimental <code>x-pronoun-*</code> classes in an h-card: <q>Pronouns: he/him/his</q>
* …

pronouns-examples

2021-06-22T21:45:33Z

Barnabywalters: /* Sites and Services */ added metafilter example

This page documents specific examples of how [[pronouns|pronoun]] information is currently published on the web, as well as UIs which support pronoun fields.

== Sites and Services ==
Examples of sites/software which allow their users to specify their pronouns, either to be displayed in a profile, or to configure pronouns used by the software to refer to the user.

* MediaWiki.org has radio button choice on Preferences: "(I prefer not to say)", "She edits wiki pages", "He edits wiki pages"
* [[MetaFilter]] updated their user profile field from "Gender" to "Gender and/or pronouns"
** {{citation |title=
Making room for pronouns on the profile page |url=http://metatalk.metafilter.com/24423/Making-room-for-pronouns-on-the-profile-page |published=2017-05-15 |author=<a href="http://www.metafilter.com/user/7418" class="h-card">Josh Millard</a> |archiveurl=http://web.archive.org/web/20170515204711/http://metatalk.metafilter.com/24423/Making-room-for-pronouns-on-the-profile-page }}
* …

== Incidentally in Profiles ==
Examples of pronoun information published by people on sites which don’t explicitly implement pronoun support, e.g. as part of a description field in their profile.

* https://twitter.com/rknLA <q>he/him</q> in profile
* [https://twitter.com/abbieandahalf @abbieandahalf] has "they/them" in their Twitter bio
* [https://twitter.com/brianloveswords @brianloveswords] has "he/him" in his Twitter bio
* [https://twitter.com/lindseybieda @lindseybieda] has "she/her" in her Twitter bio
* [https://twitter.com/jneen_ @jneen_] has http://pronoun.is/she in her Twitter bio
* [http://my.pronoun.is my.pronoun.is] (or just [http://pronoun.is pronoun.is]) is a little website that offers a way to show your pronouns on a silo profile using a link, e.g. [http://my.pronoun.is/they/them my.pronoun.is/they/them]
* …

== Personal Sites ==
See also: [https://indieweb.org/pronoun#IndieWeb_Examples pronoun#Indieweb Examples]

Examples of people who publish pronoun information on their personal sites, sometimes with experimental microformats2 properties.

* http://acegiak.net as of 2015-02-18 using experimental <code>p-x-pronoun-*</code> property classes in an h-card
* http://gregorlove.com/about as of 2015-03-12 using experimental <code>p-x-pronoun-*</code> property classes in an h-card
* http://vanderven.se/martijn/ on 2017-05-21 using experimental <code>u-pronoun</code> property classes in an h-card to link to language-specific wiktionary.org pages for each pronoun
* https://00dani.me/ using experimental a <code>u-pronoun</code> property class linking to a pronoun.is page
* https://aaronparecki.com/about/ plain text <q>He / Him</q> inside an h-card
* https://www.jvt.me on [https://www.jvt.me/posts/2019/04/10/pronouns-microformats/ 2019-04-10] using experimental <code>[x-]pronoun-*</code> property classes in an h-card
* [https://sixtwothree.org sixtwothree.org] on 2019-08-27 using experimental <code>x-pronoun-*</code> property classes in an h-card, also linked to my.pronoun.is
* beesbuzz[.]biz/about on 2018-11-16, and to the representative h-card on 2019-12-06 using experimental <code>p-pronouns</code> and <code>p-pronoun-*</code> property classes inside an h-card: <q>she/her or they/them</q>
* https://tantek.com h-card on 2020-10-22 using p-pronouns for the full set as a string, and p-pronoun h-pronoun for each individual pronoun linked to a URL explaining its use.
* https://waterpigs.co.uk using experimental <code>x-pronoun-*</code> classes in an h-card: <q>Pronouns: he/him/his</q>
* …

pronouns-examples

2021-06-22T21:45:17Z

Barnabywalters: /* Incidentally in Profiles */ added some more examples from IW

This page documents specific examples of how [[pronouns|pronoun]] information is currently published on the web, as well as UIs which support pronoun fields.

== Sites and Services ==
Examples of sites/software which allow their users to specify their pronouns, either to be displayed in a profile, or to configure pronouns used by the software to refer to the user.

* MediaWiki.org has radio button choice on Preferences: "(I prefer not to say)", "She edits wiki pages", "He edits wiki pages"
* …

== Incidentally in Profiles ==
Examples of pronoun information published by people on sites which don’t explicitly implement pronoun support, e.g. as part of a description field in their profile.

* https://twitter.com/rknLA <q>he/him</q> in profile
* [https://twitter.com/abbieandahalf @abbieandahalf] has "they/them" in their Twitter bio
* [https://twitter.com/brianloveswords @brianloveswords] has "he/him" in his Twitter bio
* [https://twitter.com/lindseybieda @lindseybieda] has "she/her" in her Twitter bio
* [https://twitter.com/jneen_ @jneen_] has http://pronoun.is/she in her Twitter bio
* [http://my.pronoun.is my.pronoun.is] (or just [http://pronoun.is pronoun.is]) is a little website that offers a way to show your pronouns on a silo profile using a link, e.g. [http://my.pronoun.is/they/them my.pronoun.is/they/them]
* …

== Personal Sites ==
See also: [https://indieweb.org/pronoun#IndieWeb_Examples pronoun#Indieweb Examples]

Examples of people who publish pronoun information on their personal sites, sometimes with experimental microformats2 properties.

* http://acegiak.net as of 2015-02-18 using experimental <code>p-x-pronoun-*</code> property classes in an h-card
* http://gregorlove.com/about as of 2015-03-12 using experimental <code>p-x-pronoun-*</code> property classes in an h-card
* http://vanderven.se/martijn/ on 2017-05-21 using experimental <code>u-pronoun</code> property classes in an h-card to link to language-specific wiktionary.org pages for each pronoun
* https://00dani.me/ using experimental a <code>u-pronoun</code> property class linking to a pronoun.is page
* https://aaronparecki.com/about/ plain text <q>He / Him</q> inside an h-card
* https://www.jvt.me on [https://www.jvt.me/posts/2019/04/10/pronouns-microformats/ 2019-04-10] using experimental <code>[x-]pronoun-*</code> property classes in an h-card
* [https://sixtwothree.org sixtwothree.org] on 2019-08-27 using experimental <code>x-pronoun-*</code> property classes in an h-card, also linked to my.pronoun.is
* beesbuzz[.]biz/about on 2018-11-16, and to the representative h-card on 2019-12-06 using experimental <code>p-pronouns</code> and <code>p-pronoun-*</code> property classes inside an h-card: <q>she/her or they/them</q>
* https://tantek.com h-card on 2020-10-22 using p-pronouns for the full set as a string, and p-pronoun h-pronoun for each individual pronoun linked to a URL explaining its use.
* https://waterpigs.co.uk using experimental <code>x-pronoun-*</code> classes in an h-card: <q>Pronouns: he/him/his</q>
* …

pronouns-examples

2021-06-22T21:43:57Z

Barnabywalters:

pronouns-examples

2021-06-22T21:43:23Z

Barnabywalters: Created page with "This page documents specific examples of how pronoun information is currently published on the web, as well as UIs which support pronoun fields. == Sites and Services == Exam..."

This page documents specific examples of how pronoun information is currently published on the web, as well as UIs which support pronoun fields.

== Sites and Services ==
Examples of sites/software which allow their users to specify their pronouns, either to be displayed in a profile, or to configure pronouns used by the software to refer to the user.

* MediaWiki.org has radio button choice on Preferences: "(I prefer not to say)", "She edits wiki pages", "He edits wiki pages"
* …

== Incidentally in Profiles ==
Examples of pronoun information published by people on sites which don’t explicitly implement pronoun support, e.g. as part of a description field in their profile.

* https://twitter.com/rknLA <q>he/him</q> in profile
* …

== Personal Sites ==
See also: [https://indieweb.org/pronoun#IndieWeb_Examples pronoun#Indieweb Examples]

Examples of people who publish pronoun information on their personal sites, sometimes with experimental microformats2 properties.

* http://acegiak.net as of 2015-02-18 using experimental <code>p-x-pronoun-*</code> property classes in an h-card
* http://gregorlove.com/about as of 2015-03-12 using experimental <code>p-x-pronoun-*</code> property classes in an h-card
* http://vanderven.se/martijn/ on 2017-05-21 using experimental <code>u-pronoun</code> property classes in an h-card to link to language-specific wiktionary.org pages for each pronoun
* https://00dani.me/ using experimental a <code>u-pronoun</code> property class linking to a pronoun.is page
* https://aaronparecki.com/about/ plain text <q>He / Him</q> inside an h-card
* https://www.jvt.me on [https://www.jvt.me/posts/2019/04/10/pronouns-microformats/ 2019-04-10] using experimental <code>[x-]pronoun-*</code> property classes in an h-card
* [https://sixtwothree.org sixtwothree.org] on 2019-08-27 using experimental <code>x-pronoun-*</code> property classes in an h-card, also linked to my.pronoun.is
* beesbuzz[.]biz/about on 2018-11-16, and to the representative h-card on 2019-12-06 using experimental <code>p-pronouns</code> and <code>p-pronoun-*</code> property classes inside an h-card: <q>she/her or they/them</q>
* https://tantek.com h-card on 2020-10-22 using p-pronouns for the full set as a string, and p-pronoun h-pronoun for each individual pronoun linked to a URL explaining its use.
* https://waterpigs.co.uk using experimental <code>x-pronoun-*</code> classes in an h-card: <q>Pronouns: he/him/his</q>
* …

pronouns

2021-06-22T21:12:15Z

Barnabywalters: Stubbed page

Pronouns are words used to stand-in for people’s names. They are often published on the web as part of people’s profiles, and could be candidates for inclusion in a microformats vocabulary e.g. h-card.

== Process ==

* [[pronouns-examples]] documents real-world examples of publishing pronouns
* [[pronouns-formats]] documents existing formats used to publish pronouns
* [[pronouns-brainstorming]] for experimenting with and proposing possible pronoun formats

== See Also ==

* [[gender]]
* [[h-card]]
* [https://en.wikipedia.org/wiki/Pronoun Pronoun on wikipedia]
* [https://indieweb.org/pronoun pronoun on the indieweb wiki]

h-card

2021-06-22T18:52:15Z

Barnabywalters: /* Implementations */ added some of the more notable indieweb software which publishes/consumes h-card

<dfn style="font-style:normal;font-weight:bold">h-card</dfn> is a simple, open format for publishing people and organisations on the web. h-card is often used on home pages and individual blog posts. h-card is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-card is the [[microformats2]] update to [[hCard]].

;<span id="status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [https://github.com/microformats/h-card/issues feedback].
;<span id="participate">Participate</span>
:[https://github.com/microformats/h-card/issues Open Issues]
:[[IRC]]
<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 are a couple of minimal examples:

<source lang=html4strict>
<a class="h-card" href="https://tantek.com/">Tantek Çelik</a>,

<span class="h-card">
<a class="p-name p-org u-url" href="https://microformats.org/">microformats.org</a>
</span>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": ["h-card"],
"properties": {
"name": ["Tantek Çelik"],
"url": ["https://tantek.com/"]
}
},
{
"type": ["h-card"],
"properties": {
"name": ["microformats.org"],
"org": ["microformats.org"],
"url": ["https://microformats.org/"]
}
}
]
}
</source>
Note a single element was sufficient for the simple person example with implied name and URL properties, while for an organization, which requires a name and org, it needed explicit markup for the h-card and all properties, though still with only two elements.

Nested h-card example:

<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="https://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="p-org h-card"
href="https://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["https://blog.lizardwrangler.com/"],
"org": [{
"value": "Mozilla Foundation",
"type": ["h-card"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["https://mozilla.org/"]
}
}]
}
}]
}
</source>

Note: the nested h-card has implied 'name' and 'url' properties, just like any other root-class-name-only h-card on an <code><a href></code> would.

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

For minimal examples where at most <code>p-name</code>, <code>u-url</code> and <code>u-photo</code> are required (such as the first given above), only the root class name is needed — see [[microformats-2-implied-properties|implied properties]].

When more than those three minimal properties are needed, the root class name must be placed on an element which encloses all the desired properties, and then the properties themselves marked up using the classnames given below.

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

== Properties ==
h-card properties, inside an element with class '''h-card'''. All properties are optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

<div style="margin-top:-.4em; float:right;"><span>Example h-card with common properties:</span>
<ul style="list-style:none"><li><code><div class="'''h-card'''"></code>
<ul style="list-style:none; margin-top:-.02em">
<li><code><span class="'''p-name'''">Sally Ride</span></code></li>
<li><code><span class="'''p-honorific-prefix'''">Dr.</span></code></li>
<li><code><span class="'''p-given-name'''">Sally</span></code></li>
<li><code><abbr class="'''p-additional-name'''">K.</abbr></code></li>
<li><code><span class="'''p-family-name'''">Ride</span></code></li>
<li><code><span class="'''p-honorific-suffix'''">Ph.D.</span>,</code></li>
<li><code><span class="'''p-nickname'''">sallykride</span> (IRC)</code></li>
<li><code><div class="'''p-org'''">Sally Ride Science</div></code></li>
<li><code><img class="'''u-photo'''" src="<nowiki>http://example.com/sk.jpg</nowiki>"/> </code></li>
<li><code><a class="'''u-url'''" href="<nowiki>http://sally.example.com</nowiki>">w</a>,</code></li>
<li><code><a class="'''u-email'''" href="<nowiki>mailto:sally@example.com</nowiki>">e</a> </code></li>
<li><code><div class="'''p-tel'''">+1.818.555.1212</div></code></li>
<li><code><div class="'''p-street-address'''">123 Main st.</div></code></li>
<li><code><span class="'''p-locality'''">Los Angeles</span>, </code></li>
<li><code><abbr class="'''p-region'''" title="California">CA</abbr>, </code></li>
<li><code><span class="'''p-postal-code'''">91316</span></code></li>
<li><code><div class="'''p-country-name'''">U.S.A</div></code></li>
<li><code><time class="'''dt-bday'''">1951-05-26</time> birthday</code></li>
<li><code><div class="'''p-category'''">physicist</div></code></li>
<li><code><div class="'''p-note'''">First American woman in space.</div></code></li></ul></li>
<li><code></div></code></li></ul>
</div>
Core properties:
* '''<code>p-name</code>''' - The full/formatted name of the person or organization
* '''<code>p-honorific-prefix</code>''' - e.g. Mrs., Mr. or Dr.
* '''<code>p-given-name</code>''' - given (often first) name
* '''<code>p-additional-name</code>''' - other (e.g. middle) name
* '''<code>p-family-name</code>''' - family (often last) name
* '''<code>p-sort-string</code>''' - string to sort by
* '''<code>p-honorific-suffix</code>''' - e.g. Ph.D, Esq.
* '''<code>p-nickname</code>''' - nickname/alias/handle
* '''<code>u-email</code>''' - email address
* '''<code>u-logo</code>''' - a logo representing the person or organization (e.g. a face icon)
* '''<code>u-photo</code>''' - a photo of the person or organization
* '''<code>u-url</code>''' - home page or other URL representing the person or organization
* '''<code>u-uid</code>''' - universally unique identifier, preferably canonical URL
* '''<code>p-category</code>''' - category/tag
* '''<code>p-adr</code>''' - postal address, optionally embed an [[h-adr]] {{main|h-adr}}
* '''<code>p-post-office-box</code>''' - post office box description if any
* '''<code>p-extended-address</code>''' - apartment/suite/room name/number if any
* '''<code>p-street-address</code>''' - street number + name
* '''<code>p-locality</code>''' - city/town/village
* '''<code>p-region</code>''' - state/county/province
* '''<code>p-postal-code</code>''' - postal code, e.g. US ZIP
* '''<code>p-country-name</code>''' - country name
* '''<code>p-label</code>'''
* '''<code>p-geo</code>''' or '''<code>u-geo</code>''', optionally embed an [[h-geo]] {{main|h-geo}}
* '''<code>p-latitude</code>''' - decimal latitude
* '''<code>p-longitude</code>''' - decimal longitude
* '''<code>p-altitude</code>''' - decimal altitude
* '''<code>p-tel</code>''' - telephone number
* '''<code>p-note</code>''' - additional notes
* '''<code>dt-bday</code>''' - birth date
* '''<code>u-key</code>''' - cryptographic public key e.g. SSH or GPG
* '''<code>p-org</code>''' - affiliated organization, optionally embed an [[h-card]]
* '''<code>p-job-title</code>''' - job title, previously 'title' in [[hCard]], disambiguated.
* '''<code>p-role</code>''' - description of role
* '''<code>u-impp</code>''' per RFC4770, new in vCard4 (RFC 6350)
* '''<code>p-sex</code>''' - biological sex, new in vCard4 (RFC 6350)
* '''<code>p-gender-identity</code>''' - gender identity, new in vCard4 (RFC 6350)
* '''<code>dt-anniversary</code>'''

Experimental properties currently in use in the wild but not (yet) part of the official h-card spec.

* '''<code>u-sound</code>''' - sound file containing the proper pronunciation of the name property, per vCard (RFC 6350).
** Used by [https://vanderven.se/martijn/ Martijn van der Ven] with a clip of his given name.
** Needs a GitHub issue to track.

== Status ==
'''h-card''' is a microformats.org draft specification. Public discussion on h-card 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-card/issues may be filed on GitHub].

h-card is ready to use and implemented in the wild. For backwards compatibility you should also mark up top-level h-cards as classic [[hCard]]s.

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

=== p-adr ===
<code>p-adr</code> can optionally embed an [[h-adr]] to cluster associated structured address properties. E.g. adding "p-adr" to the example earlier:

<source lang=html4strict>
<div class="h-card">
<p class="p-name">Joe Bloggs</p>
<p class="p-adr 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>
</div>
</source>

Q: Why would you use "p-adr" to cluster associated structured address properties?

A: Because if you have more than one structured address, clustering which properties go with which address keeps them deterministically together, instead of depending on array indices or other heuristics.

=== p-tel ===
Note: use of 'value' within 'p-tel' should be automatically handled by the support of the [[value-class-pattern]]. And for now, the former [[hCard]] 'type' subproperty of 'tel' is dropped/ignored. If there is demonstrable documented need for additional tel types (e.g. fax), we can introduce new flat properties as needed (e.g. p-tel-fax).

=== dt-bday ===
Using truncated representations of dates for birth date is often good practice as noted in [https://tools.ietf.org/html/rfc6350#section-4.3.1 the vcard spec] eg
* <code>1985-04</code> for April 1985
* <code>1985</code> for the year 1985
* <code>--04-12</code> for April 12th with no specified year

=== Reserved properties ===
The following properties were supported by the legacy hCard format, but were not carried over to h-card due to lack of real-world usage, or other problems. They are not part of h-card and should not be published, consumed, or proposed.

* '''<code>p-organization-name</code>'''
* '''<code>p-organization-unit</code>'''
* '''<code>p-tz</code>''' — timezone offset
** <q>it's going to be a hard one to "get right", as the way timezones work in vcard/ical is very weird, and timezones as a whole are an iffy thing to denote (quite the disconnect between complexity, automated processing ability, actually representing what a user would want to show/display or already does on their homepage, and actually representing something useful to parse and do something with)</q>
** <q>there's certainly no ecosystem of publishers & consumers supporting p-tz in any meaningful interoperable way</q> — [https://chat.indieweb.org/microformats/2021-06-22/1624385751126500 tantek in #microformats]
* '''<code>dt-rev</code>'''

== Examples in the wild ==
See also: [https://indieweb.org/h-card#IndieWeb_Examples h-card Examples on indieweb.org]

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

* ... add uses of h-card you see in the wild here.
* [http://www.securityjobslondon.co.uk Security Jobs London] uses h-card with legacy [[hCard]] fallback markup (to satisfy [https://search.google.com/structured-data/testing-tool Google's Structured Data Testing Tool]) in the footer of each page
* Brett Comnes marks up his posts with h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his homepage and posts with h-card [http://werd.io/view/51d5097fbed7ded0633a5956 example])
* [https://joelpurra.com/ Joel Purra] uses a hidden h-card with legacy [[hCard]] fallback markup (to satisfy [https://search.google.com/structured-data/testing-tool Google's Structured Data Testing Tool]) on the front page
* [http://eschnou.com/ Laurent Eschenauer] marks his homepage profile up using h-card
* [http://tommorris.org/ Tom Morris] marks himself up with h-card as well as venues he’s checked into ([http://tommorris.org/posts/8408 example])
* [https://www.w3.org/conf/ W3Conf 2013] uses h-card for all the event speakers and notable attendees. The h-cards make particularly good use of implied name, url, and photo properties.
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry and h-as-*
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card markup on their homepage and individual thoughts pages
* Tom Morris uses h-card and [[XFN]] to markup [http://tommorris.org/pages/blogroll his blogroll].
* Aaron Parecki uses h-card to markup both authorship and references to people in his notes permalinks, e.g. [https://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [https://tantek.com/ Tantek Çelik] uses h-card on his home page as well as within [[h-entry]]s on permalink pages to indicate authorship.
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-card on his home page, as well as within h-entries for notes and articles, both to indicate authorship and also when mentioning people within the body of the notes.
* [https://tantek.com/presentations/2012/06/microformats microformats.org at 7 years] presentation with and h-card markup for people and organizations.
* [https://tantek.com/presentations/2012/06/pdf2012-indieweb.html Rise of the Indie Web hCards] (from Personal Democracy Forum 2012 #pdf12 #pdf2012) has [[microformats2]] h-card markup
* WebMaker by Mozilla has [[microformats2]] 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]
* WebFWD by Mozilla has [[microformats2]] h-card markup on [https://webfwd.org/about/experts/ experts] and [https://webfwd.org/about/team/ team] pages
* [https://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://tristanthomas.me Tristan Thomas] uses h-card on his home page
* [http://cold32.com/about-the-author-and-contact.htm Cold32.com] uses h-card (and h-geo) on its about-the-author-and-contact page
* [https://workfrom.co/ Workfrom.co] renders h-cards for venues (e.g. [https://workfrom.co/palio-dessert-and-espresso-house])
* [http://www.pcwdld.com/ PCWDLD.com] renders h-cards for download pages(e.g. [http://www.pcwdld.com/solarwinds-network-topology-mapper-review Download page example])

=== offline ===
* spreadly marks up share permalink pages with minimal h-cards inside h-entry
* App.net rolled out support for h-card and h-entry on all profile pages and permalink pages as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* Sandeep Shetty marks his homepage and posts up with h-card and h-entry ([https://sandeep.io/101 example])

== Validating ==
* '''[https://indiewebify.me/validate-h-card/ indiewebify.me h-card validator]''' parses [[h-card]] markup and makes suggestions for things to add, with code samples
{{h-spec-section-validating}}

== Implementations ==
Software implementations that publish or consume h-card, 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-card by default, and most sites which support receiving webmentions parse h-card for authorship data.)

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]
* [https://github.com/dissolve/inkblot InkBlot]
* [https://aperture.p3k.io/ Aperture] consumes h-card to show authorship information of feed posts ([https://github.com/aaronpk/Aperture/ source code])
* [https://xray.p3k.app/ XRay] consumes h-card and flattens it into a more minimal format ([https://github.com/aaronpk/XRay/ source code])
* [https://withknown.com/ Known] publishes and consumes h-card to show authorship of posts and responses
* [https://brid.gy/ Bridgy] publishes microformats-2 versions of siloed content (including h-card for authorship) for consumption by mf2-consumers
* [https://webmention.io/ webmention.io] consumes h-card for authorship data of incoming webmentions which it accepts on behalf of other sites
* ...
* ...

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

<source lang=html4strict>
<p class="h-card vcard">
<span class="p-name fn">Joe Bloggs</span>,
<span class="p-org org">Awesome Nonprofit</span>
...
</p>
</source>

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

'''fn''', '''org''', and all the other backward compatibility hCard property class names 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-card" is found, don't look for a "vcard" on the same element.

Compat. root class name: <code id="vcard">vcard</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>honorific-prefix</code>
* <code>given-name</code>
* <code>additional-name</code>
* <code>family-name</code>
* <code>honorific-suffix</code>
* <code>nickname</code>
* <code>email</code> - parse as '''u-'''
* <code>logo</code> - parse as '''u-'''
* <code>photo</code> - parse as '''u-'''
* <code>url</code> - parse as '''u-'''
* <code>uid</code> - parse as '''u-'''
* <code>category</code>
* <code>adr</code> - parse as '''<code>p-adr h-adr</code>''' including compat root class <code>adr</code>
* <code>extended-address</code>
* <code>street-address</code>
* <code>locality</code>
* <code>region</code>
* <code>postal-code</code>
* <code>country-name</code>
* <code>label</code>
* <code>geo</code> - parse as '''<code>p-geo h-geo</code>''' including compat root class <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* <code>tel</code>
* <code>note</code>
* <code>bday</code> - parse as '''dt-'''
* <code>key</code> - parse as '''u-'''
* <code>org</code>
* <code>organization-name</code>
* <code>organization-unit</code>
* <code>title</code> - parse as '''p-job-title'''
* <code>role</code>

Reserved: (backward compat properties that parsers {{may}} implement, if they do, they {{must}} implement in this way:
* <code>tz</code>
* <code>rev</code> - parse as '''dt-'''

== Background ==
This work is based on the existing [[hCard]] and [[vcard]] specifications.

== Design Principles ==

(stub, expand)

== Additions ==
We've tried very hard with h-card to stay compatible with the vCard4 vocabulary, and thus additions should be proposed on the vCard4 mailing list.

However, you may still use this wiki to capture additions for h-card here:
* [[h-card-brainstorming]]

== See Also ==
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-adr]]
* [[h-geo]]
* [[hCard]]

[[Category:Draft Specifications]]

h-card

2021-06-22T18:42:55Z

Barnabywalters: /* Examples in the wild */ linked to indieweb wiki examples

<dfn style="font-style:normal;font-weight:bold">h-card</dfn> is a simple, open format for publishing people and organisations on the web. h-card is often used on home pages and individual blog posts. h-card is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-card is the [[microformats2]] update to [[hCard]].

;<span id="status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [https://github.com/microformats/h-card/issues feedback].
;<span id="participate">Participate</span>
:[https://github.com/microformats/h-card/issues Open Issues]
:[[IRC]]
<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 are a couple of minimal examples:

<source lang=html4strict>
<a class="h-card" href="https://tantek.com/">Tantek Çelik</a>,

<span class="h-card">
<a class="p-name p-org u-url" href="https://microformats.org/">microformats.org</a>
</span>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": ["h-card"],
"properties": {
"name": ["Tantek Çelik"],
"url": ["https://tantek.com/"]
}
},
{
"type": ["h-card"],
"properties": {
"name": ["microformats.org"],
"org": ["microformats.org"],
"url": ["https://microformats.org/"]
}
}
]
}
</source>
Note a single element was sufficient for the simple person example with implied name and URL properties, while for an organization, which requires a name and org, it needed explicit markup for the h-card and all properties, though still with only two elements.

Nested h-card example:

<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="https://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="p-org h-card"
href="https://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["https://blog.lizardwrangler.com/"],
"org": [{
"value": "Mozilla Foundation",
"type": ["h-card"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["https://mozilla.org/"]
}
}]
}
}]
}
</source>

Note: the nested h-card has implied 'name' and 'url' properties, just like any other root-class-name-only h-card on an <code><a href></code> would.

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

For minimal examples where at most <code>p-name</code>, <code>u-url</code> and <code>u-photo</code> are required (such as the first given above), only the root class name is needed — see [[microformats-2-implied-properties|implied properties]].

When more than those three minimal properties are needed, the root class name must be placed on an element which encloses all the desired properties, and then the properties themselves marked up using the classnames given below.

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

== Properties ==
h-card properties, inside an element with class '''h-card'''. All properties are optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

<div style="margin-top:-.4em; float:right;"><span>Example h-card with common properties:</span>
<ul style="list-style:none"><li><code><div class="'''h-card'''"></code>
<ul style="list-style:none; margin-top:-.02em">
<li><code><span class="'''p-name'''">Sally Ride</span></code></li>
<li><code><span class="'''p-honorific-prefix'''">Dr.</span></code></li>
<li><code><span class="'''p-given-name'''">Sally</span></code></li>
<li><code><abbr class="'''p-additional-name'''">K.</abbr></code></li>
<li><code><span class="'''p-family-name'''">Ride</span></code></li>
<li><code><span class="'''p-honorific-suffix'''">Ph.D.</span>,</code></li>
<li><code><span class="'''p-nickname'''">sallykride</span> (IRC)</code></li>
<li><code><div class="'''p-org'''">Sally Ride Science</div></code></li>
<li><code><img class="'''u-photo'''" src="<nowiki>http://example.com/sk.jpg</nowiki>"/> </code></li>
<li><code><a class="'''u-url'''" href="<nowiki>http://sally.example.com</nowiki>">w</a>,</code></li>
<li><code><a class="'''u-email'''" href="<nowiki>mailto:sally@example.com</nowiki>">e</a> </code></li>
<li><code><div class="'''p-tel'''">+1.818.555.1212</div></code></li>
<li><code><div class="'''p-street-address'''">123 Main st.</div></code></li>
<li><code><span class="'''p-locality'''">Los Angeles</span>, </code></li>
<li><code><abbr class="'''p-region'''" title="California">CA</abbr>, </code></li>
<li><code><span class="'''p-postal-code'''">91316</span></code></li>
<li><code><div class="'''p-country-name'''">U.S.A</div></code></li>
<li><code><time class="'''dt-bday'''">1951-05-26</time> birthday</code></li>
<li><code><div class="'''p-category'''">physicist</div></code></li>
<li><code><div class="'''p-note'''">First American woman in space.</div></code></li></ul></li>
<li><code></div></code></li></ul>
</div>
Core properties:
* '''<code>p-name</code>''' - The full/formatted name of the person or organization
* '''<code>p-honorific-prefix</code>''' - e.g. Mrs., Mr. or Dr.
* '''<code>p-given-name</code>''' - given (often first) name
* '''<code>p-additional-name</code>''' - other (e.g. middle) name
* '''<code>p-family-name</code>''' - family (often last) name
* '''<code>p-sort-string</code>''' - string to sort by
* '''<code>p-honorific-suffix</code>''' - e.g. Ph.D, Esq.
* '''<code>p-nickname</code>''' - nickname/alias/handle
* '''<code>u-email</code>''' - email address
* '''<code>u-logo</code>''' - a logo representing the person or organization (e.g. a face icon)
* '''<code>u-photo</code>''' - a photo of the person or organization
* '''<code>u-url</code>''' - home page or other URL representing the person or organization
* '''<code>u-uid</code>''' - universally unique identifier, preferably canonical URL
* '''<code>p-category</code>''' - category/tag
* '''<code>p-adr</code>''' - postal address, optionally embed an [[h-adr]] {{main|h-adr}}
* '''<code>p-post-office-box</code>''' - post office box description if any
* '''<code>p-extended-address</code>''' - apartment/suite/room name/number if any
* '''<code>p-street-address</code>''' - street number + name
* '''<code>p-locality</code>''' - city/town/village
* '''<code>p-region</code>''' - state/county/province
* '''<code>p-postal-code</code>''' - postal code, e.g. US ZIP
* '''<code>p-country-name</code>''' - country name
* '''<code>p-label</code>'''
* '''<code>p-geo</code>''' or '''<code>u-geo</code>''', optionally embed an [[h-geo]] {{main|h-geo}}
* '''<code>p-latitude</code>''' - decimal latitude
* '''<code>p-longitude</code>''' - decimal longitude
* '''<code>p-altitude</code>''' - decimal altitude
* '''<code>p-tel</code>''' - telephone number
* '''<code>p-note</code>''' - additional notes
* '''<code>dt-bday</code>''' - birth date
* '''<code>u-key</code>''' - cryptographic public key e.g. SSH or GPG
* '''<code>p-org</code>''' - affiliated organization, optionally embed an [[h-card]]
* '''<code>p-job-title</code>''' - job title, previously 'title' in [[hCard]], disambiguated.
* '''<code>p-role</code>''' - description of role
* '''<code>u-impp</code>''' per RFC4770, new in vCard4 (RFC 6350)
* '''<code>p-sex</code>''' - biological sex, new in vCard4 (RFC 6350)
* '''<code>p-gender-identity</code>''' - gender identity, new in vCard4 (RFC 6350)
* '''<code>dt-anniversary</code>'''

Experimental properties currently in use in the wild but not (yet) part of the official h-card spec.

* '''<code>u-sound</code>''' - sound file containing the proper pronunciation of the name property, per vCard (RFC 6350).
** Used by [https://vanderven.se/martijn/ Martijn van der Ven] with a clip of his given name.
** Needs a GitHub issue to track.

== Status ==
'''h-card''' is a microformats.org draft specification. Public discussion on h-card 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-card/issues may be filed on GitHub].

h-card is ready to use and implemented in the wild. For backwards compatibility you should also mark up top-level h-cards as classic [[hCard]]s.

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

=== p-adr ===
<code>p-adr</code> can optionally embed an [[h-adr]] to cluster associated structured address properties. E.g. adding "p-adr" to the example earlier:

<source lang=html4strict>
<div class="h-card">
<p class="p-name">Joe Bloggs</p>
<p class="p-adr 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>
</div>
</source>

Q: Why would you use "p-adr" to cluster associated structured address properties?

A: Because if you have more than one structured address, clustering which properties go with which address keeps them deterministically together, instead of depending on array indices or other heuristics.

=== p-tel ===
Note: use of 'value' within 'p-tel' should be automatically handled by the support of the [[value-class-pattern]]. And for now, the former [[hCard]] 'type' subproperty of 'tel' is dropped/ignored. If there is demonstrable documented need for additional tel types (e.g. fax), we can introduce new flat properties as needed (e.g. p-tel-fax).

=== dt-bday ===
Using truncated representations of dates for birth date is often good practice as noted in [https://tools.ietf.org/html/rfc6350#section-4.3.1 the vcard spec] eg
* <code>1985-04</code> for April 1985
* <code>1985</code> for the year 1985
* <code>--04-12</code> for April 12th with no specified year

=== Reserved properties ===
The following properties were supported by the legacy hCard format, but were not carried over to h-card due to lack of real-world usage, or other problems. They are not part of h-card and should not be published, consumed, or proposed.

* '''<code>p-organization-name</code>'''
* '''<code>p-organization-unit</code>'''
* '''<code>p-tz</code>''' — timezone offset
** <q>it's going to be a hard one to "get right", as the way timezones work in vcard/ical is very weird, and timezones as a whole are an iffy thing to denote (quite the disconnect between complexity, automated processing ability, actually representing what a user would want to show/display or already does on their homepage, and actually representing something useful to parse and do something with)</q>
** <q>there's certainly no ecosystem of publishers & consumers supporting p-tz in any meaningful interoperable way</q> — [https://chat.indieweb.org/microformats/2021-06-22/1624385751126500 tantek in #microformats]
* '''<code>dt-rev</code>'''

== Examples in the wild ==
See also: [https://indieweb.org/h-card#IndieWeb_Examples h-card Examples on indieweb.org]

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

* ... add uses of h-card you see in the wild here.
* [http://www.securityjobslondon.co.uk Security Jobs London] uses h-card with legacy [[hCard]] fallback markup (to satisfy [https://search.google.com/structured-data/testing-tool Google's Structured Data Testing Tool]) in the footer of each page
* Brett Comnes marks up his posts with h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his homepage and posts with h-card [http://werd.io/view/51d5097fbed7ded0633a5956 example])
* [https://joelpurra.com/ Joel Purra] uses a hidden h-card with legacy [[hCard]] fallback markup (to satisfy [https://search.google.com/structured-data/testing-tool Google's Structured Data Testing Tool]) on the front page
* [http://eschnou.com/ Laurent Eschenauer] marks his homepage profile up using h-card
* [http://tommorris.org/ Tom Morris] marks himself up with h-card as well as venues he’s checked into ([http://tommorris.org/posts/8408 example])
* [https://www.w3.org/conf/ W3Conf 2013] uses h-card for all the event speakers and notable attendees. The h-cards make particularly good use of implied name, url, and photo properties.
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry and h-as-*
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card markup on their homepage and individual thoughts pages
* Tom Morris uses h-card and [[XFN]] to markup [http://tommorris.org/pages/blogroll his blogroll].
* Aaron Parecki uses h-card to markup both authorship and references to people in his notes permalinks, e.g. [https://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [https://tantek.com/ Tantek Çelik] uses h-card on his home page as well as within [[h-entry]]s on permalink pages to indicate authorship.
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-card on his home page, as well as within h-entries for notes and articles, both to indicate authorship and also when mentioning people within the body of the notes.
* [https://tantek.com/presentations/2012/06/microformats microformats.org at 7 years] presentation with and h-card markup for people and organizations.
* [https://tantek.com/presentations/2012/06/pdf2012-indieweb.html Rise of the Indie Web hCards] (from Personal Democracy Forum 2012 #pdf12 #pdf2012) has [[microformats2]] h-card markup
* WebMaker by Mozilla has [[microformats2]] 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]
* WebFWD by Mozilla has [[microformats2]] h-card markup on [https://webfwd.org/about/experts/ experts] and [https://webfwd.org/about/team/ team] pages
* [https://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://tristanthomas.me Tristan Thomas] uses h-card on his home page
* [http://cold32.com/about-the-author-and-contact.htm Cold32.com] uses h-card (and h-geo) on its about-the-author-and-contact page
* [https://workfrom.co/ Workfrom.co] renders h-cards for venues (e.g. [https://workfrom.co/palio-dessert-and-espresso-house])
* [http://www.pcwdld.com/ PCWDLD.com] renders h-cards for download pages(e.g. [http://www.pcwdld.com/solarwinds-network-topology-mapper-review Download page example])

=== offline ===
* spreadly marks up share permalink pages with minimal h-cards inside h-entry
* App.net rolled out support for h-card and h-entry on all profile pages and permalink pages as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* Sandeep Shetty marks his homepage and posts up with h-card and h-entry ([https://sandeep.io/101 example])

== Validating ==
* '''[https://indiewebify.me/validate-h-card/ indiewebify.me h-card validator]''' parses [[h-card]] markup and makes suggestions for things to add, with code samples
{{h-spec-section-validating}}

== Implementations ==
Software implementations that publish or consume h-card, 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-card 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]
* [https://github.com/dissolve/inkblot InkBlot]
* ...
* ...

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

<source lang=html4strict>
<p class="h-card vcard">
<span class="p-name fn">Joe Bloggs</span>,
<span class="p-org org">Awesome Nonprofit</span>
...
</p>
</source>

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

'''fn''', '''org''', and all the other backward compatibility hCard property class names 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-card" is found, don't look for a "vcard" on the same element.

Compat. root class name: <code id="vcard">vcard</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>honorific-prefix</code>
* <code>given-name</code>
* <code>additional-name</code>
* <code>family-name</code>
* <code>honorific-suffix</code>
* <code>nickname</code>
* <code>email</code> - parse as '''u-'''
* <code>logo</code> - parse as '''u-'''
* <code>photo</code> - parse as '''u-'''
* <code>url</code> - parse as '''u-'''
* <code>uid</code> - parse as '''u-'''
* <code>category</code>
* <code>adr</code> - parse as '''<code>p-adr h-adr</code>''' including compat root class <code>adr</code>
* <code>extended-address</code>
* <code>street-address</code>
* <code>locality</code>
* <code>region</code>
* <code>postal-code</code>
* <code>country-name</code>
* <code>label</code>
* <code>geo</code> - parse as '''<code>p-geo h-geo</code>''' including compat root class <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* <code>tel</code>
* <code>note</code>
* <code>bday</code> - parse as '''dt-'''
* <code>key</code> - parse as '''u-'''
* <code>org</code>
* <code>organization-name</code>
* <code>organization-unit</code>
* <code>title</code> - parse as '''p-job-title'''
* <code>role</code>

Reserved: (backward compat properties that parsers {{may}} implement, if they do, they {{must}} implement in this way:
* <code>tz</code>
* <code>rev</code> - parse as '''dt-'''

== Background ==
This work is based on the existing [[hCard]] and [[vcard]] specifications.

== Design Principles ==

(stub, expand)

== Additions ==
We've tried very hard with h-card to stay compatible with the vCard4 vocabulary, and thus additions should be proposed on the vCard4 mailing list.

However, you may still use this wiki to capture additions for h-card here:
* [[h-card-brainstorming]]

== See Also ==
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-adr]]
* [[h-geo]]
* [[hCard]]

[[Category:Draft Specifications]]

h-card

2021-06-22T18:37:25Z

Barnabywalters: /* Examples in the wild */ moved some examples to offline

<dfn style="font-style:normal;font-weight:bold">h-card</dfn> is a simple, open format for publishing people and organisations on the web. h-card is often used on home pages and individual blog posts. h-card is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-card is the [[microformats2]] update to [[hCard]].

;<span id="status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [https://github.com/microformats/h-card/issues feedback].
;<span id="participate">Participate</span>
:[https://github.com/microformats/h-card/issues Open Issues]
:[[IRC]]
<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 are a couple of minimal examples:

<source lang=html4strict>
<a class="h-card" href="https://tantek.com/">Tantek Çelik</a>,

<span class="h-card">
<a class="p-name p-org u-url" href="https://microformats.org/">microformats.org</a>
</span>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": ["h-card"],
"properties": {
"name": ["Tantek Çelik"],
"url": ["https://tantek.com/"]
}
},
{
"type": ["h-card"],
"properties": {
"name": ["microformats.org"],
"org": ["microformats.org"],
"url": ["https://microformats.org/"]
}
}
]
}
</source>
Note a single element was sufficient for the simple person example with implied name and URL properties, while for an organization, which requires a name and org, it needed explicit markup for the h-card and all properties, though still with only two elements.

Nested h-card example:

<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="https://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="p-org h-card"
href="https://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["https://blog.lizardwrangler.com/"],
"org": [{
"value": "Mozilla Foundation",
"type": ["h-card"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["https://mozilla.org/"]
}
}]
}
}]
}
</source>

Note: the nested h-card has implied 'name' and 'url' properties, just like any other root-class-name-only h-card on an <code><a href></code> would.

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

For minimal examples where at most <code>p-name</code>, <code>u-url</code> and <code>u-photo</code> are required (such as the first given above), only the root class name is needed — see [[microformats-2-implied-properties|implied properties]].

When more than those three minimal properties are needed, the root class name must be placed on an element which encloses all the desired properties, and then the properties themselves marked up using the classnames given below.

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

== Properties ==
h-card properties, inside an element with class '''h-card'''. All properties are optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

<div style="margin-top:-.4em; float:right;"><span>Example h-card with common properties:</span>
<ul style="list-style:none"><li><code><div class="'''h-card'''"></code>
<ul style="list-style:none; margin-top:-.02em">
<li><code><span class="'''p-name'''">Sally Ride</span></code></li>
<li><code><span class="'''p-honorific-prefix'''">Dr.</span></code></li>
<li><code><span class="'''p-given-name'''">Sally</span></code></li>
<li><code><abbr class="'''p-additional-name'''">K.</abbr></code></li>
<li><code><span class="'''p-family-name'''">Ride</span></code></li>
<li><code><span class="'''p-honorific-suffix'''">Ph.D.</span>,</code></li>
<li><code><span class="'''p-nickname'''">sallykride</span> (IRC)</code></li>
<li><code><div class="'''p-org'''">Sally Ride Science</div></code></li>
<li><code><img class="'''u-photo'''" src="<nowiki>http://example.com/sk.jpg</nowiki>"/> </code></li>
<li><code><a class="'''u-url'''" href="<nowiki>http://sally.example.com</nowiki>">w</a>,</code></li>
<li><code><a class="'''u-email'''" href="<nowiki>mailto:sally@example.com</nowiki>">e</a> </code></li>
<li><code><div class="'''p-tel'''">+1.818.555.1212</div></code></li>
<li><code><div class="'''p-street-address'''">123 Main st.</div></code></li>
<li><code><span class="'''p-locality'''">Los Angeles</span>, </code></li>
<li><code><abbr class="'''p-region'''" title="California">CA</abbr>, </code></li>
<li><code><span class="'''p-postal-code'''">91316</span></code></li>
<li><code><div class="'''p-country-name'''">U.S.A</div></code></li>
<li><code><time class="'''dt-bday'''">1951-05-26</time> birthday</code></li>
<li><code><div class="'''p-category'''">physicist</div></code></li>
<li><code><div class="'''p-note'''">First American woman in space.</div></code></li></ul></li>
<li><code></div></code></li></ul>
</div>
Core properties:
* '''<code>p-name</code>''' - The full/formatted name of the person or organization
* '''<code>p-honorific-prefix</code>''' - e.g. Mrs., Mr. or Dr.
* '''<code>p-given-name</code>''' - given (often first) name
* '''<code>p-additional-name</code>''' - other (e.g. middle) name
* '''<code>p-family-name</code>''' - family (often last) name
* '''<code>p-sort-string</code>''' - string to sort by
* '''<code>p-honorific-suffix</code>''' - e.g. Ph.D, Esq.
* '''<code>p-nickname</code>''' - nickname/alias/handle
* '''<code>u-email</code>''' - email address
* '''<code>u-logo</code>''' - a logo representing the person or organization (e.g. a face icon)
* '''<code>u-photo</code>''' - a photo of the person or organization
* '''<code>u-url</code>''' - home page or other URL representing the person or organization
* '''<code>u-uid</code>''' - universally unique identifier, preferably canonical URL
* '''<code>p-category</code>''' - category/tag
* '''<code>p-adr</code>''' - postal address, optionally embed an [[h-adr]] {{main|h-adr}}
* '''<code>p-post-office-box</code>''' - post office box description if any
* '''<code>p-extended-address</code>''' - apartment/suite/room name/number if any
* '''<code>p-street-address</code>''' - street number + name
* '''<code>p-locality</code>''' - city/town/village
* '''<code>p-region</code>''' - state/county/province
* '''<code>p-postal-code</code>''' - postal code, e.g. US ZIP
* '''<code>p-country-name</code>''' - country name
* '''<code>p-label</code>'''
* '''<code>p-geo</code>''' or '''<code>u-geo</code>''', optionally embed an [[h-geo]] {{main|h-geo}}
* '''<code>p-latitude</code>''' - decimal latitude
* '''<code>p-longitude</code>''' - decimal longitude
* '''<code>p-altitude</code>''' - decimal altitude
* '''<code>p-tel</code>''' - telephone number
* '''<code>p-note</code>''' - additional notes
* '''<code>dt-bday</code>''' - birth date
* '''<code>u-key</code>''' - cryptographic public key e.g. SSH or GPG
* '''<code>p-org</code>''' - affiliated organization, optionally embed an [[h-card]]
* '''<code>p-job-title</code>''' - job title, previously 'title' in [[hCard]], disambiguated.
* '''<code>p-role</code>''' - description of role
* '''<code>u-impp</code>''' per RFC4770, new in vCard4 (RFC 6350)
* '''<code>p-sex</code>''' - biological sex, new in vCard4 (RFC 6350)
* '''<code>p-gender-identity</code>''' - gender identity, new in vCard4 (RFC 6350)
* '''<code>dt-anniversary</code>'''

Experimental properties currently in use in the wild but not (yet) part of the official h-card spec.

* '''<code>u-sound</code>''' - sound file containing the proper pronunciation of the name property, per vCard (RFC 6350).
** Used by [https://vanderven.se/martijn/ Martijn van der Ven] with a clip of his given name.
** Needs a GitHub issue to track.

== Status ==
'''h-card''' is a microformats.org draft specification. Public discussion on h-card 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-card/issues may be filed on GitHub].

h-card is ready to use and implemented in the wild. For backwards compatibility you should also mark up top-level h-cards as classic [[hCard]]s.

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

=== p-adr ===
<code>p-adr</code> can optionally embed an [[h-adr]] to cluster associated structured address properties. E.g. adding "p-adr" to the example earlier:

<source lang=html4strict>
<div class="h-card">
<p class="p-name">Joe Bloggs</p>
<p class="p-adr 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>
</div>
</source>

Q: Why would you use "p-adr" to cluster associated structured address properties?

A: Because if you have more than one structured address, clustering which properties go with which address keeps them deterministically together, instead of depending on array indices or other heuristics.

=== p-tel ===
Note: use of 'value' within 'p-tel' should be automatically handled by the support of the [[value-class-pattern]]. And for now, the former [[hCard]] 'type' subproperty of 'tel' is dropped/ignored. If there is demonstrable documented need for additional tel types (e.g. fax), we can introduce new flat properties as needed (e.g. p-tel-fax).

=== dt-bday ===
Using truncated representations of dates for birth date is often good practice as noted in [https://tools.ietf.org/html/rfc6350#section-4.3.1 the vcard spec] eg
* <code>1985-04</code> for April 1985
* <code>1985</code> for the year 1985
* <code>--04-12</code> for April 12th with no specified year

=== Reserved properties ===
The following properties were supported by the legacy hCard format, but were not carried over to h-card due to lack of real-world usage, or other problems. They are not part of h-card and should not be published, consumed, or proposed.

* '''<code>p-organization-name</code>'''
* '''<code>p-organization-unit</code>'''
* '''<code>p-tz</code>''' — timezone offset
** <q>it's going to be a hard one to "get right", as the way timezones work in vcard/ical is very weird, and timezones as a whole are an iffy thing to denote (quite the disconnect between complexity, automated processing ability, actually representing what a user would want to show/display or already does on their homepage, and actually representing something useful to parse and do something with)</q>
** <q>there's certainly no ecosystem of publishers & consumers supporting p-tz in any meaningful interoperable way</q> — [https://chat.indieweb.org/microformats/2021-06-22/1624385751126500 tantek in #microformats]
* '''<code>dt-rev</code>'''

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

* ... add uses of h-card you see in the wild here.
* [http://www.securityjobslondon.co.uk Security Jobs London] uses h-card with legacy [[hCard]] fallback markup (to satisfy [https://search.google.com/structured-data/testing-tool Google's Structured Data Testing Tool]) in the footer of each page
* Brett Comnes marks up his posts with h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his homepage and posts with h-card [http://werd.io/view/51d5097fbed7ded0633a5956 example])
* [https://joelpurra.com/ Joel Purra] uses a hidden h-card with legacy [[hCard]] fallback markup (to satisfy [https://search.google.com/structured-data/testing-tool Google's Structured Data Testing Tool]) on the front page
* [http://eschnou.com/ Laurent Eschenauer] marks his homepage profile up using h-card
* [http://tommorris.org/ Tom Morris] marks himself up with h-card as well as venues he’s checked into ([http://tommorris.org/posts/8408 example])
* [https://www.w3.org/conf/ W3Conf 2013] uses h-card for all the event speakers and notable attendees. The h-cards make particularly good use of implied name, url, and photo properties.
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry and h-as-*
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card markup on their homepage and individual thoughts pages
* Tom Morris uses h-card and [[XFN]] to markup [http://tommorris.org/pages/blogroll his blogroll].
* Aaron Parecki uses h-card to markup both authorship and references to people in his notes permalinks, e.g. [https://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [https://tantek.com/ Tantek Çelik] uses h-card on his home page as well as within [[h-entry]]s on permalink pages to indicate authorship.
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-card on his home page, as well as within h-entries for notes and articles, both to indicate authorship and also when mentioning people within the body of the notes.
* [https://tantek.com/presentations/2012/06/microformats microformats.org at 7 years] presentation with and h-card markup for people and organizations.
* [https://tantek.com/presentations/2012/06/pdf2012-indieweb.html Rise of the Indie Web hCards] (from Personal Democracy Forum 2012 #pdf12 #pdf2012) has [[microformats2]] h-card markup
* WebMaker by Mozilla has [[microformats2]] 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]
* WebFWD by Mozilla has [[microformats2]] h-card markup on [https://webfwd.org/about/experts/ experts] and [https://webfwd.org/about/team/ team] pages
* [https://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://tristanthomas.me Tristan Thomas] uses h-card on his home page
* [http://cold32.com/about-the-author-and-contact.htm Cold32.com] uses h-card (and h-geo) on its about-the-author-and-contact page
* [https://workfrom.co/ Workfrom.co] renders h-cards for venues (e.g. [https://workfrom.co/palio-dessert-and-espresso-house])
* [http://www.pcwdld.com/ PCWDLD.com] renders h-cards for download pages(e.g. [http://www.pcwdld.com/solarwinds-network-topology-mapper-review Download page example])

=== offline ===
* spreadly marks up share permalink pages with minimal h-cards inside h-entry
* App.net rolled out support for h-card and h-entry on all profile pages and permalink pages as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* Sandeep Shetty marks his homepage and posts up with h-card and h-entry ([https://sandeep.io/101 example])

== Validating ==
* '''[https://indiewebify.me/validate-h-card/ indiewebify.me h-card validator]''' parses [[h-card]] markup and makes suggestions for things to add, with code samples
{{h-spec-section-validating}}

== Implementations ==
Software implementations that publish or consume h-card, 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-card 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]
* [https://github.com/dissolve/inkblot InkBlot]
* ...
* ...

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

<source lang=html4strict>
<p class="h-card vcard">
<span class="p-name fn">Joe Bloggs</span>,
<span class="p-org org">Awesome Nonprofit</span>
...
</p>
</source>

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

'''fn''', '''org''', and all the other backward compatibility hCard property class names 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-card" is found, don't look for a "vcard" on the same element.

Compat. root class name: <code id="vcard">vcard</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>honorific-prefix</code>
* <code>given-name</code>
* <code>additional-name</code>
* <code>family-name</code>
* <code>honorific-suffix</code>
* <code>nickname</code>
* <code>email</code> - parse as '''u-'''
* <code>logo</code> - parse as '''u-'''
* <code>photo</code> - parse as '''u-'''
* <code>url</code> - parse as '''u-'''
* <code>uid</code> - parse as '''u-'''
* <code>category</code>
* <code>adr</code> - parse as '''<code>p-adr h-adr</code>''' including compat root class <code>adr</code>
* <code>extended-address</code>
* <code>street-address</code>
* <code>locality</code>
* <code>region</code>
* <code>postal-code</code>
* <code>country-name</code>
* <code>label</code>
* <code>geo</code> - parse as '''<code>p-geo h-geo</code>''' including compat root class <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* <code>tel</code>
* <code>note</code>
* <code>bday</code> - parse as '''dt-'''
* <code>key</code> - parse as '''u-'''
* <code>org</code>
* <code>organization-name</code>
* <code>organization-unit</code>
* <code>title</code> - parse as '''p-job-title'''
* <code>role</code>

Reserved: (backward compat properties that parsers {{may}} implement, if they do, they {{must}} implement in this way:
* <code>tz</code>
* <code>rev</code> - parse as '''dt-'''

== Background ==
This work is based on the existing [[hCard]] and [[vcard]] specifications.

== Design Principles ==

(stub, expand)

== Additions ==
We've tried very hard with h-card to stay compatible with the vCard4 vocabulary, and thus additions should be proposed on the vCard4 mailing list.

However, you may still use this wiki to capture additions for h-card here:
* [[h-card-brainstorming]]

== See Also ==
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-adr]]
* [[h-geo]]
* [[hCard]]

[[Category:Draft Specifications]]

h-card

2021-06-22T18:33:45Z

Barnabywalters: /* Reserved properties */ removed example, clarified status of reserved properties

<dfn style="font-style:normal;font-weight:bold">h-card</dfn> is a simple, open format for publishing people and organisations on the web. h-card is often used on home pages and individual blog posts. h-card is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-card is the [[microformats2]] update to [[hCard]].

;<span id="status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [https://github.com/microformats/h-card/issues feedback].
;<span id="participate">Participate</span>
:[https://github.com/microformats/h-card/issues Open Issues]
:[[IRC]]
<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 are a couple of minimal examples:

<source lang=html4strict>
<a class="h-card" href="https://tantek.com/">Tantek Çelik</a>,

<span class="h-card">
<a class="p-name p-org u-url" href="https://microformats.org/">microformats.org</a>
</span>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": ["h-card"],
"properties": {
"name": ["Tantek Çelik"],
"url": ["https://tantek.com/"]
}
},
{
"type": ["h-card"],
"properties": {
"name": ["microformats.org"],
"org": ["microformats.org"],
"url": ["https://microformats.org/"]
}
}
]
}
</source>
Note a single element was sufficient for the simple person example with implied name and URL properties, while for an organization, which requires a name and org, it needed explicit markup for the h-card and all properties, though still with only two elements.

Nested h-card example:

<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="https://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="p-org h-card"
href="https://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["https://blog.lizardwrangler.com/"],
"org": [{
"value": "Mozilla Foundation",
"type": ["h-card"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["https://mozilla.org/"]
}
}]
}
}]
}
</source>

Note: the nested h-card has implied 'name' and 'url' properties, just like any other root-class-name-only h-card on an <code><a href></code> would.

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

For minimal examples where at most <code>p-name</code>, <code>u-url</code> and <code>u-photo</code> are required (such as the first given above), only the root class name is needed — see [[microformats-2-implied-properties|implied properties]].

When more than those three minimal properties are needed, the root class name must be placed on an element which encloses all the desired properties, and then the properties themselves marked up using the classnames given below.

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

== Properties ==
h-card properties, inside an element with class '''h-card'''. All properties are optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

<div style="margin-top:-.4em; float:right;"><span>Example h-card with common properties:</span>
<ul style="list-style:none"><li><code><div class="'''h-card'''"></code>
<ul style="list-style:none; margin-top:-.02em">
<li><code><span class="'''p-name'''">Sally Ride</span></code></li>
<li><code><span class="'''p-honorific-prefix'''">Dr.</span></code></li>
<li><code><span class="'''p-given-name'''">Sally</span></code></li>
<li><code><abbr class="'''p-additional-name'''">K.</abbr></code></li>
<li><code><span class="'''p-family-name'''">Ride</span></code></li>
<li><code><span class="'''p-honorific-suffix'''">Ph.D.</span>,</code></li>
<li><code><span class="'''p-nickname'''">sallykride</span> (IRC)</code></li>
<li><code><div class="'''p-org'''">Sally Ride Science</div></code></li>
<li><code><img class="'''u-photo'''" src="<nowiki>http://example.com/sk.jpg</nowiki>"/> </code></li>
<li><code><a class="'''u-url'''" href="<nowiki>http://sally.example.com</nowiki>">w</a>,</code></li>
<li><code><a class="'''u-email'''" href="<nowiki>mailto:sally@example.com</nowiki>">e</a> </code></li>
<li><code><div class="'''p-tel'''">+1.818.555.1212</div></code></li>
<li><code><div class="'''p-street-address'''">123 Main st.</div></code></li>
<li><code><span class="'''p-locality'''">Los Angeles</span>, </code></li>
<li><code><abbr class="'''p-region'''" title="California">CA</abbr>, </code></li>
<li><code><span class="'''p-postal-code'''">91316</span></code></li>
<li><code><div class="'''p-country-name'''">U.S.A</div></code></li>
<li><code><time class="'''dt-bday'''">1951-05-26</time> birthday</code></li>
<li><code><div class="'''p-category'''">physicist</div></code></li>
<li><code><div class="'''p-note'''">First American woman in space.</div></code></li></ul></li>
<li><code></div></code></li></ul>
</div>
Core properties:
* '''<code>p-name</code>''' - The full/formatted name of the person or organization
* '''<code>p-honorific-prefix</code>''' - e.g. Mrs., Mr. or Dr.
* '''<code>p-given-name</code>''' - given (often first) name
* '''<code>p-additional-name</code>''' - other (e.g. middle) name
* '''<code>p-family-name</code>''' - family (often last) name
* '''<code>p-sort-string</code>''' - string to sort by
* '''<code>p-honorific-suffix</code>''' - e.g. Ph.D, Esq.
* '''<code>p-nickname</code>''' - nickname/alias/handle
* '''<code>u-email</code>''' - email address
* '''<code>u-logo</code>''' - a logo representing the person or organization (e.g. a face icon)
* '''<code>u-photo</code>''' - a photo of the person or organization
* '''<code>u-url</code>''' - home page or other URL representing the person or organization
* '''<code>u-uid</code>''' - universally unique identifier, preferably canonical URL
* '''<code>p-category</code>''' - category/tag
* '''<code>p-adr</code>''' - postal address, optionally embed an [[h-adr]] {{main|h-adr}}
* '''<code>p-post-office-box</code>''' - post office box description if any
* '''<code>p-extended-address</code>''' - apartment/suite/room name/number if any
* '''<code>p-street-address</code>''' - street number + name
* '''<code>p-locality</code>''' - city/town/village
* '''<code>p-region</code>''' - state/county/province
* '''<code>p-postal-code</code>''' - postal code, e.g. US ZIP
* '''<code>p-country-name</code>''' - country name
* '''<code>p-label</code>'''
* '''<code>p-geo</code>''' or '''<code>u-geo</code>''', optionally embed an [[h-geo]] {{main|h-geo}}
* '''<code>p-latitude</code>''' - decimal latitude
* '''<code>p-longitude</code>''' - decimal longitude
* '''<code>p-altitude</code>''' - decimal altitude
* '''<code>p-tel</code>''' - telephone number
* '''<code>p-note</code>''' - additional notes
* '''<code>dt-bday</code>''' - birth date
* '''<code>u-key</code>''' - cryptographic public key e.g. SSH or GPG
* '''<code>p-org</code>''' - affiliated organization, optionally embed an [[h-card]]
* '''<code>p-job-title</code>''' - job title, previously 'title' in [[hCard]], disambiguated.
* '''<code>p-role</code>''' - description of role
* '''<code>u-impp</code>''' per RFC4770, new in vCard4 (RFC 6350)
* '''<code>p-sex</code>''' - biological sex, new in vCard4 (RFC 6350)
* '''<code>p-gender-identity</code>''' - gender identity, new in vCard4 (RFC 6350)
* '''<code>dt-anniversary</code>'''

Experimental properties currently in use in the wild but not (yet) part of the official h-card spec.

* '''<code>u-sound</code>''' - sound file containing the proper pronunciation of the name property, per vCard (RFC 6350).
** Used by [https://vanderven.se/martijn/ Martijn van der Ven] with a clip of his given name.
** Needs a GitHub issue to track.

== Status ==
'''h-card''' is a microformats.org draft specification. Public discussion on h-card 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-card/issues may be filed on GitHub].

h-card is ready to use and implemented in the wild. For backwards compatibility you should also mark up top-level h-cards as classic [[hCard]]s.

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

=== p-adr ===
<code>p-adr</code> can optionally embed an [[h-adr]] to cluster associated structured address properties. E.g. adding "p-adr" to the example earlier:

<source lang=html4strict>
<div class="h-card">
<p class="p-name">Joe Bloggs</p>
<p class="p-adr 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>
</div>
</source>

Q: Why would you use "p-adr" to cluster associated structured address properties?

A: Because if you have more than one structured address, clustering which properties go with which address keeps them deterministically together, instead of depending on array indices or other heuristics.

=== p-tel ===
Note: use of 'value' within 'p-tel' should be automatically handled by the support of the [[value-class-pattern]]. And for now, the former [[hCard]] 'type' subproperty of 'tel' is dropped/ignored. If there is demonstrable documented need for additional tel types (e.g. fax), we can introduce new flat properties as needed (e.g. p-tel-fax).

=== dt-bday ===
Using truncated representations of dates for birth date is often good practice as noted in [https://tools.ietf.org/html/rfc6350#section-4.3.1 the vcard spec] eg
* <code>1985-04</code> for April 1985
* <code>1985</code> for the year 1985
* <code>--04-12</code> for April 12th with no specified year

=== Reserved properties ===
The following properties were supported by the legacy hCard format, but were not carried over to h-card due to lack of real-world usage, or other problems. They are not part of h-card and should not be published, consumed, or proposed.

* '''<code>p-organization-name</code>'''
* '''<code>p-organization-unit</code>'''
* '''<code>p-tz</code>''' — timezone offset
** <q>it's going to be a hard one to "get right", as the way timezones work in vcard/ical is very weird, and timezones as a whole are an iffy thing to denote (quite the disconnect between complexity, automated processing ability, actually representing what a user would want to show/display or already does on their homepage, and actually representing something useful to parse and do something with)</q>
** <q>there's certainly no ecosystem of publishers & consumers supporting p-tz in any meaningful interoperable way</q> — [https://chat.indieweb.org/microformats/2021-06-22/1624385751126500 tantek in #microformats]
* '''<code>dt-rev</code>'''

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

* ... add uses of h-card you see in the wild here.
* [http://www.securityjobslondon.co.uk Security Jobs London] uses h-card with legacy [[hCard]] fallback markup (to satisfy [https://search.google.com/structured-data/testing-tool Google's Structured Data Testing Tool]) in the footer of each page
* App.net rolled out support for h-card and h-entry on all profile pages and permalink pages as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* Brett Comnes marks up his posts with h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his homepage and posts with h-card [http://werd.io/view/51d5097fbed7ded0633a5956 example])
* [https://joelpurra.com/ Joel Purra] uses a hidden h-card with legacy [[hCard]] fallback markup (to satisfy [https://search.google.com/structured-data/testing-tool Google's Structured Data Testing Tool]) on the front page
* Sandeep Shetty marks his homepage and posts up with h-card and h-entry ([sandeep.io/101 example])
* [http://eschnou.com/ Laurent Eschenauer] marks his homepage profile up using h-card
* [http://tommorris.org/ Tom Morris] marks himself up with h-card as well as venues he’s checked into ([http://tommorris.org/posts/8408 example])
* [https://www.w3.org/conf/ W3Conf 2013] uses h-card for all the event speakers and notable attendees. The h-cards make particularly good use of implied name, url, and photo properties.
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry and h-as-*
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card markup on their homepage and individual thoughts pages
* Tom Morris uses h-card and [[XFN]] to markup [http://tommorris.org/pages/blogroll his blogroll].
* Aaron Parecki uses h-card to markup both authorship and references to people in his notes permalinks, e.g. [https://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [https://tantek.com/ Tantek Çelik] uses h-card on his home page as well as within [[h-entry]]s on permalink pages to indicate authorship.
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-card on his home page, as well as within h-entries for notes and articles, both to indicate authorship and also when mentioning people within the body of the notes.
* [https://tantek.com/presentations/2012/06/microformats microformats.org at 7 years] presentation with and h-card markup for people and organizations.
* [https://tantek.com/presentations/2012/06/pdf2012-indieweb.html Rise of the Indie Web hCards] (from Personal Democracy Forum 2012 #pdf12 #pdf2012) has [[microformats2]] h-card markup
* WebMaker by Mozilla has [[microformats2]] 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]
* WebFWD by Mozilla has [[microformats2]] h-card markup on [https://webfwd.org/about/experts/ experts] and [https://webfwd.org/about/team/ team] pages
* [https://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://tristanthomas.me Tristan Thomas] uses h-card on his home page
* [http://cold32.com/about-the-author-and-contact.htm Cold32.com] uses h-card (and h-geo) on its about-the-author-and-contact page
* [https://workfrom.co/ Workfrom.co] renders h-cards for venues (e.g. [https://workfrom.co/palio-dessert-and-espresso-house])
* [http://www.pcwdld.com/ PCWDLD.com] renders h-cards for download pages(e.g. [http://www.pcwdld.com/solarwinds-network-topology-mapper-review Download page example])

=== offline ===
* spreadly marks up share permalink pages with minimal h-cards inside h-entry

== Validating ==
* '''[https://indiewebify.me/validate-h-card/ indiewebify.me h-card validator]''' parses [[h-card]] markup and makes suggestions for things to add, with code samples
{{h-spec-section-validating}}

== Implementations ==
Software implementations that publish or consume h-card, 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-card 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]
* [https://github.com/dissolve/inkblot InkBlot]
* ...
* ...

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

<source lang=html4strict>
<p class="h-card vcard">
<span class="p-name fn">Joe Bloggs</span>,
<span class="p-org org">Awesome Nonprofit</span>
...
</p>
</source>

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

'''fn''', '''org''', and all the other backward compatibility hCard property class names 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-card" is found, don't look for a "vcard" on the same element.

Compat. root class name: <code id="vcard">vcard</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>honorific-prefix</code>
* <code>given-name</code>
* <code>additional-name</code>
* <code>family-name</code>
* <code>honorific-suffix</code>
* <code>nickname</code>
* <code>email</code> - parse as '''u-'''
* <code>logo</code> - parse as '''u-'''
* <code>photo</code> - parse as '''u-'''
* <code>url</code> - parse as '''u-'''
* <code>uid</code> - parse as '''u-'''
* <code>category</code>
* <code>adr</code> - parse as '''<code>p-adr h-adr</code>''' including compat root class <code>adr</code>
* <code>extended-address</code>
* <code>street-address</code>
* <code>locality</code>
* <code>region</code>
* <code>postal-code</code>
* <code>country-name</code>
* <code>label</code>
* <code>geo</code> - parse as '''<code>p-geo h-geo</code>''' including compat root class <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* <code>tel</code>
* <code>note</code>
* <code>bday</code> - parse as '''dt-'''
* <code>key</code> - parse as '''u-'''
* <code>org</code>
* <code>organization-name</code>
* <code>organization-unit</code>
* <code>title</code> - parse as '''p-job-title'''
* <code>role</code>

Reserved: (backward compat properties that parsers {{may}} implement, if they do, they {{must}} implement in this way:
* <code>tz</code>
* <code>rev</code> - parse as '''dt-'''

== Background ==
This work is based on the existing [[hCard]] and [[vcard]] specifications.

== Design Principles ==

(stub, expand)

== Additions ==
We've tried very hard with h-card to stay compatible with the vCard4 vocabulary, and thus additions should be proposed on the vCard4 mailing list.

However, you may still use this wiki to capture additions for h-card here:
* [[h-card-brainstorming]]

== See Also ==
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-adr]]
* [[h-geo]]
* [[hCard]]

[[Category:Draft Specifications]]

representative-h-card-parsing

2021-06-22T12:45:49Z

Barnabywalters: /* Implementations */ added rockorager/representative-h-card

Assuming you already have access to a [[parsers#microformats2_parsers|microformats2 parser]], the algorithm defined here allows you to determine the representative [[h-card]] for a given page.

This algorithm is the microformats2 update to [[representative-hcard-parsing]].

== Algorithm ==

After [[parsing]] the page:

* If the page contains an h-card with '''uid''' and '''url''' properties both matching the page URL, the first such h-card is the representative h-card
* If no representative h-card was found, if the page contains an h-card with a '''url''' property value which also has a <code>rel=me</code> relation (i.e. matches a URL in parse_results.rels.me), the first such h-card is the representative h-card
* If no representative h-card was found, if the page contains '''one single''' h-card, and the h-card has a '''url''' property matching the page URL, that h-card is the representative h-card
* If no representative h-card was found, the page has no representative h-card

=== Matching URLs ===
URLs are to be matched as per the parsing algorithm defined in https://url.spec.whatwg.org:

* Parse the URLs
* If every component matches, the URLs match

== Implementations ==
Open source implementations of the representative h-card algorithm.

* '''PHP''' [https://github.com/barnabywalters/php-mf-cleaner barnabywalters/mf-cleaner] package implements representative h-card parsing in [https://github.com/barnabywalters/php-mf-cleaner/blob/master/src/BarnabyWalters/Mf2/Functions.php#L211 getRepresentativeHCard()] function
** Example usage: <code>$hcard = BarnabyWalters\Mf2\getRepresentativeHCard($mfs, $url);</code>
* '''PHP''' [https://github.com/indieweb/representative-h-card-php indieweb/representative-h-card-php]
* '''node.js''' [https://github.com/rockorager/representative-h-card rockorager/representative-h-card]
* Add yours here!
* …

== Back compat ==
All backcompat for representative h-card parsing should already be handled by the [[h-card#Backward_Compatibility|h-card backcompat]] rules, implemented by a conforming parser.

== See Also ==
* [[h-card]]
* [[representative-hcard]] — original hCard work, most of which applies equally to the updated algorithm

FAQ

2021-05-25T12:40:14Z

Barnabywalters:

#REDIRECT [[faq]]

Template:warning

2021-04-28T17:31:02Z

Barnabywalters: Changed styles for readability, consistency with Template:inactive

<div style="padding: 1em; border: 5px solid #f78c00; background: #fcdcb3; font-size: 1.5em; margin-bottom: 1em;">⚠️ <strong>Warning:</strong> {{{1}}}</div>

Template:inactive

2021-04-28T17:23:32Z

Barnabywalters:

<div style="padding: 1em; border: 5px solid #af0011; background: #fcd2cf; font-size: 1.5em; margin-bottom: 1em;"><strong>Inactive:</strong> This page is outdated and no longer represents the current approach to developing microformats. See also: [[process]]</div>

species-brainstorming

2021-04-28T17:17:00Z

Barnabywalters: Added inactive template per discussion in IRC

{{inactive}}

=Species Brainstorming=

:'''Note: the original name of the proposed microformat, "species", is likely to change, probably to "biota" or "taxon". The former has been retained here, to avoid having to make many repetitive and perhaps redundant edits'''

:'''{{UpdateMarker}} The [http://www.kaply.com/weblog/2007/02/16/operator-07a-is-available/ Operator] extension now detects ''Species''. [http://www.westmidlandbirdclub.com/records/lists-2004uf.htm A test page is available]. Work on both continues!'''

==Andy Mabbett==
===Proposal===

There should, I believe, be a "'''[[species]]'''" microformat for the markup of plant and animal names, to include their scientific names. Consider:

:<pre><nowiki><abbr class="species" title="Anas platyrhynchos">Mallard</abbr></nowiki></pre>
or
:<pre><nowiki><span class="species">Anas platyrhynchos</span></nowiki></pre>

The microformat would allow user agents to be configured to perform look-ups on on-line databases of species, according to user preferences. Specification of the taxonomic class would help user agents to know which such databases were applicable (i.e., use database A for plants, but database B for mammals and database C for insects.)

It would also allow for more specific searching (do I mean "crow" or do I mean "Corvus corone"?).

The specification should encourage, but not mandate, the correct capitalisation of scientific names, so "''Anas platyrhynchos'''" not "''anas platyrhynchos''" nor (except historically) "''Anas Platyrhynchos''". A reminder that such names should be styled with italics will also be included.

===Straw man proposal===

See : [[species-strawman-01]]

==Bill Hull==
[http://www.mangoverde.com/ My website] has 17000+ photos of 4700+ bird species. There are also a handful of butterflies (organized very poorly as I am unaware of any published butterfly world taxonomies) and shortly will have a number of dragon/damselflies. The site is made up of static pages but is built from a database so it is easy for me to add it new HTML tags to the pages. If you are interested in some prototyping at some point I can probably build stuff into the pages. - Bill Hull

==Roger Hyam==
===Taxonomic Databases Working Group===

[http://www.tdwg.org/index.html TDWG] is the organisation for standardisation in exchange of biodiversity data. The organisation has now (November 2007) undergone some re-organization. It has a new collaborative development environment, standards process, standards architecture and it has formed alliances with major organizations in the domains of geospatial and ecological data.

Central to the TDWG standards architecture are the [http://wiki.tdwg.org/twiki/bin/view/TAG/LsidVocs LSID vocabularies]. The role of these vocabularies is to define URIs for the nuts-and-bolts concepts that occur in the biodiversity informatics domain. See [http://wiki.tdwg.org/twiki/bin/view/TAG/WhatIsTheOntology a description of what the TDWG ontology is] for details. Although the vocabularies are defined in OWL the intention is for their URIs to be used as namespaces across different XML and non-XML based technologies. They can act as a central mapping point for those hard pressed developers who want to combine data presented to them in many formats.

The species microformats that are proposed here are a good thing. The only danger is that they re-define any of the central terms defined in the TDWG vocabularies. If they do that then they are creating another language instead of extending HTML to embrace existing semantics - which I don't think is their intent. It would be nice to have the data in web pages in a form that can be combined with the hundreds of millions of records marked up with the TDWG URIs.

If there is enough belief in the need for a Species Microformat why not propose a TDWG Applicability Statement and take it through a peer review process. The [http://www.tdwg.org/about-tdwg/process/ TDWG process] is quite simple and free (unless you count blood, sweat and tears). You would need to form a Task Group with a charter saying what you intended to do. As convener of the TAG Interest Group I would willingly host the Task Group. You could then propose a standard and have it reviewed by a range of biologists and IT people before it becomes ratified and recommended for adoption. RogerHyam 2007-11-5

==Malcolm Storey==
(extracted from e-mails to Andy Mabbett, by kind permission)

* "Hopefully I'll have more time for things like this in the New Year, but expect it all be done and dusted by then!!" - Malcolm Storey, [http://www.bioimages.org.uk/ BioImages]

===ICZN, ICBN et al===
You don't cover the full set of levels of taxonomic hierarchy defined by the relevant body ICZN or ICBN (plus the others - one each for garden plant varieties, bacteria, viruses. Don't know about mycoplasmas, diseases, BSE factors etc.

ICBN Ranks listed [http://www.bgbm.org/iapt/nomenclature/code/SaintLouis/0007Ch1Art003.htm], [http://www.bgbm.org/iapt/nomenclature/code/SaintLouis/0008Ch1Art004.htm]

AIUI ICBN only goes down to species.

ICZN isn't so easy: [http://www.nhm.ac.uk/hosted_sites/iczn/]

:1.2.2. The Code regulates the names of taxa in the family group, genus group, and species group. Articles 1-4, 7-10, 11.1-11.3, 14, 27, 28 and 32.5.2.5 also regulate names of taxa at ranks above the family group. (But none of the above articles list the taxonomic ranks.)

ICZN Only goes down to subspecies (art 1.3.4)

Note also:

:1.4. Independence. Zoological nomenclature is independent of other systems of nomenclature in that the name of an animal taxon is not to be rejected merely because it is identical with the name of a taxon that is not animal (see Article 1.1.1)

(eg Trichia, Oenanthe, Melanotus)

Myxomycetes are the exception - they're in kingdom protozoa which falls under ICZN but they fall under the ICBN name space. (Hence "Trichia").

===DNA===
You may want to consider refs to DNA sequences. They're not part of taxonomy, but they can be considered the bottom rung of the taxonomic hierarchy and they will be of increasing significance.

===Typography===
what about ''Adalia 2-punctata'', and ''Adalia bipunctata'' (not to mention those with hyphens [or apostrophes] which may get left out. And what about accented characters)?

:''Adalia 2-punctata'' is an abbreviation of ''Adalia bipunctata'', so:

:<pre><nowiki><abbr class="binominal" title="Adalia bipunctata">Adalia 2-punctata</abbr></nowiki></pre>
[[User:AndyMabbett|AndyMabbett]] 09:55, 21 Oct 2006 (PDT)

===Gaps===
The hierarchy is not always fully populated. Not every species belongs to a class. Maybe this was where fungi are different. In Paul Kirk's databases (which are the official ones used to drive the checklists and NBN) he has fixed fields for the higher level taxa which means that only certain ranks can be used. The blanks he fills in (mostly!!) with "insertae sedis" (think it's Latin for "unknown seat"). In my database I use a self-join which gives much more flexibility. Anyway there are lots of "insertae sedis" in Paul's database!

===Homonyms===
''Apion carduorum'' sensu Morris 1990 is ''Apion gibbirostre'' (Gyllenhal, 1813). ''Apion carduorum'' Kirby, 1808 is a different species.

:You'd mark the former up as something like
:<pre><nowiki><abbr class="binominal" title="Apion gibbirostre">''Apion carduorum'' sensu Morris 1990</abbr></nowiki></pre>

:[[User:AndyMabbett|AndyMabbett]] 12:21, 5 Oct 2006 (PDT)

===Citations for authorites===
If people are citing the authority in full they would include the literature reference, not just the date e.g.
:''Cuphophyllus niveus'' (Scop.) Bon, ''Doc. Mycol.'' 14(56): 11 (1985)[1984]

::Perhaps we should allow for the inclusion of an [[hcitation|hCitation]]? [[User:AndyMabbett|Andy Mabbett]] 15:08, 28 Feb 2007 (PST)

==Hyppo==
===Nomenclatural challenge===
You asked for comments. One challenge I see is the difference in Nomenclature for Animalia and Plantae (coming from the old 2 kingdom system). For Plantae the International Code of Botanical Nomenclature[http://www.bgbm.org/iapt/nomenclature/code/SaintLouis/0000St.Luistitle.htm] is used and for Animalia the code from [http://www.iczn.org/ http://www.iczn.org/]. Animalia code is not officially accepted but ICZN tries to be authoritive starting from 2008.

The two different nomenclatural systems differ in a few areas, and they affect markup.

*Subgenus (Plantae): ''Dendroceros'' subg. ''Apoceros''
*Subgenus (Animalia): ''Sula (Morus)''

*Subspecies (Plantae): ''Begonia grandis'' ssp. ''evansiana''
*Subspecies (Animalia): ''Gorilla beringei graueri''
:--[[User:Hyppo|Hyppo]] 14:23, 9 Oct 2006 (PDT)

:I would mark those up as:

:<pre><nowiki><span class=genus">Dendroceros</span> subg. <span class="subgenus">Apoceros</span></nowiki></pre>

:<pre><nowiki><span class=genus">Sula</span> <span class="subgenus">Morus</span></nowiki></pre>

:<pre><nowiki><span class="binominal">Begonia grandis</span> ssp. <span class="subspecies">evansiana''</span></nowiki></pre>

:<pre><nowiki><span class="binominal">Gorilla beringei</span> <span class="subspecies">graueri</span></nowiki></pre>

:With wrapping class="biota" and possibly kingdom, attributes.

:[[User:AndyMabbett|AndyMabbett]] 11:37, 10 Oct 2006 (PDT)

==Cyndy Parr==

The ideas expressed here are promising. Below are my comments on all the preceding -- as I have time I'll organize, elaborate, and try to move parts into the right discussion threads above.

In the [http://spire.umbc.edu Spire project] we have been developing ontologies in OWL for taxonomic names and hierarchies. Ideally, we'd like to have a microformat where people can tag a scientific name and an application can then check an ontology of their choice for more information (richer semantics).

We would discourage full expression of the Linnaean hierarchy except for those who are maintaining such classifications (such as uBio). The rest of the hierarchy can be retrieved ontologically as necessary.

Better to tie the scientific name (taxon name) to the authority or ontology from which it came. I.e. for those who are able to provide information on taxonomic concepts, support for TCS (Taxonomic Concept Schema) fields would be important.

I prefer "taxon" or "taxon-name" or TaxonName over biota (which is plural, and too close to biotic which has a far larger scope than taxa). Would prefer "binomial" to "binominal"
*I also favour "taxon" over "biota" simply because it the more commonly used term. I also prefer "binomial". I did a quick straw poll of various experts and all favoured binomial. Neither is technically incorrect, but binomial is more commonly used. Indeed, a Google search for binomial returns 6,580,000 results while binominal returns 342,000 and a "did you mean: binomial" prompt. --[[User:CharlesRoper|Charles Roper]] 04:12, 9 Jan 2007 (PST)
**This [http://www.googlebattle.com/index.php?domain=%22binomial+name%22+-equation&domain2=%22binominal+name%22+-equation&submit=Go%21 binomial vs. binominal Google battle] seems even more conclusive. [[User:AndyMabbett|Andy Mabbett]] 06:17, 9 Jan 2007 (PST)
"class" is difficult not only because of the confusion with the programming concept of classes, but because it is a taxonomic rank. However, most of us have figured out the difference by now so this is not critical.

"cname" should be "comname" or "common-name" or "vernacular" to make it more obvious what the information is. A sub-component would be the language for which that common name is used ( something like an HTML attribute lang="en")
*I also favour "common-name" or "vernacular" --[[User:CharlesRoper|Charles Roper]] 04:12, 9 Jan 2007 (PST)

There are known conflicts between names across kingdoms (as current codes of nomenclature allow these). Thus specification of kingdom may be encouraged. Disambiguation could be handled by applications outside the microformats (this could be difficult), or they could be dealt with in the core microformat: e.g. plant-taxon or fungal-taxon or animal-taxon.

A sightings microformat is a good idea and I would be interested in being involved in that. We've been toying with this in OWL and also using structured blogging over at http://fieldmarking.reger.com

Your terms such as gender (better: sex), age bracket (better: life stage), count, type (better: depending on the meaning, caste or morph) all belong in a specimen or sighting microformat and used in combination with the taxon microformat, not be part of it.

===Response by Andy Mabbett===
Thank you very much for your detailed contribution. I have a few responses:

*We would discourage full expression of the Linnaean hierarchy except for those who are maintaining such classifications (such as uBio).
** Why? Also, I'm not aware of any microformat which is restricted to a subset of users, nor how this would be done. How would you suggest that someone mark up this: "Not all of the Passeriformes sing"?
*** I would prefer express this something like so:
<pre><nowiki>
<span class="taxon lsidres:urn:lsid:ubio.org:namebank:21833">
<i class="sci-name">Passeriformes</i>
</span>
</nowiki></pre>
Or, to simplify further:
<pre><nowiki>
<i class="taxon sci-name lsidres:urn:lsid:ubio.org:namebank:21833">Passeriformes</i>
</nowiki></pre>
Or, at the simplest level:
<pre><nowiki>
<i class="taxon">Passeriformes</i>
</nowiki></pre>
Simply marking up the word as a taxon would lighten the load of any parser, making its job much simpler. --[[User:CharlesRoper|Charles Roper]] 10:50, 8 Jan 2007 (PST)
***Your first example requires the author of that page to find LSID, even assuming that they know such a thing exists. How is that "paving the cowpaths"? Your latter example removes semantic detail which is included in the straw-man proposal. It is akin to removing all the children of "adr" in hCard. I think your parser-load issue is a red herring. [[User:AndyMabbett|Andy Mabbett]] 11:07, 8 Jan 2007 (PST)
**** I would argue that finding and using an LSID would not be a difficult task for any author who is using a microformat. I don't see how it is any more difficult - in fact I see it as being easier - than manually marking up ranks. Why is parser-load a red herring? --[[User:CharlesRoper|Charles Roper]] 12:26, 8 Jan 2007 (PST)
***Nice example (having done my doctoral work on a Passerine that may or may not be singing...). Absolutely I'd recommending marking up "Passeriformes" but no need to go on to specify "Aves." I'm still grokking microformats so I don't think we've got a conflict. [[User:CyndyParr|CyndyParr]] 10:20, 10 Jan 2007 (PST)
****''Aves'' is available for use, but not required, so indeed, we don't have conflict ;-) [[User:AndyMabbett|Andy Mabbett]] 10:42, 10 Jan 2007 (PST)
*The rest of the hierarchy can be retrieved ontologically as necessary.
**That's a use-case once the uF is published, certainly. the proposal doesn't require that the hierarchy be marked-up, it merely allows for it, in cases where it is '''already published'''.
***I've yet to see any consistent examples of a hierarchy being marked-up using class names resembling those found in the proposal. A microformat is supposed take (and perhaps tweak, or clean up) mark-up practises that are '''already in use''', not invent new ones. In other words, microformats should pave the cowpaths. While allowing for the marking-up of the hierarchy is fair enough (I understand the reasons for wanting that option), I believe the vast majority of authors do not need that facility, or (from my own experience) do not have time or energy to make use of anything more complex than simply marking-up a piece of text as a taxonomic name. In its current state, I don't believe the current species microformat proposal fulfils any of the "philosophy of microformats" points raised in [http://ifindkarma.typepad.com/relax/2004/12/microformats.html this article]. I believe the added complexity acts as a disincentive potential users and is also clearly confusing. With taxonomic intelligence (hierarchies, synonymy, etc) being available from elsewhere (e.g. uBio), why have it embedded in the microformat? What examples of this kind of usage are there and what leads you to believe authors '''will''' use it, if it's available? [[rel-license]] is an example of a microformat that is simple and holds intelligence elsewhere. I believe simplicity is the key to a successful species microformat. --[[User:CharlesRoper|Charles Roper]] 10:50, 8 Jan 2007 (PST)
****''I've yet to see any consistent examples of a hierarchy being marked-up using class names resembling those found in the proposal.'' Perhaps not but, unlike other uFs, in taxonomy there exist clearly defined standards for the names of the components of taxonomic names. This is akin to the pre-existing class names from vCard, as used in hCard.
*****Not so: vCard is widely used standard already and thus it was a natural progression to develop hCard. There is no software based vCard equivalent of the taxonomic hierarchy in common use that I am aware of.
****''A microformat is supposed take (and perhaps tweak, or clean up) mark-up practises that are '''already in use''''' Taxonomic classes ''''are '''' already in use.[[User:AndyMabbett|Andy Mabbett]]
*****My concern still stands that there is no consistent mark-up usage that I can find.
***Fair enough [[User:CyndyParr|CyndyParr]] 10:20, 10 Jan 2007 (PST)
****''I believe the vast majority of authors [...] do not have time or energy to make use of anything more complex than simply marking-up a piece of text as a taxonomic name''' and - as has been pointed out previously, they will be able to do the latter, and nobody will force them to do the former. Why should they not, though, be able to do the latter should they wish?
*****As I say, I find the concept of allowing the full suite of ranks to be fair - I understand your desire to have them in there. I just feel that the complexity they add to the specification will put off authors and confuse them. I also maintain that very few authors will make use of this extra complexity. Should we have some sort of poll to try and determine how many people would be able to make use of the full proposal? I'm not totally against having all of the ranks in the Species microformat, I've just yet to be convinced they are necessary or conducive to adoption of the standard. --[[User:CharlesRoper|Charles Roper]] 12:26, 8 Jan 2007 (PST)
****''What examples of this kind of usage are there'' Those on [[species-examples]], e.g. Wikipedia.
*****I've yet to find any consistent mark-up usage.--[[User:CharlesRoper|Charles Roper]] 12:26, 8 Jan 2007 (PST)
****''[[rel-license]] is an example of a microformat that is simple and holds intelligence elsewhere'''' It holds no intelligence elsewhere, which was not already on the pre-microformatting page.[[User:AndyMabbett|Andy Mabbett]] 11:07, 8 Jan 2007 (PST)
*****The license on the end of the rel-license link is the intelligence. To look at it from a different angle, why not embed the license information within class attributes? Why not have a full license microformat, just in case some author needs it? Rel-license as it stands serves the needs of most authors most of the time, which is a fundamental philosophy of microformats.
*Better to tie the scientific name (taxon name) to the authority or ontology from which it came.
**That would require the publisher to add extra data, which they might not wish to publish, nor, indeed, have to hand. Microformats are about recognising what data is '''already''' published and then enabling people to add semantics which identify the type of data on their pages.
***I'm just suggesting support for such authority or ontology for those of us who think it important [[User:CyndyParr|CyndyParr]] 10:20, 10 Jan 2007 (PST)
****Again, the option to do so is in the current proposal. [[User:AndyMabbett|Andy Mabbett]] 10:42, 10 Jan 2007 (PST)
*[common names] A sub-component would be the language for which that common name is used (something like an HTML attribute lang="en")
**Indeed, but that's already available, and (on properly constructed pages) should already be on the parent container. [[User:AndyMabbett|Andy Mabbett]]
***Fair enough [[User:CyndyParr|CyndyParr]] 10:20, 10 Jan 2007 (PST)
*conflicts between names across kingdoms (as current codes of nomenclature allow these). Thus specification of kingdom may be encouraged.
**already in the proposal! [[User:AndyMabbett|Andy Mabbett]]
***but perhaps the proposal could be more explicit about the importance of kingdom given its important role in disambiguating species names (using a name of any other rank is less desirable given instability and required application overhead). I realize that I'm going beyond the microformat itself to "best practices" but please forgive me; I've been wrangling with taxonomic databases for a long time. [[User:CyndyParr|CyndyParr]] 10:20, 10 Jan 2007 (PST)
*Disambiguation could be handled by applications outside the microformats
**Not sure what you mean here, since all parsing is done "outside microformats". [[User:AndyMabbett|Andy Mabbett]]
***Thanks for the clarification [[User:CyndyParr|CyndyParr]] 10:20, 10 Jan 2007 (PST)
***Another reason to make use of nameservers, rather than embedding the information within the microformat. --[[User:CharlesRoper|Charles Roper]] 10:50, 8 Jan 2007 (PST)
**** And how is enforcing the use of nameservers "paving the cowpaths"? [[User:AndyMabbett|Andy Mabbett]] 11:07, 8 Jan 2007 (PST)
*****The use of nameservers isn't enforced; it's optional (if disambiguation or further taxonomic intelligence is required). --[[User:CharlesRoper|Charles Roper]] 12:26, 8 Jan 2007 (PST)
******Agreed [[User:CyndyParr|CyndyParr]] 10:20, 10 Jan 2007 (PST)

(I'm either in agreement with your other points, or ambivalent.)

Thank you again - do stick around. Are you on the [[mailing-lists#microformats-discuss|mailing list]]?

[[User:AndyMabbett|Andy Mabbett]] 11:06, 5 Jan 2007 (PST)

*I am now! [[User:CyndyParr|CyndyParr]] 10:20, 10 Jan 2007 (PST)

==Pengo==

Unfortunately scientific names seem to change as often as common names. I have some examples and use cases this microformat needs to address, around the problems of ambiguity:

Ambiguity 1. Ambiguous scientific names.. ''[http://en.wikipedia.org/wiki/Sousa_chinensis Sousa chinensis]'' may either refer to '''Chinese White Dolphin''' (also known as ''Sousa chinensis chinensis'') or Humpback dolphin, also known as '''''Sousa''''' (genus) which includes up to five species or subspecies of dolphin including the Chinese White Dolphin. I don't care whether the Chinese White Dolphin is a species or subspecies, but the microformat needs to allow the user to be specific about which system is being addressed.

Ambiguity 2. Another example is the [http://en.wikipedia.org/wiki/Orangutan Orangutan]... or Orangutans. Organutans were once believed to be a single species, but are now considered two separate species. The problem is that the new scientific name for just the Bornean species (''Pongo pygmaeus'') is the same as the old scientific name which encompassed both species (''Pongo pygmaeus''). Meanwhile the new scientific name for the Sumatran Orangutan (''Pongo abelii'') is always unambiguous.

Ambiguity 3. ''[http://en.wikipedia.org/wiki/Doronomyrmex_pocahontas Doronomyrmex pocahontas]'' is an ant species that probably doesn't belong in the genus ''Doronomyrmex'', but rather ''Leptothorax''. But, until a full taxonomic study of the known species of ''Doronomyrmex'' and ''Leptothorax'' is carried out, it will stay there. Meanwhile the the term "''Leptothorax'' ([http://en.wiktionary.org/wiki/sensu_stricto sensu stricto])" is used to mean "in the sense of the original author".

Use cases:
So how do we:
# tag species in new documents, where we are using the most current nomenclature in the tags, to indicate that we don't mean the old nomenclature
# tag species allowing for new nomenclature to arise which may obsolete what we're using
# tag species in old documents, where we have updated the nomenclature in the tag, but the taxt may be referring to the old nomenclature, and we want to indicate that the updated nomenclature is being used.
# tag species in [others'] documents that are tagged automatically and where the specific nomenclature being used is unknown or ambiguous
# address issues where competing nomenclatures exist side-by-side, or transition periods
# tag species that have some clues as to which nomenclature is being used, e.g. the date of publication, and the author.
# tag a taxon which is now considered paraphyletic
# decide what's out of the scope of this microformat

Brainstorm solutions:
* Allow an "old-synonym" field, which strictly lists the previous name of the species (and never a newer name). So, e.g.
<pre><nowiki><span species="Pongo pygmaeus" old-synonym="Pongo pygmaeus pygmaeus">Bornean Orangutan</span></nowiki></pre>
* Allow the English common name to be included, when it clears ambiguity. E.g. the "Chinese White Dolphin" has always been called that, regardless of whether it was considered a species or subspecies.
* Allow a taxonomy-year field for what year the taxonomy used in the tag comes from.
* Use a UID as described by others above.
* Have an ad-hoc "disambiguation" field which could include anything to disambiguate, such as years, synonyms, "sensu stricto", common names, authors (i.e. "in the sense of this author") etc. What goes in it for a particular taxon will develop from usage.
* Have a taxonomy-uncertain="true" field to indicate it has been (for example) automatically tagged and may not be accurate, so that other suggestions can be given by 3rd party software.

Basically I don't synonyms are necessary unless they are to show that the species was previously called something else, which may help to give a more exact meaning.

Comments? Are there already existing solutions to this problem in the real world?
[[User:PeNGo|Pengo]] 19:49, 28 Jan 2007 (PST)

===Response to Pengo by Andy Mabbett===
Thank you for your expert contribution. Of your proposed solutions, the common (or vernacular) name, UID and author/ year are already in the current proposal. It may be sensible to have a "synonym" property (as used on http://en.wikipedia.org/wiki/Doronomyrmex_pocahontas), but I don't think "old-synonym" is particularly well named. Perhaps, if it's needed at all, "formerly" would be better? It is worth remembering, though, that the microformat is meant for labelling what people '''''already''''' publish and, for instance, http://en.wikipedia.org/wiki/Bornean_Orangutan refers to ''Pongo pygmaeus'', not any previous name. [[User:AndyMabbett|Andy Mabbett]] 02:20, 30 Jan 2007 (PST)
* Then most effective way to disambiguate is to use a UID. I feel other solutions would over-complicate the specification. I think we need to put some effort into populating the examples regrouped page with specific examples of publishing styles, e.g., plain binomials, plain common names, scientific names with common names, scientific names with synonyms, binomial with subspecies, etc. [[User:CharlesRoper|Charles Roper]] 05:25, 2 Feb 2007 (PST)
**There are very few exmples of UIDs being published in-the-wild. [[User:AndyMabbett|Andy Mabbett]] 06:00, 2 Feb 2007 (PST)
***I found a good source of synonym usage; see the Coleopterist's Checklist of Beetles of the British Isles: http://www.coleopterist.org.uk/checklist.htm. Look for the indented specific epithet names, e.g. in the family [http://www.coleopterist.org.uk/haliplidae-list.htm HALIPLIDAE], ''pallens'' Fowler, 1887 and ''halberti'' Bullock, 1928 are examples of synonyms, with the favoured specific epithet being ''confinis'' Stephens, 1828. On a more general note, checklists such as this are ripe for microformatting and are an excellent example of common markup practice. The species microformat could be used to great effect with content such as this, creating minable dictionaries of species names which are, in turn, essential tools in for use in biodiversity informatics. [[User:CharlesRoper|Charles Roper]] 14:43, 24 Feb 2007 (PST)
***Re. UIDs: yes, we have an interesting chicken & egg situation here. Without a reliable way to publish a UID (other than making them human readable text, which is undesirable) how are we supposed to be able to make use of them? A microformat would be a good means with which to deploy UIDs, but it is frowned upon to implement a pattern that isn't already being practised. Judging by the messages here, on the discussion list and elsewhere, there is clearly a desire for linking taxon names with UIDs, particularly LSIDs, which look set to become the standard UID for taxonomic naming. [[User:CharlesRoper|Charles Roper]] 10:41, 2 Feb 2007 (PST)
****Well, the proposal allows for the inclusion of UIDs (as with all the suggested attributes, some work on the exact format might need to be done), should people to chose to publish them; whether or not they do is not something for uFs to push for. [[User:AndyMabbett|Andy Mabbett]] 13:13, 2 Feb 2007 (PST)

==Charles Roper==
===Synonyms===
I found an interesting [http://collections2.eeb.uconn.edu/collections/insects/CTBnew/duodecimguttata.html example of synonym usage] in the [http://collections2.eeb.uconn.edu/collections/insects/CTBnew/checklist.htm Tiger Beetles of Connecticut checklist]. In the particular example cited, the synonyms refer to, or are associated with, the species name - ''Cicindela duodecimguttata'' Dejean 1825. Synonyms are often mentioned alongside or near preferred scientific names; how should we tie them together, especially when, as in this case, the name and the synonym are not positioned close to one another, but are still clearly associated? As a segue to this question, how should multiple synonymous common names be represented? How about common names in different languages? For example, the [http://names.ubio.org/browser/details.php?names=on&authors=on&sci=on&vern=on&namebankID=2478269 Otter has many different common names].

:I take it you refer to the text which may be paraphrased (by omitting some prose) as:

::'''''Cicindela duodecimguttata'' is known from 23 localities. ''Cicindela duodecimguttata'', once classified as a subspecies of ''C. repanda'', shares many traits with ''C. repanda''. Where ''C. duodecimguttata'' occurs, the more common ''C. repanda'' is usually found.'''

::'''Synonomies: ''Cicindela proteus'' Kirby 1837:9. ''Cicindela bucolica'' Casey 1913:28. ''Cicindela hudsonica'' Casey 1916:29. ''Cicindela edmontonensis'' Carr 1920:21'''

:The problem would seem to be that ''C. repanda'' is referred to both as a species in its own right, and as a past synonym of ''C. duodecimguttata''. If the whole thing is wrapped in one <code>div class="biota"</code>, allowing the other listed synonyms to be included, then how is ''C. repanda'' to be marked up as a species in its own right?

:I would mark up the first occurrence of each, then use the include-pattern to "attach" the other listed synonyms with the former (I've only included one synonym in the following, for clarity):

:<pre><nowiki>
<span class="biota">
<span class="binominal">Cicindela duodecimguttata</span>
<object class="include" data="#C-proteus"></object>
</span>

is known from 23 localities. Cicindela duodecimguttata, once classified as a subspecies of

<span class="biota">
<span class="binominal">C. repanda</span>
</span>

, shares many traits with C. repanda. Where C. duodecimguttata occurs, the more common C. repanda is usually found.

Synonomies:
<span class="synonym" id="C-proteus">
<span class="binominal">Cicindela proteus</span> [or maybe "synonym-binominal" ?]
<span class="authority">Kirby</span>
<span class="year">1837</span>:9.</span>
Cicindela bucolica Casey 1913:28. Cicindela hudsonica Casey 1916:29. Cicindela edmontonensis Carr 1920:21
</nowiki></pre>

:I might then use the its entry on the "shares many traits" line to mark up ''C. repanda'' as an synonym, and include it in the same way.

:Multiple and foreign-language common names would be catered for by allowing the common name attribute to be "0 or many" (the first such occurrence having precedence), and using a <code>lang</code> attribte where appropraite.

:[[User:AndyMabbett|Andy Mabbett]] 14:42, 28 Feb 2007 (PST)

==Ryan Kaldari==
1. The name of this microformat needs to be changed ASAP. Calling it "species" is confusing and misleading. There was even resistance to implementing this microformat in Wikipedia solely because of the confusing name.[http://en.wikipedia.org/wiki/Template_talk:Taxobox#Hidden_microformat_category]

2. Synonyms should be added as a node to the format.

3. I wouldn't worry too much about accommodating LSIDs specifically, as it seems to be a rapidly dying format. Just concentrate on accommodating GUIDs in general (of any format) and identifying them as such. Also, keep in mind that many objects are going to have more than one GUID (even though this is discouraged), so we should be able to accommodate this.

== Other use cases ==
Please add your suggestions!

'Species' microformats could be used to:
*...

==See also==
{{species}}

species

2021-04-28T17:16:47Z

Barnabywalters: Added inactive template per discussion in IRC

{{inactive}}

=Species=

:'''For the latest ideas, and to make comments, please see [[species-brainstorming]].'''

:'''Note: the original name of the proposed microformat, "species", is likely to change, probably to "biota" or "taxon". The former has been retained here, to avoid having to make many repetitive and perhaps redundant edits'''

:'''The [http://www.kaply.com/weblog/2007/02/16/operator-07a-is-available/ beta of Operator] (0.7a) detects ''Species''. [http://www.westmidlandbirdclub.com/records/lists-2004.htm A test page is available]. Work on both continues!'''

==Introduction==

People use the vernacular AND taxonomic names of species in everyday speech and writing - just read or watch any populist gardening magazine or television programme.

*Consider this list: "'''Blackbird'''", "'''poodle'''", "'''T Rex'''", "'''potato'''", "'''French Marigold'''", "'''Wisteria'''", "'''E. Coli'''", "'''HIV'''", "'''Rubella'''" and "'''human being'''".

:"'''T Rex'''" is "''Tyrannosaurus rex''"; "'''E. Coli'''" is "''Escherichia coli''"; "'''HIV'''" is "''Human immunodeficiency virus''" and "'''Rubella'''" is "''Rubella virus''". All are the taxonomic (or scientific) names of unique species.

:"'''''Wisteria'''''" is a taxonomic genus.

:"'''Blackbird'''"; "'''poodle'''"; "'''potato'''"; "'''French Marigold'''" and "'''human being'''" (arguments about Neanderthals not withstanding) are vernacular (or common) names, but still refer to individual species.

*The scientific naming of organisms is a part of [http://www.calacademy.org/research/informatics/sblum/pub/biodiv_informatics.html biodiversity informatics] - "the application of information technology to the domain of biodiversity".

*The proposal aligns with [http://www.ted.com/tedprize/2007/wilson.cfm E.O Wilson's wish]:

<blockquote>...that we will work together to help create the key tool that we need to inspire preservation of Earth's biodiversity: the Encyclopedia of Life [...] an encyclopedia that lives on the Internet, with an ever-evolving page for every species [and which]
does not duplicate existing efforts, but instead incorporates them through linking [with a] search technology that can aggregate existing biological information and make it easily accessible.</blockquote>

*As long ago as April 1998 on [http://www.w3.org/MarkUp/future/papers/rothenburg-19980412.html Robert Rothenburg's paper on Dictionaries] (''Note 4'') said:

<blockquote>What is missing [from HTML] is an element for marking up "proper names" (names of people, geographic locations, institutions, or even '''scientific names such as genus/species''').</blockquote>

:It's interesting that microformats have given us the first three missing items - and we're now debating the fourth!

==Proposal==
Imagine viewing a web page with a reference to a species - and being able to use an add-on to you browser to be taken directly to information about that species, on, say, Wikipedia, or Wikispecies, or Google Images, or another site, such as in an academic database, of your choosing.

Your software would automatically know to search site A if the scientific name referred to a moth, site B for a bird, and site C for a plant - and you could set your preferences as to which sites those were to be, and in which order two or more were to be searched (e.g. for moths, try [http://ukmoths.org.uk/ UK Moths] first, if not found try [http://www.nhm.ac.uk/research-curation/projects/lepindex/index.html The Global Lepidoptera Names Index]).

Or supposing someone writes a long, chronologically-ordered web page about all the birds, insects, mammals and plants they saw on a wildlife safari, with lots of prose description about the paces where they saw them and the people they were with, but you want to extract a list of species, sorted into alphabetical order within taxonomic class (birds first, then insects then...) or in taxonomic order.

Those are just two of the things a "species" microformat might do for you.

Your software, or a search engine, would be able to differentiate between a pages discussing HMS Beagle, the ship, and a Beagle dog; or birds that fly as opposed to a slang term for women.

Another benefit would be that user-agents could be instructed to treat text marked up in this way as not being in the base language of the document or element in which they occur - pronunciation should be as for Latin, they should not be translated (e.g. where a component word happens also to be a valid word in that language, such as the genus '''''Colon''''', '''''Circus''' cyaneus'', ''Hesperia '''comma''''', or anything with ''major'' or ''minor'' on an English-language page) and should not be spell-checked, or be spell-checked with a specialised dictionary (a need identified in this [http://www.alvestrand.no/pipermail/ietf-languages/2003-February/000590.html 2003 ietf-languages discussion of language values for taxonomic names]).

A further benefit the species microformat would bring is in the enriching and enhancement of species checklists, which are commonly found on the web. Broadly speaking, a species checklist is a list of taxa, usually for a particular group of similar organisms such as birds or vascular plants, found within a particular geographical region (a country, [http://www.westmidlandbirdclub.com/records/lists.htm a region], a county, or a specific site, large or small). A typical example of a species checklist is the [http://www.coleopterist.org.uk/checklist.htm Checklist of Beetles of the British Isles] which, as the name suggests, lists beetles known to be found within the British Isles. A [http://www.google.com/search?q=species+checklist Google Search for "species checklist"] will reveal many other such examples. Species checklists are presented in a broadly consistent manner but are usually unable to be parsed and utilised by computers due to the lack of a common standard for marking them up in HTML. The species microformat would provide that common standard. A fully microformat enabled checklist would be parsable by computers and thus would provide developers with a means by which to aggregate and otherwise make use of this invaluable content beyond the current, rather limited, use of simple online viewing.

A specific example of checklist use might be in enabling [http://www.aditsite.co.uk/html/choosing_recording_software.html biological recording software] to parse and aggregate checklists in order to include them in their own species dictionaries. Typically there are waits of many months or even years while humans collate checklist changes manually for inclusion in recording software; automated checklist parsing and aggregation would greatly expedite and increase the efficiencies of this process.

==Existing taxonomies==
The proposal respects all existing biological taxonomies, and is not intended to change or supplant any of them - it is intended merely to provide webmasters (from personal hobby sites to major academic databases; from news outlets to retail organisations) with a method of either:

# marking-up a taxonomical name (or taxon-common name pair) in such a way that its components can be recognised by computers '''or'''
# marking up a common name, so as to associate with it a taxonomical name, in such a way that the latter's components can be recognised by computers.

==Embedding within other microformats==
The proposed [[plant]] microformat (with care regime, supplier, etc.), [[hlisting]], [[recipe]] or [[hReview]] (and possibly others) could contain a scientific name microformat, in the same way that an [[hCalendar]] can contain an [[hCard]].

See also: [[species-brainstorming#Future development]]

==References==

====General taxonomy====
* [http://en.wikipedia.org/wiki/Scientific_classification Wikipedia: Scientific classification]
**[http://en.wikipedia.org/wiki/Binomial_nomenclature Wikipedia: Binomial nomenclature]
**[http://en.wikipedia.org/wiki/Binomen Wikipedia: Binomen]
**[http://en.wikipedia.org/wiki/Trinomial_nomenclature Wikipedia: Trinomial nomenclature]
**[http://en.wikipedia.org/wiki/Trinomen Wikipedia: Trinomen]
**[http://en.wikipedia.org/wiki/Taxon Wikipedia: Taxon]
**[http://en.wikipedia.org/wiki/Rank_%28zoology%29 Wikipedia: Rank (zoology)]
**[http://en.wikipedia.org/wiki/Rank_%28botany%29 Wikipedia: Rank (botany)]
**[http://en.wikipedia.org/wiki/Cultivar Wikipedia: Cultivars]
**[http://en.wikipedia.org/wiki/Variety_%28biology%29 Wikipedia: Varieties]
**[http://en.wikipedia.org/wiki/Subvariety Wikipedia: Sub-varieties]
**[http://en.wikipedia.org/wiki/Form_%28botany%29 Wikipedia: forms]
**[http://en.wikipedia.org/wiki/Synonym_%28taxonomy%29 Wikipedia: Synonyms]
**[http://en.wikipedia.org/wiki/Wikipedia:How_to_read_a_taxobox How to read a taxobox]

====Taxonomic codes====
* [http://en.wikipedia.org/wiki/Nomenclature_Codes Wikipedia: Nomenclature Codes]
* [http://www.iczn.org/ http://www.iczn.org/ International Commission on Zoological Nomenclature] (ICZN)
** [http://en.wikipedia.org/wiki/International_Code_of_Zoological_Nomenclature Wikipedia: International Code of Zoological Nomenclature]
**[http://en.wikipedia.org/wiki/International_Commission_on_Zoological_Nomenclature Wikipedia: International Commission on Zoological Nomenclature]
* [http://ibot.sav.sk/icbn/main.htm International Code of Botanical Nomenclature] (ICBN)
** [http://en.wikipedia.org/wiki/International_Code_of_Botanical_Nomenclature Wikipedia: International Code of Botanical Nomenclature]
* [http://www.the-icsp.org/ International Committee on Systematics of Prokaryotes] (ICSP)
**[http://en.wikipedia.org/wiki/International_Code_of_Nomenclature_of_Bacteria Wikipedia: International Code of Nomenclature of Bacteria] (ICNB)
* [http://www.ictvonline.org/ International Committee on Taxonomy of Viruses]
**[http://en.wikipedia.org/wiki/International_Committee_on_Taxonomy_of_Viruses Wikipedia: International Committee on Taxonomy of Viruses]

====Other references====

*[http://www.rhs.org.uk/rhsplantfinder/plantnaming.asp RHS Plant Finder: The naming of plants]
*[http://www.ishs.org/sci/icracpco.htm International Code of Nomenclature for Cultivated Plants]
*[http://www.tdwg.org/index.html Taxonomic Databases Working Group]
*[http://www.hortax.org.uk/ Hortax] - The Names of Garden Plants
*[http://www.bgbm.fu-berlin.de/iapt/nomenclature/code/SaintLouis/0000St.Luistitle.htm www.bgbm.fu-berlin.de/iapt/nomenclature/code/SaintLouis/0000St.Luistitle.htm]
*[http://species.wikimedia.org/wiki/Main_Page WikiSpecies]
*[http://en.wiktionary.org/wiki/taxonomy Wiktionary: Taxonomy]
*[http://jbi.nhm.ku.edu/index.php/jbi/article/view/25 Biodiversity Informatics: Taxonomic names, metadata, and the Semantic Web]
*[http://en.wikipedia.org/wiki/Virus_classification Wikipedia: Virus classification]

==Contributors & Supporters==
*[[User:AndyMabbett|Andy Mabbett]] (proponent)
*[[User:RogerHyam|Roger Hyam]] (interested party?)
*[[User:SXBRC|Charles Roper]], [http://www.sxbrc.org.uk/ Sussex Biodiversity Record Centre] (proponent)
*[[User:SteveMcBill|Steve McWilliam]], [http://www.rECOrd-LRC.co.uk/ rECOrd - The Biodiversity Information System for the Cheshire region] (supporter)
*[[User:KierenPitts|Kieren Pitts]], [http://www.ilrt.bris.ac.uk/ ILRT - Institute for Learning and Research Technology] and the [http://www.amentsoc.org/ Amateur Entomologists' Society] (supporter)
*[[User:CyndyParr|Cyndy Parr]], [http://spire.umbc.edu Spire project] (interested party)
*[[User:AnimalDiversity|Animal Diversity Web]], [http://animaldiversity.org] (interested party)
*[[User:Christoph|Christoph Champ]], [http://www.christophchamp.com/] (supporter with a background in biochemistry, biophysics, and bioinformatics)
*[[User:David Stang|David Stang]], [http://ZipcodeZoo.com] (interested party)
*[[User:StuartTurner|Stuart Turner, DVM]], [http://leafpath.org Leafpath Informatics] (interested party)

==See also==
Here's some work-in-progress:
{{species}}
*[https://addons.mozilla.org/firefox/169/ Biobar] - A customisable Firefox Extension providing a toolbar and content menu options for browsing biological data and databases, which shows what a user-agent could do, with data extracted from a species microformat

==Examples in the wild==

* An example use of the species microformat on the [http://www.amentsoc.org/insects/fact-files/orders/hymenoptera-parasitica.html Amateur Entomologists' Society Web site].
*Social network for gardeners marking up plant names with microformats [http://www.growsonyou.com/plant/Cosmos_bipinnatus Grows on You].
*A "proof-of-concept" example, with binomial and sub-family, but no other ranks, has been added to the Wikispecies entry for [http://species.wikimedia.org/wiki/Glaucidium_sanchezi Glaucidium sanchezi]; and to its subfamily, [http://species.wikimedia.org/wiki/Surniinae Surniinae]. See [http://species.wikimedia.org/wiki/Wikispecies:Microformat Wikispecies:Microformat] for related discussion.
*The current "[[species-brainstorming#Straw man proposal|straw man]]" for the Species microformat has been deployed, in part, on Wikipedia. '''''All''''' Wikipedia articles with "[http://en.wikipedia.org/wiki/Template:Taxobox taxoboxes]" (information panels on living things; and there are '''37,140''' as at the time of posting) now emit a species microformat. For example [http://en.wikipedia.org/wiki/Southern_Tamandua Southern_Tamandua] (a species) and [http://en.wikipedia.org/wiki/Anteater Anteater] (a family of species).
* A [http://www.westmidlandbirdclub.com/records/lists-2004.htm West Midland Bird Club test page] is available.
* [http://www.bbc.co.uk/nature/family/Megapode BBC Wildlife Finder]

==Implementations==
*[https://addons.mozilla.org/firefox/4106/ Operator] has a user-script for parsing ''Species''.
*[http://buzzword.org.uk/cognition/ Cognition] has an [http://buzzword.org.uk/cognition/uf-plus.html#species experimental implementation].

===Implementations (pending)===
*[http://www.spacefornature.co.uk/biorec/taxoncheck.htm Taxon Checker] - a software tool which, given a common name, searches for the relevant taxonomic data and outputs the selected species' details as (among other options) an HTML fragment. It is intended to provide templates for outputting such fragments with "species" microformat markup, once this proposal is implemented.
*[http://en.wikipedia.org/wiki/User:Beastie_Bot Wikpedia's Beastie Bot] can be used to update the "taxoboxes" of articles about living things/

Template:inactive

2021-04-28T17:16:32Z

Barnabywalters:

<div style="padding: 1em; border: 5px solid #af0011; background: #fcd2cf; font-size: 1.5em; margin-bottom: 1em;"><strong>Warning:</strong> This page is inactive, outdated, and no longer represents the current approach to developing microformats. See also: [[process]]</div>

Template:inactive

2021-04-28T17:14:19Z

Barnabywalters: Created, draft of template for old, inactive pages

<div style="padding: 1em; border: 5px solid #af0011; background: #fcd2cf; font-size: 1.5em;"><strong>Warning:</strong> This page is inactive, outdated, and no longer represents the current approach to developing microformats. See also: [[process]]</div>

microformats2-parsing-issues

2016-03-13T22:35:59Z

Barnabywalters: /* exclude style elements before parsing */

This page is for documenting issues with the [[microformats2-parsing]] specification.

== issues ==
Open issues in various states of partial resolution from none to nearly resolved.

=== ignore u-camelCase properties ===
Due to Suit CSS (and others? citations?) recent (2015-?) use of "u-*" class names for so-called "[http://davidtheclark.com/on-utility-classes/ utility classes]", we are seeing some false positives in a few very rare instances, e.g.: http://www.unmung.com/mf2?url=http%3A%2F%2Fwww.kevinmarks.com%2Ftwitterutils.html&html=&pretty=on

(Nearly) all these "utility classes" use camelCase for the class name suffixes, thus we can filter them out by looking for camelCase (since microformats class name conventions are always all lowercase and hyphenated), or even just looking for (and rejecting) *any* capital letters.

Proposal:
* microformats2 parsers MUST IGNORE u-* classnames where the * has any uppercase letter(s).

<div class="discussion">
* +1 [[User:Tantek|Tantek]] Let's get this fix rolling quickly to avoid further pollution.
* +1 [[User:Barnabywalters|Barnaby]] php-mf2 already ignores classnames with capitalised prefixes, ignoring any classnames with capital letters seems totally reasonable
* ...
</div>

=== exclude style elements before parsing ===
[http://logs.glob.uno/?c=freenode%23microformats#c85457 2016-01-25 raised in #microformats]

Ran into an issue of a <style> element being parsed as plain text in a p-name. Should [[microformats2-parsing]] be updated to indicate <style> should be excluded when parsing? Appears to implicitly fall under [[microformats2-parsing#note_HTML_parsing_rules]]

Sample link: http://veganstraightedge.com/notes/2016/01/16/tonight-s-dinner-tacocleanse-beverly-hills-c

The <script> tag can be similarly problematic.

Proposal: Drop both <script> and <style> elements completely when parsing any property (including e-* HTML values). [[User:Tantek|Tantek]] 01:01, 29 February 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Aaronpk|aaronpk]] as a consumer of HTML from an e-* property, I will always be sanitizing the HTML and removing <script> and <style> anyway
* +1 [[User:Kylewm|kylewm]]
* 0 [[User:Barnabywalters|Barnaby]] +1 to removing the contents of <script> and <style> from all plaintext properties (and 'value' property in HTML dicts), -1 to removing <script> and <style> from HTML. That’s a job for a sanitization stage. As aaronpk points out, sanitization will have to be done anyway if the content is to be reposted, so doing so in the parser doesn’t actually save anyone any work, but removes information which could be useful to people (example use cases: publishing posts with embedded per-post styling, publishing interactive HTML documents with embedded javascript)
** +1 this seems like reasonable feedback to make a new refined proposal. [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)
** +1 I like the revised proposal and am happy to change my vote to this [[User:Aaronpk|Aaronpk]] 21:16, 13 March 2016 (UTC)
</div>

Proposal 2: Drop both <script> and <style> elements completely when parsing any property (except for e-* HTML values, which preserve all markup). [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Barnabywalters|Barnaby]]
* ...
</div>

=== use poster if no src on video for u props ===
[https://indiewebcamp.com/irc/2015-12-13#t1450035721661 2015-12-13 raised in #indiewebcamp]

There is a use-case of marking up the "poster" of a video element as the u-featured of an [[h-entry]], to do that, we need to change [[microformats2-parsing#parsing_a_u-_property|u- property parsing]] to look at the poster attribute of the video element, after it's looked for the src attribute.
<blockquote>" else if video.u-x[poster], then get the poster attribute "</blockquote>

Real-world example of markup in the wild:
* http://veganstraightedge.com/videos/2013/5/31/1/backyard-squirrel-buddy
** and likely all other videos posted there.

Background discussion that led to this proposal:
* https://indiewebcamp.com/irc/2015-12-13#t1450035721661

This seems very straightforward so I've added it as PROPOSED directly in the parsing spec. This issue is for tracking the discussion.

Feedback from parser implementers please!
<div class="discussion">
* +1 [[User:Barnabywalters|Barnaby]] easy to implement and based on real-world markup, no objections
* ...
</div>

=== uf2 children on backcompat properties ===
[http://logs.glob.uno/?c=freenode%23microformats&s=today#c84632 2015-11-24 raised by Calli] in #microformats

Related but different from [[#uf2_children_inside_a_classic_microformats_root_class_name]], when there is a uf2 child directly on a backcompat property, what should happen? E.g.

<source lang=html4strict>
<div class="vcard">
<div class="adr h-adr">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

What is the expected behavior and parser output?

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-adr"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

<div class="discussion">
* Proposal: the nested "adr h-adr" child is treated as an mf2 object, not backcompat, and thus the resulting parsed "locality" property has a single value of "MF2". Proposed by Calli, noting that Glenn Jones's microformatshiv gets that result currently, and it would be easier for him (Calli) to implement this way.
** +1 Tantek, seems reasonable and the reasoning provided is good (we have one implementation this way already)
** +1 Kyle, this is consistent with the resolution to the related issue
** +1 Calli, yes, this is easier for me to implement (than taking both MF1 and MF2 properties) because it is consistent - for me, consistency is the controlling factor in favor rather than ease of parser implementation
** +1 Barnaby, php-mf2’s mf1 backcompat produces this exact result, and it makes a lot of sense to me
** ...
</div>

Another example:

<source lang=html4strict>
<div class="vcard">
<div class="adr h-custom">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-custom"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

Per the [[#any_h-_root_class_name_overrides_and_stops_backcompat_root]] resolution, the class name "h-custom" overrides the use of "adr" as a backcompat root.

=== default generated HTML ===
2015-09-08 raised by Tantek in #indiewebcamp

Should there be a default (perhaps not quite "canonical") way to map/generate HTML+microformats2 from a parsed mf2 JSON output?

E.g. straw proposal:
* JSON/mf2 -> [[XOXO]]+mf2

Existing work / mappings:
* https://github.com/snarfed/granary/blob/master/granary/microformats2.py#L295

Related to:
* https://github.com/snarfed/granary/issues/31

Use-cases:
* default webview / presentation for a site that stores mf2 JSON output
* possibly a way to implement a distributed HTTP webcache retrieval protocol

Thoughts?
<div class="discussion">
* +1 [[User:Tantek|Tantek]] I think we should have this, but am open to proposals on specifics!
* +1 [[User:GlennJones|Glenn]] Also think this is worth looking at, but I am not sure it should be part of the parser spec. Feels like it should be built as a separate library and have it own spec on the microformats wiki.
* +1 [[User:Barnabywalters|Barnaby]] agreed with Glenn, this would be a nice thing to have, but IMO it’s out of scope for the parser and should be specified separately. Personally I would probably implement it separately too, depending on how much work it is.
* ...
</div>

=== Noscript skip/parse ===
2015-07-28

Should mf parsers skip <code><noscript></code> tag in the HTML, like the <code><template></code> tag mentioned in http://microformats.org/wiki/microformats2-parsing#note_HTML_parsing_rules ?

mf2py skips <code><noscript></code> when using the html5lib DOM parser but no when using lxml parser. Example use of <code><noscript></code> https://kartikprabhu.com/ featured images have a no javascript fallback image inside <code><noscript></code> with <code>class='u-featured'</code> markup.
* html5lib actually HTML-escapes the contents of <code><noscript></code>, so to mf2py it just looks like plain text with no tags. In Woodwind, I've resorted to using regex to strip out <code><noscript></code> tags before parsing (very hacky). [[User:Kylewm|Kylewm]] 15:52, 25 August 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] skip noscript (and inside) because in today's typical browsing contexts, nothing in noscript is displayed, thus we should discourage marking up effectively invisible content.
** Proposed change to [[microformats2-parsing#parse_a_document_for_microformats]]:
*** from: "follow the HTML parsing rules"
*** to: "follow the HTML parsing rules (including skipping/omitting <code><noscript></code> elements, e.g. like the html5lib DOM parser)
* -1 [[User:GlennJones|Glenn]] This subject does need to be address, but differently to proposed change. My personal view is that e-* html should be passed through raw and then the consumer can process it in a way they feel fit. Its a case for helper libraries. I am about to build a helper library to do this based on the Readability code to post process e-* html. Other people may want to take different approaches, defining this in the spec feels like move into a whole area of new functionally.
* 0 [[User:Barnabywalters|Barnaby]] to me this should be treated the same as the script/style contents — removed completely from all plaintext properties, but left unaltered in raw HTML.

As a separate new point we need to consider "exclude tags" lists for parsed text from html. We should consider <code><noscript></code>, <code><noframe></code> and <code><template></code> there maybe other I have not gone through all the tags in current HTML spec. Also we should consider what to do about the more common pattern of fallback text within media tags <code><video></code>, <code><audio></code> etc. This should be explicitly discussed in the parsing rules. At the moment my experimental text normalisation does exclude tags, but the default text parse does not. Currently the fallback content in media tags like <code><video></code> is added to the parse text. 12:56, 25 Septemeber 2015 (UTC)
* [[User:Barnabywalters|Barnaby]] in theory, as the video and audio data by default can’t be included in plaintext properties, and the fallback content (much like img alt attributes) should be somehow human-readable and useful, I would suggest keeping it in plaintext properties. I’d like to see some real-world examples of what fallback content people are using — if it’s links or plaintext descriptions this approach could work well, if people are writing instructions saying “install flash” or “update your browser” it’s not going to produce very pretty results
* ...
</div>

=== Standard datetime format ===
2015-07-28

http://microformats.org/wiki/microformats2-parsing#parsing_a_dt-_property does not specify any standard format to use for datetimes. e.g. <pre>2015-07-28T12:55:33</pre> vs <pre>2015-07-28 12:55:33</pre>
Would be good to standardize this to compare various parser outputs.

2015-07-29: This subject is (somewhat) covered in http://microformats.org/wiki/iso-8601 As it stands the JavaScript parsers support output in the 3 main profiles, 'W3C Note', 'RFC 3339' and 'HTML5' plus 'auto' which keeps authors format. The default date output for the JavaScript parsers is the same format as the date was originally authored in. This can be changes by setting the options.dateFormat switch to any of the other profiles mentioned. It would be good if other parser also had a switch to force output to a common profiles so we could compare various parser outputs, but I think the default should be how a date was authored. All output whatever profile should also keeps the authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string. This is important if you want to compare parser outputs.

The only exception to this where date and times are combined such as the implied h-event rule for dt-start and dt-end where I output in the HTML5 style 2015-07-29 12:55:33 as there is no predefined author preference and HTML5 profile is more human readable. [[User:GlennJones|Glenn Jones]] 11:02, 29 July 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] output more human readable <code>2015-07-28 12:55:33</code> canonically, with authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string.
** Let's update any test cases as needed for this. - [[User:Tantek|Tantek]]
* ...
</div>

=== implied date for dt properties both mf2 and backcompat ===
The [[value-class-pattern#microformats2_parsers|value class pattern dt-* date proposal]] should apply to both mf2 dt-* properties, and backcompat classic microformats, to preserve the hAtom / hCalendar optimizations noted on that page, but in a generic way.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] 16:12, 18 August 2015 (UTC)
* +1 [[User:Glenn Jones|Glenn Jones]] 20 August 2015
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== implied properties when an explicit class is provided ===
<div class="discussion">
Should "u-url" still be implied if another explicit class is already provided, as below. This is a contrived example, but it is taken from Bridgy's unit tests.

<code><pre>
<article class="h-entry">
<a class="u-like-of" href="http://orig.domain/baz">liked this</a>
</article>
</pre></code>

In this case, http://orig.domain/baz is almost certainly not the u-url, so IMO it would be better to leave it out —[[User:Kylewm|Kylewm]] 15:10, 7 October 2014 (UTC)

'''2015-01-20 consensus'''
* Changed my mind. Simpler to do nothing. Example provided is artificially constructed, does not reflect likely real world confusion of if we make implied properties more complicated. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
* ++ Consensus on do nothing for this case. At [[2015-01-20]]

'''Proposed resolution:'''
* Changed again. Due to indiewebcamp.com/edit use-case, this now makes sense for all implied properties. That is:
** If an element has any explicit property class name(s) on it, then it must not be used to imply any properties. [[User:Tantek|Tantek]] 20:50, 27 May 2015 (UTC)
*** +1 this seems reasonable, if a publisher is going to add an mf2 class, it is unlikely they want other classes automatically implied from the same value [[User:Aaronpk|Aaronpk]] 23:19, 29 November 2015 (UTC)
*** -1 for now. To my knowledge, this has only been observed in artificially constructed unit tests and examples, and it adds some weird edge cases that are hard to reason about. [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** ... provide input on this proposal here
** Refined: Or should this be refined by per parsing prefix? [[User:Tantek|Tantek]] 22:59, 18 September 2015 (UTC)
*** Any explicit "p-*" property means no implied "p-name" from that element
*** Any explicit "u-*" property means no implied "u-url" nor "u-photo" from that element.
*** ... provide input on this refined proposal here
** Suggestion: split this issue up per property. I think it makes sense for u-url and can be easily added to the spec as e.g. ".h-x>a[href]:only-of-type:not[.h-*<strong>,.u-*</strong>]". [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** Obviously wrong to assume a link explicitly pointing elsewhere is our "url"
*** More difficult to make a case for photo and especially for name.
*** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
*** ... provide input on this refined proposal here
</div>

=== whitespace collapsing revisited ===
2015-05-27: (raised by [[User:Kevin Marks|Kevin Marks]] per Glenn Jones)

Revising the microformats tests to conform to the "don't collapse whitespace" rule below reveals some non-intuitive cases.
preserving whitespace in addresses is somewhat defensible, but in an implied name it is often unhelpful, as it preserves non-user visible space there for authoring reasons.

For example:
[https://github.com/microformats/tests/commit/a325e0e9bc2089507e69b1883f7065a3316e07c2#diff-d577012c1438978a571c4049179607f0 this test] shows how extraneous whitespace ends up in the <code>name</code>

<code><pre>
<div class="h-review-aggregate">
<div class="p-item h-event">
<h3 class="p-name">Fullfrontal</h3>
<p class="p-description">A one day JavaScript Conference held in Brighton</p>
<p><time class="dt-start" datetime="2012-11-09">9th November 2012</time></p>
</div>

<p class="p-rating">
<span class="p-average value">9.9</span> out of
<span class="p-best">10</span>
based on <span class="p-count">62</span> reviews
</p>
</div>
</pre></code>

give a parsed result of:

<code><pre>
{
"items": [{
"type": ["h-review-aggregate"],
"properties": {
"item": [{
"value": "Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012",
"type": ["h-event"],
"properties": {
"name": ["Fullfrontal"],
"description": ["A one day JavaScript Conference held in Brighton"],
"start": ["2012-11-09"]
}
}],
"rating": ["9.9"],
"average": ["9.9"],
"best": ["10"],
"count": ["62"],
"name": ["Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012\n\n\n9.9 out of \n 10 \n based on 62 reviews"]
}
}],
"rels": {}
}
</pre></code>

The <code>value</code> is a reasonable textual representation of the event, but the implied <code>name</code> is full of spurious whitespace that any consumer would have to strip.

[https://github.com/microformats/tests/commit/4c9690b53b0a2f40440abac8e609c51ac7dd6d56 h-review] has similar issues

2015-05-28: (Addition by [[User:GlennJones|Glenn Jones]])

The example below shows the type of markup most effected by the "implied name" and "don't collapse whitespace" rule working together to produce output that is hard to use without further processing.

<code><pre>
<a class="h-card" href="http://glennjones.net">
<span class="p-given-name">Glenn</span>
<span class="p-family-name">Jones</span>
</a>
</pre></code>

The output for the name property from the above HTML would be <code>Glenn\r\n Jones</code> using the (trim lead/trailing) suggested in the parsing spec. I could of course move the spans onto one line, but it feels fragile to consider whitespace sensitivity in HTML like this. Added to the fact that HTML templating environments often take away that level of whitespace control from authors anyway.

There are issues with both: keeping whitespace, returns and tabs from parsed HTML or collapse that whitespace. If we return the whitespace it becomes mal-formatted for humans because it was only added to make the HTML code understandable and in most cases was not meant to be used/read outside of that context. If we collapse the whitespace we can have issues of whitespace sensitive text from <code><pre></code> etc. being incorrectly formatted.

Providing a CSS aware innerText feature would produce the most useable output, but this is too complex/time consuming to build for most parser developers. In the face of no perfect solution I have taken the 80:20 view, whereby errant whitespace, causes me considerably more problems than mal-formatted <code><pre></code> content so I collapse whitespace on all text returned.

This feature is a non-CSS aware version of innerText. It does not cover all rendering edge cases, but enough to produce practical output.

For now, I have started changing the node parser to flag "white-space collapsing" as an experimental feature which is off by default i.e. http://glennjones.net/tools/microformats/ but personally I will parse everything with this on as I find it the most practical solution.

Not sure where that leaves me on the options below.

Options:

Choose from:
# keep as is and every parser client has to post process for common cases.
# '''keep as is but have mf2 parser trim leading/trailing whitespace (likely to provide desired result and be reasonably backcompat)'''
#* +1 my preference of the two options. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
#* +1 though this doesn't solve any of the problems discussed above, it's still worth doing [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
#* +1 will help parsers be more consistent with each other, and I haven't ever encountered a case where preserving leading/trailing whitespace was desirable [[User:Kylewm|Kylewm]] 20:45, 8 June 2015 (UTC)

2015-06-08 option 2 resolved by consensus and implementation in mf2py.

Somewhat orthogonal:
* make <code>value</code> on properties with children normalise whitespace
** -1 Seems like a bad idea as this "value" is supposed to be the same as if there was no embedded child microformat. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
* make implied <code>name</code> normalise whitespace.
** +0 This is reasonable and already done somewhat in the parsing spec (trim lead/trailing). [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** +1 Given the universality of name, this would fix most of the issues we see. [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
* Put \n in textual forms if there is a <code><p></code> tag in the original.
** -1 that's a long path to go down with whitespace equivalents for HTML markup. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** would only preserving whitespace if in <pre> be an 80:20 compromise? [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)

Because there are both code markup and specific vocabulary (label) needs for preserving whitespace, we are compelled to preserve in general, perhaps except for very specific limited generic cases (e.g. trim leading/trailing, "value" parsing, implied name). [[User:Tantek|Tantek]]

=== u- parsing iframe src ===
Currently if I put u-* on an iframe it gets the value of the fallback text. This seems a shame. Getting the URL seems a sensible answer.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== i- parsing iframe src ===

More controversially, what about using an iframe for transclusion? A use case here is comments on a static site. Currently, on eg http://www.kevinmarks.com/microformatschema.html the comments are injected via JS, making them opaque to parsers and thus precluding further parsing such as salmentions.

If instead they were an iframe embedding them, a parser could optionally fetch its contents, parse them, and include them in the parsed mf2 output at that point. Overloading u-* for this seems wrong; e-* as below for srcdoc would have a different effect; this implies a new prefix directive would be needed. A strawman i-* (for include) may work.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== e- parsing iframe srcdoc ===
<div class="discussion">
* Proposal: addition of a new e-* parsing rule for iframe elements with srcdoc attributes. E.G.

<source lang="html4strict">
<div class="h-entry">
<iframe class="e-content" srcdoc="<p>A paragraph of HTML with "quoted quotes" &amp; doubly quoted ampersands</p>" />
</div>
</source>
<source lang="javascript">
{
"items": [{
"type": ["h-entry"],
"properties": {
"content": ["<p>A paragraph of HTML with "quoted quotes" & doubly quoted ampersands</p>"]
}
}]
}
</source>

This would allow, for example, HTML comments to be sandboxed inside iframes but still parsable as microformats.

I believe the correct processing would be to leave " entities as they are but to unescape any doubly-escaped ampersands.

** Is there any use case for that? —[[User:TomMorris|Tom Morris]] 12:32, 14 September 2013 (UTC)
** +1 we need documentation of use case and existing sites publishing iframe srcdoc like this - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
** Rejected by consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 properties on select ===
How should select elements with properties be treated any differently?

Awaiting real world examples / stronger use-cases, until then no special treatment of select elements with properties:
<div class="discussion">
* Are there any real world examples of select elements with microformats properties?
* What would the use-case be for putting a microformats property class name on a select element?
* Nothing special. By consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 root name on form ===
See what to do about <em>root class names</em> on <code><form></code> elements in particular:
* [[hcard-input]]

Awaiting real world examples / stronger use-cases, until then, no special treatment of root class names on <code><form></code> elements:
<div class="discussion">
* Are there any real world examples of a <code><form></code> element with a microformats root class name?
* [[hcard-input]] is one possible use-case, is anyone attempting to use forms for hCard input, e.g. with scripts to help make it work?
* Are there other use-cases for putting a microformats root class name on a <code><form></code> element?
* As of [[2015-01-20]] - no consensus - need more input as to when/why this is useful to do anything special.
</div>

===Parsing Literal Values===
Issue raised by: [[User:BenWard|Ben Ward]]

It is proposed for microformats2 that all microformats be parsable from just their root element, e.g. <code><p class="h-card">Ben Ward</p></code> would create an hCard with the following properties after parsing:

<source lang=javascript>
{
'type': ['h-card'],
'properties': {
'name': ['Ben Ward']
}
}
</source>

This is a four-fold change from the current [[hCard]]:
# type is generically identifiable as a microformat root, even in parsed form. The use of the 'h-' prefix persists into the type of the object. This is deliberately so, as a result of re-using the JSON data model of microdata which itself is re-using a common JSON convention, such that microformatted data is clearly distinguishable (as opposed to any other random schema that may be using a similar data model).
# root-class-only support. Per [[microformats-2-implied-properties]], the ''name'' property is implied by the entirety of the root class name element.
# 'name' instead of 'fn'. As also documented in [[microformats-2-implied-properties]], the continuous challenges/problems and need to repeatedly re-explain 'fn' over the years combined with the real-world market response of nearly every other party doing a person vocabulary renaming 'fn' to 'name', microformats 2 makes this change as well.
# There is no automatic parse-time inferring of <code>'given-name': ['Ben']</code> and <code>'family-name': ['Ward']</code>. Any such inferring *might* be made by a vCard converter, but is left up to that specific application (not all applications) built on that vocabulary, though even in that case it may not be necessary, as an empty "N:;;;" [[vCard]] property is sufficient to satisfy the N property requirement of [[vCard]], and also causes no problems when imported into various [[vcard-implementations]].

It is required of the extractor to understand that when a microformats object specifies no explicit child properties, that it must treat <code>h-card</code> as having a <code>p-name</code>. But, the parser is generic, so it also treats <code>h-review</code>, <code>h-entry</code>, <code>h-recipe</code>, <code>h-geo</code> as having a ‘<code>p-name</code>’.

As a result, specific vocabularies are evolved to drop their specific form of name (e.g. fn, summary, entry-title) and simplified to use a common 'name' property instead.

Note: while the overwhelming majority of real world publishing/consuming uses of microformats do so with proper nouns which have names (and thus this parser-level incorporation of an implied 'name'), there are some formats that do not have a 'name' semantic. For example, [[geo]], [[adr]], and possibly if/when developed, units of measure, length, cost. The current thinking is that the benefits to the far greater proper-noun use-case of microformats outweigh the technical inelegance of having an extra/ignored 'name' property on formats that lack such a semantic.

Some formats also may appear in theory to better imply some other property, e.g. a review might be thought to imply its ''content'', not its name, and an Atom entry its ''content'', not its title, but in practice (actual publishing patterns) this is not the case. Typically, brief unstructured reviews (or mentions thereof) provide a ''summary'' (often hyperlinked to an expanded structured form) of that review, not its content, and similarly, brief unstructured posts (e.g. RSS items) have historically most often been link blog items which include the title of an item and a link. Short status updates as well established by Twitter are newer and would seem to imply purely content with no title, at least semantically, however, even Twitter populates the RSS title and ATOM entry title of their feeds with the content. It's not clear what went into that decision, however, that's likely irrelevant, as the outcome turns out to be emergent consistency among publishing behaviors.

To avoid overloading or undermining the semantics of a vocabulary, I propose that we handle this at the extractor level in a simpler fashion: Define a new property for literal data, that an extractor will provide if no other information was available. All ''interpreters'' may then be instructed that in the event that an object has no properties, it can attempt to interpret the literal value from the page instead.

* This was one of the design iterations I went through which led me to the current implied 'name' design. Another iteration was the ability for a vocabulary to specify a single required property which was implied if there were no properties provided. However, the combination of the fact that in most cases such single required properties were quite name-like, and that a vocabulary-specific rule like that would then bind parsers to specific vocabularies (even so slightly) led me to collapse them into implying a 'name'. It's not perfect, but it's the best alternative so far that balances practical convenience of publishing/consuming, avoids vocabulary-specific knowledge in the parser, and technical (in)elegance. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

In existing microformats, the closest existing example we have for this is the <code>label</code> property in hCard, which is used to represent the literal address label for a place. It is a corresponding piece of <code>fn</code>, <code>org</code> and <code>adr</code> in combination, but has no structure in and of itself. Possibly, every microformat could have a <code>label</code> form where structured data is unavailable.

However in practice, the hCard <code>label</code> property is both little understood and little used. It's not even clear that it ought to be kept for microformats 2 (no known consumers, very few (if any?) real-world non-test publishers). This disuse is likely a good indicator that we should avoid basing anything on its design.

Alternatively, <code>value</code> is used throughout microformats to target a generic value (e.g. in combination with <code>price</code> in hListing.) It has been proposed that when parsing properties that are also themselves microformats, we create native objects of the form:

{
'value': '1900 12th Street, San Francisco, CA 94'
, 'type': ['h-adr']
, 'properties': {
'street-address': '1900 12th Street'
, 'etc': 'etc'
}
}

We could apply this same pattern to the root level:

{
type: [h-card]
, properties: {}
, value: 'Ben Ward'
}

In this case, an interpreter or implementation is responsible for using <code>value</code> in place of <code>fn</code>, or restructuring the object. It would be the responsibility of each vocabulary to define its root property. The parsing layer of microformats 2.0 would not impose semantics or naming onto that.

For another example, h-geo would end up like this:

{
type: [h-geo]
, properties: {}
, value: '1.3232;-0.543'
}

* This is an alternative I've been considering as well: [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)
** 'value' is more generic than 'name' (applies to more vocabularies) with the trade-off that it naturally has less (weaker) semantics.
*** +1 I think that having naturally weaker semantics would be appropriate for this parsing functionality. —[[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC)
** The interesting thing that this analysis has revealed is that there appear to be two distinct clusters of microformats, the much more commonly used/understood/useful proper-noun microformats which markup things with names (people, events, reviews, recipes), and the less used compound-data microformats which are often used ''inside'' other microformats and just have some sort of semi-structured value (adr, geo, measure, and perhaps even things like tel). Perhaps this is implying the possibility and some degree of utility for ''two'' microformats root class name prefixes, 'h-' for existing proper-noun microformats, and something else ('m-' for microformat/molecule?, 's-' for structured-value?, 'v-' for value (though historically "v-"/"v." has meant "vendor-specific")?) for unnamed structured data microformats.
*** This more and more feels like a good idea, and I'm leaning toward "s-" for struct / structure / structured value. "s-" works just like "h-" except that it doesn't imply any properties at parse time. We can try it and see what happens. There's also no harm if publishers just use "h-" structures, they just (possibly) get a few extra properties if they happen to omit properties.
** Parallels the same JSON when a property has both a string value ''and'' is a structure itself.
*** Changed my mind on this. The parallel is not quite there. 'name'/'url'/'photo' are only implied if there are NO properties, where as the JSON string value + structure convention *always* provides a 'value'. [[User:Tantek|Tantek]] 22:39, 4 October 2011 (UTC)
*** And due to this difference in behavior ('value' is there when nested properties are present, whereas 'name' is only implied when there are no properties specified), I think it's correct to keep them separate, i.e. stick with implied 'name'. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
** However, I'm still currently leaning towards the practical convenience of providing a 'name' for the vast majority of microformats uses, rather than diluting this feature for the sake of avoiding implying inapplicable semantics to the few plain structured data microformats, and even then, only when no properties are explicitly specified! I'd rather introduce a new root prefix for those than lose the simplicity and utility of implied 'name'. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

== resolved ==
=== When to collapse whitespace in properties ===

The spec doesn’t explicitly require whitespace to be collapsed or not. The official mf2 test suite requires it to be collapsed.

Reasons why whitespace ''shouldn’t'' be collapsed:
* Plaintext property representations of syntax-highlighted code, poetry and song lyrics require whitespace to be present
* Whether or not whitespace is an important part of the content being parsed is determined by css white-space and CANNOT be inferred from HTML markup alone

Resolution 2013-11-12: Agreed, whitespace should not be collapsed (other than normal HTML5 parsing rules). The spec now refers to "textContent" rather than "innertext" to make this explicit.

=== How to interpret mf2 classnames on form inputs ===
E.G. how to parse:

<source lang=html4strict>
<input class="u-url" value="https://brennannovak.com/notes/338" />
</source>

Examples in the wild: https://brennannovak.com/notes/338

See proposal:
* [[hcard-parsing-brainstorming#input_element_handling]]

Resolution 2013-11-12: Per that proposal, p- u- dt- properties on input[value] elements now use the value attribute.

=== mixture of microformats2 and classic microformats classnames on different elements ===
Some sites in the wild have mistakenly combined classic mf and mf2 markup in ways which misrepresent the content if parsed in BC mode.

Typically this is caused by putting classic and mf2 classnames for the same vocabulary on different elements, e.g:

<source lang="html4strict">
<body class="hentry">
<article class="h-entry">
<h1 class="p-name"></h1>
</article>
</body>
</source>

Sites where this has been observed:
* http://acegiak.machinespirit.net/2013/10/17/barnaby-walters-notes-another-thing-i-love-about-the-web-users-have-the-power-to-take-control-of-their-uis-and-improve-their-own-experiences-aside-drm-for-html-would-prevent-this-from-being-possibl/
* http://shawfactor.com/2013/08/06/thoughts-on-extending-webmentions/ (fixed)
* http://notizblog.org/2013/06/18/the-rise-of-the-indieweb/ (fixed)

Discussion:

* As far as I can tell, the problems in all of these examples were caused by mf2 markup being injected by a wordpress plugin, but classic mf classnames being present further up the DOM in the themes. When parsed in compatibility mode, the classic mf classnames are transformed into mf2 classnames, making the original mf2 classnames look like children of empty items.
* Turns out this isn’t theme-specific, WordPress injects hentry via PHP [http://indiewebcamp.com/irc/2013-10-22/line/1382448759]. The bug with the wordpress mf2 plugin is resolved as of [http://indiewebcamp.com/irc/2013-10-22/line/1382449035 2013-10-22] --[[User:Barnabywalters|bw]] 13:38, 22 October 2013 (UTC)

=== e- and p- escaping levels ===
<div class="discussion">
* The fact that the parsed value of any element with .e-* is at a different level of escaping to the parsed values of p-*, dt-* etc. without any indication of how the property was parsed in the output is a security problem. For example:

<table style="width: 100%">
<tr>
<th>input</th>
<th>output</th>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="p-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="e-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
</table>

* As a parser developer, the most straightforward way I can think of solving this is to add an option (enabled by default) which encodes HTML special characters on all non e-* properties, so the developer knows that all property values are going to be at the same level of escaping. --[[User:Barnabywalters|bw]] 20:00, 15 June 2013 (UTC)
** Your suggestion of auto-HTML-encoding p-*/u-*/dt-* property values is the most sensible I think. I would NOT make it an option, as it makes sense write consistent microformats2 consumers. - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
** Can you think of any existing apps/consumers of microformats2 via the parser that would break? What would indieweb comments parsers do? - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
*** The only breakage which might occur would be over-encoding of non e-* properties, but I’ll release this update as v0.2.0 and warn people about the changes. The worst thing which could happen is that some comments look a bit weird, as opposed to the current worst possible scenario of easy XSS attacks --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** We should also decide exactly which characters get encoded — just angle brackets, or quotes/ampersands as well? --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** I am not sure about this, it seems more like a helper function rather than a core feature of the parser. Personally I would like to store data as text and encode only when I am going to use and I known the format it is going to be use in. --[[User:GlennJones|Glenn Jones]] 9:54, 14 July 2013 (UTC)
***After the discussion on the indiewebcamp IRC with Barnaby Walters I now understand the XSS issue that this change is trying to address. A rogue author could include HTML with scripts to execute a XSS attack. These could be masked by switch prefixes i.e. p-* to e-* on a well use property. As the consumer does not see the prefix in the JSON output they have no idea if a property will content HTML or text. I will update my two parsers and the test suite --[[User:GlennJones|Glenn Jones]] 8:02, 17 July 2013 (UTC)
**So what about an author setting a property to e-* when it would normal be p-*, dt-* or u-* i.e.
<source lang=html4strict>
<div class="h-card"><p class="e-name"><script> alert('xss test') </script></p></div>
</source>
** per [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]], parsers should never automatically attempt to HTML-special-characters encode - as that would provide the client of the parser a false sense of security. It's *always* up to client code to escape any text being output to HTML *at the moment it is output to HTML* and never before, because they can never trust that any text from storage/elsewhere has for sure been escaped or not. - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** Should we not encode e-* as well and the consumer can decode at their own risk --[[User:GlennJones|Glenn Jones]] 18:42, 21 July 2013 (UTC)
*** No, never, per above point from [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** See [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] etherpad: https://etherpad.mozilla.org/microformats2parsing for more details on the resolution to this issue - and incorporate here (then move to resolved section below). - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
* Resolved by changes to the parsing spec: all properties are plaintext (non-HTML escaped), e-* properties result in a dictionary with <code>value</code> = plaintext version, <code>html</code> = raw HTML version
----

</div>

=== br hr empty string ===
<div class="discussion">
* The parsing rule 'else if br.p-x or hr.p-x, then return "" (empty string)' for p-* can cause any code consuming the API to become quite bloated. It means that you have test every array value to see if its an empty string. It is also unclear to me what the purpose of this mark-up pattern is for [[User:GlennJones|Glenn Jones]]
** Upon reconsidering this, I agree with you, this is an unlikely use case. If a publisher wants to explicitly set an empty property "p-foo" they can simply write <code><span class="p-foo"></span></code> which looks explicit. Whereas BR and HR tags are often just presentational, so we should both not encourage usage of them for semantics, and anyone that did use them would be subject to likely loss of semantics upon a redesign (that got rid of those particular BR and HR tags). I'm going to remove them from the parsing spec. - [[User:Tantek|Tantek]] 15:29, 10 February 2013 (UTC)
</div>

=== datetime examples without T delimiter ===
<div class="discussion">
* The examples in the wiki microformats-2 pages such h-entry and h-entry had datetime without the 'T' delimiter between date and time. ie
<source lang="html4strict">
<time class="dt-published" datetime="2013-06-13 12:00:00">13<sup>th</sup> June 2013</time>
</source>
I have updated the pages. As far as I known this is a new pattern for dates. Was it a mistake in the examples or is it a new datetime pattern.
** The [[HTML5]] "time" element, and "datetime" attribute allow for space <span style="white-space:nowrap">" "</span> as a separator between date and time as well as "T", thus we allow it for microformats as well. The <span style="white-space:nowrap">" "</span> separator is preferred as the date and time are more readable when separated by a space. The examples noted in those specs deliberately use this. - [[User:Tantek|Tantek]] 18:48, 15 July 2013 (UTC)
</div>

=== rel-alternate absent optional attributes ===
<div class="discussion">
* What should rel-alternate parsing do when one of the optional attributes specified (<kbd>hreflang</kbd> or <kbd>media</kbd> or both) is not there? The options seem to be:
*# leave the corresponding key out of the alternate JSON object
*#* This one. Leave the corresponding key out.
*# include the corresponding key in the alternate JSON object, but set the value to the JSON null object
*# include the corresponding key in the alternate JSON object, but set the value to a blank string
*# something I haven't thought of

I haven't checked the existing implementations, but Barnaby said he's not sure what the appropriate way to deal with it is either. —[[User:TomMorris|Tom Morris]] 15:41, 9 August 2013 (UTC)
</div>

=== rel-alternate and type attribute ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Should rel-alternate parsing also pick up the <code>type</code> attribute? It’s fairly widely used, e.g. for ATOM feeds.
** Numerous existing sites/pages have various [[rel-alternate]] uses with a type attribute for feeds/APIs so that's good enough to add this for help with discovery in general. Rel parsing updated. - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
</div>

=== Extraction vs Interpretation ===
Issue raised by: [[User:BenWard|Ben Ward]]

A microformats ‘1.0’ parser performs the following function:

* Given a piece of HTML content, discover a known microformat, extract it, apply various extraction patterns based upon the HTML mark-up used (e.g. include pattern, <code>abbr</code> patterns, date-time patterns, value-title pattern), apply various content optimisations where applicable, and return the result in an object native to the programming language.

This is performing two types of function: Extraction of data from an HTML document or fragment, ''and'' interpretation and optimisation of that content to match the rules set out by a vocabulary specification.

It is only possible to write a generic parser that covers the first half of this task: Extraction, and application of global rules based on HTML elements and patterns common to all formats.

The purpose of a generic parser (as supported by use cases such as search engines, and other crawlers) is:

To provide a way for tools to extract rich data from a page for native storage, such that the data may be interpreted later by applications. This allows microformats to be crawled, and indexed, and removes the need to include complex HTML parsing within every implementation of microformat data.

Microformats will continue to define various vocabulary-specific optimisations. as part of the design to be optimised for authors. For example: The <code>fn</code> pattern in [[hcard]], or the <code>lat;long</code> pattern in [[geo]], as well as default values for properties, such as the maximum rating in an [[hreview]].
* Actually, no, as it is defined currently, microformats 2 ''drops'' vocabulary-specific optimizations. Such optimizations have often been too inapplicable, error prone or i18n-unsafe (e.g. fn to given-name + family-name fails for both numerous cases where middlenames/initials are used, and in general in numerous Asian languages where given/family name order is the reverse of Western English conventions, or languages with multiple family-names, e.g. Spanish - see [[hcard-issues-resolved]] for more). This is a deliberate cutting of a "feature" from microformats 1, it is a deliberate model simplification design decision. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

==== Extraction resolution ====
Proposed resolution:

Microformats2 should refer only to ''extraction'' of microformats. Vocabularies should in turn document their appropriate optimisations, which will need to be applied by implementations, or a companion to an extractor, which I'll refer to here as an ‘interpreter’.
* Vocabularies will no longer have optimizations, this is again deliberately, as they've been shown to be more error prone than helpful. Thus there should be no need for any vocabulary-specific 'interpreters'. However, due to design quirks in various legacy/interchange formats, ''export conversions algorithms'' to those legacy/interchange formats will require some additional legacy-format-specific rules (e.g. odd "required" rules in [[Atom]] or [[vCard]] will require specific synthesis rules, limitations in said formats will require filtering of some values, e.g. [[vcard3]] BDAY disallows vague birthdays like year-month and --month-day - subsequently allowed in [[vcard4]]). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

A microformats2 ‘extractor’, in combination with the functionality of a domain and format-aware ‘interpreter’ (either another shared component, or part of the implementation itself) would be equivalent to a microformats 1.0 ‘parser.’
* A microformats2 parser is both generic (no knowledge of specific vocabularies), and lacks any/all such vocabulary-specific rules as compared to a microformats 1.0 [[hcard-parsing|parser]] with the exception of a 1) a limited list of well-established/interoperable backward compat root class names (of current [[microformats]] that are or can be soon shown to be specifications/standards per the [[process]]), 2) flat sets of backward compat property names (some with prefix/name specific conversion) for each of those backward compat root class names. This is a deliberate design decision that makes microformats 2 more "micro", and yes this means that even with such backward compat support, this simple form of backward compat may mean that some existing microformats 1 content breaks. We'll assess those and iterate on a documented case-by-case basis rather than attempt to maintain theoretical 100% backward compatibility (since many current microformats format-specific-features are either unused, or may have caused more problems than solutions). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

N.B. I'll rewrite some of these as [[microformats2-parsing-faq]] to help better clarify. The reasoning that led to most of these design decisions is documented in the [[microformats-2#About_This_Brainstorm|microformats 2: About This Brainstorm]] section and following sections. I'll recheck those sections to see if/where reasoning for some of the above noted design decisions may have been missed, and back-fill accordingly. This is necessary because [[microformats2]] is a evolutionary result of simultaneously addressing both numerous generic [[issues]] as well as various common [[hcard-issues-resolved|format]]-[[hcalendar-issues-resolved|specific]] [[mfo|problems]] in microformats1 syntax and vocabularies. The very number of changes may make it more challenging (from a microformats1 perspective) to see why any particular design change has been made. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

This issue can be moved from resolved to closed once the above-mentioned write-ups have occurred.

===Parsing properties from rel attributes===
tl;dr resolution: As of 2013, [[microformats2-parsing]] handles parsing all link and a href rel values at document scope level, and producing canonical JSON accordingly. - [[User:Tantek|Tantek]]

Issue raised by [[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC):

* Currently, hAtom parses `bookmark` as a permalink
* Various microformats parse `rel=tag` as tags
* The current proposal for parsing does not allow parsing properties from rel attributes.

Microformats parsers could instead extract ''all'' link relationships from rel attributes within an microformat object, parsing them as if a u- prefixed property.
* Minor nit: Rather than same as a u- prefixed property, I think such "rel" properties should be parsed purely from the <code>href</code> attribute on <code><a></code> and <code><area></code> elements and nothing more. I would strongly disagree to extending rel to apply to other elements with URLs like img src, object data, or to apply to elements in general like div. That's the path that RDFa has taken and caused much confusion as a result. [[User:Tantek|Tantek]] 07:39, 5 October 2011 (UTC)
** Agree: That seems like a perfectly reasonable restriction. --[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)

This results in:

* Continuing use of the <code>rel</code> attribute in HTML, thereby building on HTML semantics rather than bypassing them or ignoring them in favour of something less meaningful.
* Parsing hAtom objects contain a property named <code>bookmark</code>, in place of <code>permalink</code>.
* All microformats that use <code>rel-tag</code> would contain a property named… <code>tag</code>. Perfect.

Since <code>rel</code> attributes are not overloaded for other functionality like class is, and other uses of <code>rel</code> within content are low (and non-semantic uses are nil, to the best of my knowledge) the risk of property pollution would be extremely low.

Note, with regard to this last point, that a generic microformats parser ''will'' parse false-positive properties, and ''will'' parse objects in combined chunks, rather than individually by format. Extracted objects will often not represent a vocabulary without further processing.

<div class="discussion">
* This sounds like it might be workable. Let's try it and see how well authors "get it". - [[User:Tantek|Tantek]]
* Possible issue: do we have any collisions between class property names and rel names? (I don't think so offhand, but useful to ask the question). - [[User:Tantek|Tantek]]
** None that I can think of in microformats. There is the case of Google's <code>rel=author</code> and <code>p-author</code> in hAtom. However, the next point, about mfo scoping, would cover it in most situations (rel-author on a hyperlink within an hcard wouldn't be applied to the hentry.) The one situation in a parse tree where it's ambiguous would be this:
<source lang=html4strict>
<a href="p-author h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
** I can think of two quite reasonable solutions:
*** 1. Declare that class properties take precedence over rel properties of the same name, discarding rel values if a class is also found, or
*** 2. Since all properties are now multi-value anyway, the hAtom object could be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
** —[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)
*** Option 2 makes sense and is consistent with the rest of the multi-value parsing/handling. - [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
*** What about without the 'p-author'?
<source lang=html4strict>
<a href="h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
Should that be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
Or
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': 'http://benward.me' /* from the rel="author" */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},

],
…
}
}
</source>
*** And if the former, then we're presumably saying that the value parsed due to the presence of a rel is always its own value, and does not combine with any other structures. I am fine with this, but I wanted to make sure we are ok with that explicitly. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
**** +1 I think that since the rel attribute is specifically concerned with the relation to an href attribute, it should not be combined with other structures that are rightly declared uses classes.
***** The more I've thought about this and how consuming applications may want to treat rel semantics, the more it seems correct to keep rel semantics distinct from class semantics. Class semantics are quite general/flexible, whereas rel is quite specific, naming something else in terms of a relationship from the current page/microformat's perspective. I think we should consider putting rel values in their own 'rel' collection, separate from the 'properties' collection. E.g. the original rel-author p-author h-card markup example would be parsed into this:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
}
],
…
}
'rel': {
'author': ['http://benward.me'] /* from the rel="author" */
}
}
</source>
***** and if a post had multiple authors:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from p-author */
'type': ['h-card'], /* from h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
{
'value': ['Tantek Çelik'], /* from 2nd p-author */
'type': ['h-card'], /* from 2nd h-card ... */
'properties': {
'name': ['Tantek Çelik'],
'url': ['http://tantek.com']
},
],
…
}
'rel': {
'author': [
'http://benward.me', /* from rel="author" */
'http://tantek.com' /* from 2nd rel="author" */
]
}
}
</source>
***** This preserves the semantic distinction between rel and properties in general, and leaves it up to a higher-level application to implement any logic around showing "more info" about a rel-author, e.g. by correlating the rel-author URL with the 'url' of an hCard it found in the same entry. However, note that even in the earlier JSON data model, the rel-author value just shows up as another property value, and any higher level application would still have to do some correlation logic. At least with this JSON data model, applications that may be looking for a rel value in particular, or a property value in particular can do so without having one unintentionally pollute the other. [[User:Tantek|Tantek]] 17:33, 6 October 2011 (UTC)

* Presumably we'd apply all the same property scoping rules to rel scoping as well. E.g. a rel hyperlink inside a microformat won't be seen by any containing microformat. - [[User:Tantek|Tantek]]
** Correct, it should be parsed in the same scope as all other class properties in the object.
*** Update: all rel microformats are now parsed at page-scope. Per-microformat scoping of rel has been found to be too confusing in practice (and against the general semantic of rel expressed in the HTML/HTML5 specs) [[User:Tantek|Tantek]] 01:00, 10 July 2014 (UTC)

This issue can be moved from resolved to closed once we've verified that all the above-mentioned and implied needs to write things up have occurred.
</div>

=== deduping of rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-02 by [[User:Kevin Marks|Kevin Marks]]
* 2015-06-05 resolved by consensus and one real world implementation proof of implementability and verification of expected results. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

Many sites have multiple duplicate rel links to the same url - a very common case is WordPress home pages eg [http://ma.tt ma.tt]

Each post on the page has a block like
<code><pre>
<div class="entry-meta">
<span class="date">
<a href="http://ma.tt/2015/05/beethoven-mozart-bach/"
title="Permalink to Beethoven, Mozart, Bach" rel="bookmark">
<time class="entry-date" datetime="2015-05-31T22:42:00+00:00">May 31, 2015</time></a></span>
<span class="categories-links">
<a href="http://ma.tt/category/asides/" rel="category tag">Asides</a></span>
<span class="author vcard">
<a class="url fn n" href="http://ma.tt/author/saxmatt/"
title="View all posts by Matt" rel="author">Matt</a></span>
</div></pre></code>

As currently defined, the parser will create duplicate entries in <code>rels</code> for each post:
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/",
"https://ma.tt/"
],
}
</pre></code>

and in the <code>rel-urls</code> we will also see:
<code><pre>
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author",
"author",
"author",
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home",
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag",
"category",
"tag",
"category",
"tag",
"category",
"tag"
],
"text": "Asides"
}
</pre></code>
These duplicates are unhelpful for parser consumers. We should:
* make them both sets - only listing distinct values. This will remove ordering information, but order is irrelevant for rel in html.
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/"
],
}
…
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag"
],
"text": "Asides"
}
</pre></code>

* possibly we could also make <code>title</code> <code>text</code> <code>type</code> sets too. That would solve the information loss issue with the current parsers
** Resolution: in the case of duplicate other attributes, first one set wins. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

<div class="discussion">
* +1 as the proposer. A version of mf2py that does this is running at unmung,com. see [http://www.unmung.com/mf2?url=https%3A%2F%2Fma.tt&html=&pretty=on fro ma.tt] or [http://www.unmung.com/?html=%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E&pretty=on a simple test] [[User:Kevin Marks|Kevin Marks]] 23:49, 2 June 2015 (UTC)
* +1 makes sense to me, and not having them be sets in the current spec is likely an oversight on my part. Thanks for noting this issue. [[User:Tantek|Tantek]] 05:28, 3 June 2015 (UTC)
</div>

=== include alternates in rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 resolved per consensus and one real world implementation proof of implementability. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* add "alternate" rels to the "rels" collection to make them easier to look-up in "rel-urls" - that is, all rel values end up in "rels" collections. No exceptions.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls".
* +1 This makes sense to me, as the <code>rels</code> and <code>rel-urls</code> should match so you can lookup in rels first, then get details about urls from rel-urls. We can drop "alternates" independently from this change. [[User:Kevin Marks|Kevin Marks]] 00:23, 2 June 2015 (UTC)
** +1 drop "alternates" independently now made a separate issue. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
* +1 Makes sense. And I agree with Kevin; I think parsers should deprecate "alternates" for now and drop it after a version cycle or two. [[User:Kylewm|Kylewm]] 00:30, 2 June 2015 (UTC)
* implemented in [https://github.com/kevinmarks/mf2py/commit/4dba45200eef11da811f64817d02044ab9e98b77 my fork of mf2py] and running on [http://www.unmung.com/?html=%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fa%22%3Eauthor+a%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fb%22%3Eauthor+b%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F1%22%3Epost+1%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F2%22%3Epost+2%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22alternate+home%22%0D%0A+++href%3D%22http%3A%2F%2Fexample.com%2Ffr%22%0D%0A+++media%3D%22handheld%22%0D%0A+++hreflang%3D%22fr%22%3EFrench+mobile+homepage%3C%2Fa%3E&pretty=on unmung] [[User:Kevin Marks|Kevin Marks]] 01:29, 2 June 2015 (UTC)
</div>

=== Empty properties overridden by implied rules against user expectation ===
Status: resolved, existing behavior correct, no changes to parsing spec.

2015-07-03: raised by [[User:Glenn Jones|Glenn Jones]]

Emma Kuo brought up an issue (https://github.com/glennjones/microformat-node/issues/22) based on following the indieweb note pattern, where the content of a note is given both the e-content and p-name classes. If the element containing the notes only has none text content like image the p-name can have unexpected value. Here is the example she gave:

<code><pre>
<div class="h-entry">
<a href="http://this.site/photo" class="u-url"></a>
<div class="e-content p-name"><img src="photo.jpg" class="u-photo"/></div>
Some extraneous text
<div class="h-cite">
<a href="http://someother.site/like" class="u-url"></a>
<a href="http://this.site/photo" class="u-like-of"></a>
<div class="e-content p-name">liked this</div>
</div>
</div>
</pre></code>

At the moment I parser this as follows: - if a property (p-name) is empty do not add it to the output. In this case "empty" is classed as not containing any non-whitespace text. As far as I known there is no guidance on how to handle "empty" properties in microformats paring rules, so I followed the conventions of JSON API's not to return "empty" properties.

The side effect of the above is that p-name also has a number of "implied rules". The "implied rules" try to automatically fill properties like p-name if there is no defined value. In the example above it uses the textContent of the parent h-entry, so value of the h-entry>p-name is the text content of the h-cite i.e. "likes this".

Options:

1. We should not allow the "implied name rule" to get textContent from within a child h-*
<div class="discussion">
* <strike>+1 I believe this is inline with how we parse properties and will meet user/author expectations [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* -1 A nested h-* is still part of the content of the parent h-*, I don't quite understand the rationale for excluding it. For example, I may include lots of h-cards in the body of a post that references people and wouldn't want them to be excluded from the implied name generation. [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* -1 I'm not sure this would solve the problem because auto-filled text could come from the parent h-* ("some extraneous text" in the example above) [[User:emmak|Emma Kuo]] 20:50, 4 July 2015 (UTC)
* -1 I agree with the other -1s. This would break some of the simplicity of the model. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
</div>
2. We should not execute the "implied rules" where there is an author defined "empty" property.
<div class="discussion">
* <strike>-1 Although the output would meet author expectations it is complex for parsers as they will have to keep state for each property through the whole series of parsing rules. [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* +1 An explicit, empty, p-name property should prevent an implicit p-name from being generated. For example tantek.com includes <span class="p-name"></span> at the start of the h-feed to prevent a giant name from being auto-generated. From my reading of the parsing spec, I don't see any reason that blank strings should be excluded from parsing. (mf2py and php-mf2 will both happily include empty strings in their output) [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* +1 We already have interop on this between mf2py and phpmf2, as well as people depending on it to explicitly set empty property values. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
* +1 As we already have interop with two parsers and solid user issue from Emma we should take this approach. [[User:GlennJones|Glenn Jones]] 11:51, 29 July 2015 (UTC)</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== uf2 children inside a classic microformats root class name ===
Status: incorporated into [[microformats2-parsing]]

2015-020: (raised by kylewm) What should microformats2 children inside a classic microformats root class name do?

Options:

1. Nothing. Any unattached uf2 children inside a classic microformats root are ignored. Problems:
<div class="discussion">
* However then there's a possible surprise if/when the author upgrades the classic microformats root to uf2, then all of a sudden all the new uf2 children show-up.
* Another downside: author adds uf2 markup, can't figure out why nothing is happening (because somewhere up the tree in code they didn't touch is classic microformats that are hiding these unattached uf2 children.
</div>
2. Show up in the children collection of the classic microformats root
<div class="discussion">
* Feels most predictable. When you add uf2 root class names anywhere, they will show up in the JSON output hierarchy.
* When you convert ancestor class microformats root class names to uf2 root class names, no surprise in terms of which microformats show up. Same children collection.
* +1 Thus I'm leaning towards this one, despite the fact that classic microformats never had a concept of generic unattached children. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)
* +1 I think this is the best option I will implement it and update the wiki once its in the JavaScript parser. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>
3. Show up as peers to the classic microformats root. Issue(s)
<div class="discussion">
* Has ths surprise aspect of if/when you convert the classic root class name to a uf2 root class name, the former peers become unattached children.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== any h- root class name overrides and stops backcompat root ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: The presence of any h-* root class name overrides and stop any backcompat parsing of classic microformats root class names on that same element. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for restricting backcompat root class name to only seeing backcompat property class names
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
* I don't think I understand this rule. If I was stop all parsing of of classic microformats in the presence of any h-* root in a document then some of the other rules such as "uf2 children inside a classic microformats root class name" do not make sense. Could this item be expanded and explained a bit more? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** added "on that same element" as that was what we were discussing/implying in this issue. [[User:Tantek|Tantek]] 22:49, 18 September 2015 (UTC)
</div>

=== backcompat classic microformats should only see backcompat properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats vocabulary that indicates a backcompat root class name (and thus an absence of the microformats2 equivalent on the same element), parsers must only look for the backcompat properties that are specified explicitly for that backcompat root class.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such behaviour was never expected by authors, and crossing a classic microformats root class name with microformats2 property names were never explicitly expected nor specified to work.

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== microformats2 root class names should only see microformats2 properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats2 root class name, only explicit microformats2 properties should be parsed. Any backcompat property names must be ignored.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such microformats2 authors should be expected to do all their microformats markup with microformats2 class names - this is a deliberate expectation so that their microformats aren't polluted with other (classic microformats) coincidentally named generic class names.

Thoughts?
<div class="discussion">
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== implied properties on backcompat parsing unlikely to be intended ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
Since classic microformats had no notion of implied properties, when implied property parsing occurs on backward compat classic microformats root class names, it is unlikely that any implied property (p-name u-url u-photo) was ever intended by the author of the classic microformat. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
Examples:
* see https://indiewebcamp.com/h-entry#bad_hentry_properties for a growing list

'''Proposed resolution:'''

* Be explicit in implied property parsing that it must only be done for explicit 'h-*' root class name microformats, not for any (back)compat parsing of microformats. Please comment on this proposal with "** comment" on new lines below. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
** +1 This makes a lot of sense to me. We should strive to parse mf1 as it was intended by the author, and I think you're right that implied rules are unlikely to be what was intended [[User:Kylewm|Kylewm]] 03:22, 30 December 2014 (UTC)
** +1 I think this will help backcompat parsing, but there are two major things to consider. It may well break some consumer code as the output for a microformats currently always has the name property, there may not be the defences code to check this is true when we remove the implied name rule for classic microformats. The test suite will also need major updating as all the test output for classic microformats will have. I will look into implementing this and report back to the wiki. [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** Also it should be made clear that we are only removing the implied rules from classic microformats parsing and not the value property? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
*** The "parsing for implied properties" section only references name, photo, url properties. Where (in the spec) is the confusion about "value" coming from? [[User:Tantek|Tantek]]
** RESOLVED at [[2015-01-20]] meetup. [[User:Tantek|Tantek]] 04:09, 21 January 2015 (UTC)
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Set implied properties by microformat version"

=== link elements and u- parsing ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Raised by tantek on 2014-07-08 on [http://logs.glob.uno/?c=freenode%23microformats&s=8+Jul+2014&e=9+Jul+2014#c72916 irc]: should the parsing specification for handling u- properties be modified to include the <code>link</code> element? The potential downside is that [[invisible-metadata-is-considered-harmful]], however all known real world examples of <code>link</code> are <em>semi-</em>visible data (not fully hidden).

There are potential cases for wanting to use link as an alternative to <code>a</code> (and <code>area</code>), such as a whole page where the root <code>html</code> element is an <code>h-card</code> and the properties are included across the page: some in visible data in the <code>body</code> while others are in the <code>head</code> as <code>link</code> elements. Example:

One specific use-case is the semi-visible <code>link rel="shortcut icon" href="..."</code> - which is visible sometimes in browser UI, and also when a user chooses "Add to Home Screen" on a mobile device. Such page level icons may be used as a <code>u-photo</code> or <code>u-logo</code> of the containing <code>h-*</code> object on the <code>html</code> element.
* http://adactio.com/about/myself/ on 2014-190
** <em>could</em> use <code><html class=h-card></code> - page is all about Jeremy Keith the person
** <em>icon / logo is only</em> on <code><link></code> tag which <em>could</em> use <code>class=u-logo</code>: <br/><code><link rel="shortcut icon apple-touch-icon" type="image/png" href="/icon.png" /></code>

Another specific use-case is a post permalink page, e.g. with <code><html class=h-entry></code>
* http://waterpigs.co.uk/notes/4WjHpC/
** <em>has</em> <code><html class="no-js h-entry hentry h-as-note" lang="en"></code>

Another use-case is publishing links to PGP/GPG keys linked from the head which is currently handled by <code><link rel=pgpkey></code> which is already supported in existing [[microformats2-parsing#parse_a_hyperlink_element_for_rel_microformats|microformats2 rel parsing]] of <code>link rel</code> elements. Thus there is a (admittedly weak) argument for consistently parsing <em>both</em> <code><link rel></code> <em>and</em> <code><link class="u-*"></code>.

E.g. inside that aforementioned real world <code><html class=h-entry></code> post permalink page example,
* why should <code><link rel="in-reply-to"></code> work
* but not <code><link class="u-in-reply-to"></code> ?
The slightly stronger argument for consistency of link handling is that it <strong>[[simpler|simplifies]]</strong> the publisher (and parser) model:
* <code><a></code> and <code><area></code> work for both <code>rel</code> and <code>class</code>
* why does <code><link></code> only work for <code>rel</code> ?
* it would be <em>simpler</em> if all three tags just worked (in the same way) for both <code>rel</code> and <code>class</code>

'''Should the parsing spec be modified to handle these cases?''' —[[User:TomMorris|Tom Morris]] 09:25, 9 July 2014 (UTC)

** I'm generally in favour. It'd be good to see what other parser developers think. —[[User:TomMorris|Tom Morris]] 10:16, 9 July 2014 (UTC)
** adding this to the parsers won't be an issue. <del datetime="2014-07-09T18:45">The question is should the door be opened to hidden mf data?</del> <ins datetime="2014-07-09T18:45">Up on further reflection, there seems to be no need to distinguish between <code>rel=property</code> and <code>class=u-property</code> on link elements. So I am in favour for consistency.</ins> [[User:KP|Kartik]] 18:30, 2014-07-09 (EST)
** RESOLVED at [[2015-01-20]] meetup. Make link consistent with a.
</div>

=== drop alternates collection ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 split into separate issue from include alternates in rels per implementation feedback from Kevin Marks. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* drop "alternates" as its no longer needed, and all current consuming code clients like rel-urls better anyway.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls" in original issue now "include alternates in rels", we no longer need "alternates", and those with client consuming code have universally indicated that they would rather use rel-urls anyway. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
</div>

== see also ==
* [[microformats2-parsing]]
* [[microformats2]]

microformats2-parsing-issues

2016-03-13T21:03:31Z

Barnabywalters: /* Noscript skip/parse */

This page is for documenting issues with the [[microformats2-parsing]] specification.

== issues ==
Open issues in various states of partial resolution from none to nearly resolved.

=== ignore u-camelCase properties ===
Due to Suit CSS (and others? citations?) recent (2015-?) use of "u-*" class names for so-called "[http://davidtheclark.com/on-utility-classes/ utility classes]", we are seeing some false positives in a few very rare instances, e.g.: http://www.unmung.com/mf2?url=http%3A%2F%2Fwww.kevinmarks.com%2Ftwitterutils.html&html=&pretty=on

(Nearly) all these "utility classes" use camelCase for the class name suffixes, thus we can filter them out by looking for camelCase (since microformats class name conventions are always all lowercase and hyphenated), or even just looking for (and rejecting) *any* capital letters.

Proposal:
* microformats2 parsers MUST IGNORE u-* classnames where the * has any uppercase letter(s).

<div class="discussion">
* +1 [[User:Tantek|Tantek]] Let's get this fix rolling quickly to avoid further pollution.
* +1 [[User:Barnabywalters|Barnaby]] php-mf2 already ignores classnames with capitalised prefixes, ignoring any classnames with capital letters seems totally reasonable
* ...
</div>

=== exclude style elements before parsing ===
[http://logs.glob.uno/?c=freenode%23microformats#c85457 2016-01-25 raised in #microformats]

Ran into an issue of a <style> element being parsed as plain text in a p-name. Should [[microformats2-parsing]] be updated to indicate <style> should be excluded when parsing? Appears to implicitly fall under [[microformats2-parsing#note_HTML_parsing_rules]]

Sample link: http://veganstraightedge.com/notes/2016/01/16/tonight-s-dinner-tacocleanse-beverly-hills-c

The <script> tag can be similarly problematic.

Proposal: Drop both <script> and <style> elements completely when parsing any property (including e-* HTML values). [[User:Tantek|Tantek]] 01:01, 29 February 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Aaronpk|aaronpk]] as a consumer of HTML from an e-* property, I will always be sanitizing the HTML and removing <script> and <style> anyway
* +1 [[User:Kylewm|kylewm]]
* 0 [[User:Barnabywalters|Barnaby]] +1 to removing the contents of <script> and <style> from all plaintext properties (and 'value' property in HTML dicts), -1 to removing <script> and <style> from HTML. That’s a job for a sanitization stage. As aaronpk points out, sanitization will have to be done anyway if the content is to be reposted, so doing so in the parser doesn’t actually save anyone any work, but removes information which could be useful to people (example use cases: publishing posts with embedded per-post styling, publishing interactive HTML documents with embedded javascript)
** +1 this seems like reasonable feedback to make a new refined proposal. [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)
</div>

Proposal 2: Drop both <script> and <style> elements completely when parsing any property (except for e-* HTML values, which preserve all markup). [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Barnabywalters|Barnaby]
* ...
</div>

=== use poster if no src on video for u props ===
[https://indiewebcamp.com/irc/2015-12-13#t1450035721661 2015-12-13 raised in #indiewebcamp]

There is a use-case of marking up the "poster" of a video element as the u-featured of an [[h-entry]], to do that, we need to change [[microformats2-parsing#parsing_a_u-_property|u- property parsing]] to look at the poster attribute of the video element, after it's looked for the src attribute.
<blockquote>" else if video.u-x[poster], then get the poster attribute "</blockquote>

Real-world example of markup in the wild:
* http://veganstraightedge.com/videos/2013/5/31/1/backyard-squirrel-buddy
** and likely all other videos posted there.

Background discussion that led to this proposal:
* https://indiewebcamp.com/irc/2015-12-13#t1450035721661

This seems very straightforward so I've added it as PROPOSED directly in the parsing spec. This issue is for tracking the discussion.

Feedback from parser implementers please!
<div class="discussion">
* +1 [[User:Barnabywalters|Barnaby]] easy to implement and based on real-world markup, no objections
* ...
</div>

=== uf2 children on backcompat properties ===
[http://logs.glob.uno/?c=freenode%23microformats&s=today#c84632 2015-11-24 raised by Calli] in #microformats

Related but different from [[#uf2_children_inside_a_classic_microformats_root_class_name]], when there is a uf2 child directly on a backcompat property, what should happen? E.g.

<source lang=html4strict>
<div class="vcard">
<div class="adr h-adr">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

What is the expected behavior and parser output?

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-adr"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

<div class="discussion">
* Proposal: the nested "adr h-adr" child is treated as an mf2 object, not backcompat, and thus the resulting parsed "locality" property has a single value of "MF2". Proposed by Calli, noting that Glenn Jones's microformatshiv gets that result currently, and it would be easier for him (Calli) to implement this way.
** +1 Tantek, seems reasonable and the reasoning provided is good (we have one implementation this way already)
** +1 Kyle, this is consistent with the resolution to the related issue
** +1 Calli, yes, this is easier for me to implement (than taking both MF1 and MF2 properties) because it is consistent - for me, consistency is the controlling factor in favor rather than ease of parser implementation
** +1 Barnaby, php-mf2’s mf1 backcompat produces this exact result, and it makes a lot of sense to me
** ...
</div>

Another example:

<source lang=html4strict>
<div class="vcard">
<div class="adr h-custom">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-custom"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

Per the [[#any_h-_root_class_name_overrides_and_stops_backcompat_root]] resolution, the class name "h-custom" overrides the use of "adr" as a backcompat root.

=== default generated HTML ===
2015-09-08 raised by Tantek in #indiewebcamp

Should there be a default (perhaps not quite "canonical") way to map/generate HTML+microformats2 from a parsed mf2 JSON output?

E.g. straw proposal:
* JSON/mf2 -> [[XOXO]]+mf2

Existing work / mappings:
* https://github.com/snarfed/granary/blob/master/granary/microformats2.py#L295

Related to:
* https://github.com/snarfed/granary/issues/31

Use-cases:
* default webview / presentation for a site that stores mf2 JSON output
* possibly a way to implement a distributed HTTP webcache retrieval protocol

Thoughts?
<div class="discussion">
* +1 [[User:Tantek|Tantek]] I think we should have this, but am open to proposals on specifics!
* +1 [[User:GlennJones|Glenn]] Also think this is worth looking at, but I am not sure it should be part of the parser spec. Feels like it should be built as a separate library and have it own spec on the microformats wiki.
* +1 [[User:Barnabywalters|Barnaby]] agreed with Glenn, this would be a nice thing to have, but IMO it’s out of scope for the parser and should be specified separately. Personally I would probably implement it separately too, depending on how much work it is.
* ...
</div>

=== Noscript skip/parse ===
2015-07-28

Should mf parsers skip <code><noscript></code> tag in the HTML, like the <code><template></code> tag mentioned in http://microformats.org/wiki/microformats2-parsing#note_HTML_parsing_rules ?

mf2py skips <code><noscript></code> when using the html5lib DOM parser but no when using lxml parser. Example use of <code><noscript></code> https://kartikprabhu.com/ featured images have a no javascript fallback image inside <code><noscript></code> with <code>class='u-featured'</code> markup.
* html5lib actually HTML-escapes the contents of <code><noscript></code>, so to mf2py it just looks like plain text with no tags. In Woodwind, I've resorted to using regex to strip out <code><noscript></code> tags before parsing (very hacky). [[User:Kylewm|Kylewm]] 15:52, 25 August 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] skip noscript (and inside) because in today's typical browsing contexts, nothing in noscript is displayed, thus we should discourage marking up effectively invisible content.
** Proposed change to [[microformats2-parsing#parse_a_document_for_microformats]]:
*** from: "follow the HTML parsing rules"
*** to: "follow the HTML parsing rules (including skipping/omitting <code><noscript></code> elements, e.g. like the html5lib DOM parser)
* -1 [[User:GlennJones|Glenn]] This subject does need to be address, but differently to proposed change. My personal view is that e-* html should be passed through raw and then the consumer can process it in a way they feel fit. Its a case for helper libraries. I am about to build a helper library to do this based on the Readability code to post process e-* html. Other people may want to take different approaches, defining this in the spec feels like move into a whole area of new functionally.
* 0 [[User:Barnabywalters|Barnaby]] to me this should be treated the same as the script/style contents — removed completely from all plaintext properties, but left unaltered in raw HTML.

As a separate new point we need to consider "exclude tags" lists for parsed text from html. We should consider <code><noscript></code>, <code><noframe></code> and <code><template></code> there maybe other I have not gone through all the tags in current HTML spec. Also we should consider what to do about the more common pattern of fallback text within media tags <code><video></code>, <code><audio></code> etc. This should be explicitly discussed in the parsing rules. At the moment my experimental text normalisation does exclude tags, but the default text parse does not. Currently the fallback content in media tags like <code><video></code> is added to the parse text. 12:56, 25 Septemeber 2015 (UTC)
* [[User:Barnabywalters|Barnaby]] in theory, as the video and audio data by default can’t be included in plaintext properties, and the fallback content (much like img alt attributes) should be somehow human-readable and useful, I would suggest keeping it in plaintext properties. I’d like to see some real-world examples of what fallback content people are using — if it’s links or plaintext descriptions this approach could work well, if people are writing instructions saying “install flash” or “update your browser” it’s not going to produce very pretty results
* ...
</div>

=== Standard datetime format ===
2015-07-28

http://microformats.org/wiki/microformats2-parsing#parsing_a_dt-_property does not specify any standard format to use for datetimes. e.g. <pre>2015-07-28T12:55:33</pre> vs <pre>2015-07-28 12:55:33</pre>
Would be good to standardize this to compare various parser outputs.

2015-07-29: This subject is (somewhat) covered in http://microformats.org/wiki/iso-8601 As it stands the JavaScript parsers support output in the 3 main profiles, 'W3C Note', 'RFC 3339' and 'HTML5' plus 'auto' which keeps authors format. The default date output for the JavaScript parsers is the same format as the date was originally authored in. This can be changes by setting the options.dateFormat switch to any of the other profiles mentioned. It would be good if other parser also had a switch to force output to a common profiles so we could compare various parser outputs, but I think the default should be how a date was authored. All output whatever profile should also keeps the authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string. This is important if you want to compare parser outputs.

The only exception to this where date and times are combined such as the implied h-event rule for dt-start and dt-end where I output in the HTML5 style 2015-07-29 12:55:33 as there is no predefined author preference and HTML5 profile is more human readable. [[User:GlennJones|Glenn Jones]] 11:02, 29 July 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] output more human readable <code>2015-07-28 12:55:33</code> canonically, with authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string.
** Let's update any test cases as needed for this. - [[User:Tantek|Tantek]]
* ...
</div>

=== implied date for dt properties both mf2 and backcompat ===
The [[value-class-pattern#microformats2_parsers|value class pattern dt-* date proposal]] should apply to both mf2 dt-* properties, and backcompat classic microformats, to preserve the hAtom / hCalendar optimizations noted on that page, but in a generic way.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] 16:12, 18 August 2015 (UTC)
* +1 [[User:Glenn Jones|Glenn Jones]] 20 August 2015
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== implied properties when an explicit class is provided ===
<div class="discussion">
Should "u-url" still be implied if another explicit class is already provided, as below. This is a contrived example, but it is taken from Bridgy's unit tests.

<code><pre>
<article class="h-entry">
<a class="u-like-of" href="http://orig.domain/baz">liked this</a>
</article>
</pre></code>

In this case, http://orig.domain/baz is almost certainly not the u-url, so IMO it would be better to leave it out —[[User:Kylewm|Kylewm]] 15:10, 7 October 2014 (UTC)

'''2015-01-20 consensus'''
* Changed my mind. Simpler to do nothing. Example provided is artificially constructed, does not reflect likely real world confusion of if we make implied properties more complicated. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
* ++ Consensus on do nothing for this case. At [[2015-01-20]]

'''Proposed resolution:'''
* Changed again. Due to indiewebcamp.com/edit use-case, this now makes sense for all implied properties. That is:
** If an element has any explicit property class name(s) on it, then it must not be used to imply any properties. [[User:Tantek|Tantek]] 20:50, 27 May 2015 (UTC)
*** +1 this seems reasonable, if a publisher is going to add an mf2 class, it is unlikely they want other classes automatically implied from the same value [[User:Aaronpk|Aaronpk]] 23:19, 29 November 2015 (UTC)
*** -1 for now. To my knowledge, this has only been observed in artificially constructed unit tests and examples, and it adds some weird edge cases that are hard to reason about. [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** ... provide input on this proposal here
** Refined: Or should this be refined by per parsing prefix? [[User:Tantek|Tantek]] 22:59, 18 September 2015 (UTC)
*** Any explicit "p-*" property means no implied "p-name" from that element
*** Any explicit "u-*" property means no implied "u-url" nor "u-photo" from that element.
*** ... provide input on this refined proposal here
** Suggestion: split this issue up per property. I think it makes sense for u-url and can be easily added to the spec as e.g. ".h-x>a[href]:only-of-type:not[.h-*<strong>,.u-*</strong>]". [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** Obviously wrong to assume a link explicitly pointing elsewhere is our "url"
*** More difficult to make a case for photo and especially for name.
*** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
*** ... provide input on this refined proposal here
</div>

=== whitespace collapsing revisited ===
2015-05-27: (raised by [[User:Kevin Marks|Kevin Marks]] per Glenn Jones)

Revising the microformats tests to conform to the "don't collapse whitespace" rule below reveals some non-intuitive cases.
preserving whitespace in addresses is somewhat defensible, but in an implied name it is often unhelpful, as it preserves non-user visible space there for authoring reasons.

For example:
[https://github.com/microformats/tests/commit/a325e0e9bc2089507e69b1883f7065a3316e07c2#diff-d577012c1438978a571c4049179607f0 this test] shows how extraneous whitespace ends up in the <code>name</code>

<code><pre>
<div class="h-review-aggregate">
<div class="p-item h-event">
<h3 class="p-name">Fullfrontal</h3>
<p class="p-description">A one day JavaScript Conference held in Brighton</p>
<p><time class="dt-start" datetime="2012-11-09">9th November 2012</time></p>
</div>

<p class="p-rating">
<span class="p-average value">9.9</span> out of
<span class="p-best">10</span>
based on <span class="p-count">62</span> reviews
</p>
</div>
</pre></code>

give a parsed result of:

<code><pre>
{
"items": [{
"type": ["h-review-aggregate"],
"properties": {
"item": [{
"value": "Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012",
"type": ["h-event"],
"properties": {
"name": ["Fullfrontal"],
"description": ["A one day JavaScript Conference held in Brighton"],
"start": ["2012-11-09"]
}
}],
"rating": ["9.9"],
"average": ["9.9"],
"best": ["10"],
"count": ["62"],
"name": ["Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012\n\n\n9.9 out of \n 10 \n based on 62 reviews"]
}
}],
"rels": {}
}
</pre></code>

The <code>value</code> is a reasonable textual representation of the event, but the implied <code>name</code> is full of spurious whitespace that any consumer would have to strip.

[https://github.com/microformats/tests/commit/4c9690b53b0a2f40440abac8e609c51ac7dd6d56 h-review] has similar issues

2015-05-28: (Addition by [[User:GlennJones|Glenn Jones]])

The example below shows the type of markup most effected by the "implied name" and "don't collapse whitespace" rule working together to produce output that is hard to use without further processing.

<code><pre>
<a class="h-card" href="http://glennjones.net">
<span class="p-given-name">Glenn</span>
<span class="p-family-name">Jones</span>
</a>
</pre></code>

The output for the name property from the above HTML would be <code>Glenn\r\n Jones</code> using the (trim lead/trailing) suggested in the parsing spec. I could of course move the spans onto one line, but it feels fragile to consider whitespace sensitivity in HTML like this. Added to the fact that HTML templating environments often take away that level of whitespace control from authors anyway.

There are issues with both: keeping whitespace, returns and tabs from parsed HTML or collapse that whitespace. If we return the whitespace it becomes mal-formatted for humans because it was only added to make the HTML code understandable and in most cases was not meant to be used/read outside of that context. If we collapse the whitespace we can have issues of whitespace sensitive text from <code><pre></code> etc. being incorrectly formatted.

Providing a CSS aware innerText feature would produce the most useable output, but this is too complex/time consuming to build for most parser developers. In the face of no perfect solution I have taken the 80:20 view, whereby errant whitespace, causes me considerably more problems than mal-formatted <code><pre></code> content so I collapse whitespace on all text returned.

This feature is a non-CSS aware version of innerText. It does not cover all rendering edge cases, but enough to produce practical output.

For now, I have started changing the node parser to flag "white-space collapsing" as an experimental feature which is off by default i.e. http://glennjones.net/tools/microformats/ but personally I will parse everything with this on as I find it the most practical solution.

Not sure where that leaves me on the options below.

Options:

Choose from:
# keep as is and every parser client has to post process for common cases.
# '''keep as is but have mf2 parser trim leading/trailing whitespace (likely to provide desired result and be reasonably backcompat)'''
#* +1 my preference of the two options. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
#* +1 though this doesn't solve any of the problems discussed above, it's still worth doing [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
#* +1 will help parsers be more consistent with each other, and I haven't ever encountered a case where preserving leading/trailing whitespace was desirable [[User:Kylewm|Kylewm]] 20:45, 8 June 2015 (UTC)

2015-06-08 option 2 resolved by consensus and implementation in mf2py.

Somewhat orthogonal:
* make <code>value</code> on properties with children normalise whitespace
** -1 Seems like a bad idea as this "value" is supposed to be the same as if there was no embedded child microformat. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
* make implied <code>name</code> normalise whitespace.
** +0 This is reasonable and already done somewhat in the parsing spec (trim lead/trailing). [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** +1 Given the universality of name, this would fix most of the issues we see. [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
* Put \n in textual forms if there is a <code><p></code> tag in the original.
** -1 that's a long path to go down with whitespace equivalents for HTML markup. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** would only preserving whitespace if in <pre> be an 80:20 compromise? [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)

Because there are both code markup and specific vocabulary (label) needs for preserving whitespace, we are compelled to preserve in general, perhaps except for very specific limited generic cases (e.g. trim leading/trailing, "value" parsing, implied name). [[User:Tantek|Tantek]]

=== u- parsing iframe src ===
Currently if I put u-* on an iframe it gets the value of the fallback text. This seems a shame. Getting the URL seems a sensible answer.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== i- parsing iframe src ===

More controversially, what about using an iframe for transclusion? A use case here is comments on a static site. Currently, on eg http://www.kevinmarks.com/microformatschema.html the comments are injected via JS, making them opaque to parsers and thus precluding further parsing such as salmentions.

If instead they were an iframe embedding them, a parser could optionally fetch its contents, parse them, and include them in the parsed mf2 output at that point. Overloading u-* for this seems wrong; e-* as below for srcdoc would have a different effect; this implies a new prefix directive would be needed. A strawman i-* (for include) may work.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== e- parsing iframe srcdoc ===
<div class="discussion">
* Proposal: addition of a new e-* parsing rule for iframe elements with srcdoc attributes. E.G.

<source lang="html4strict">
<div class="h-entry">
<iframe class="e-content" srcdoc="<p>A paragraph of HTML with "quoted quotes" &amp; doubly quoted ampersands</p>" />
</div>
</source>
<source lang="javascript">
{
"items": [{
"type": ["h-entry"],
"properties": {
"content": ["<p>A paragraph of HTML with "quoted quotes" & doubly quoted ampersands</p>"]
}
}]
}
</source>

This would allow, for example, HTML comments to be sandboxed inside iframes but still parsable as microformats.

I believe the correct processing would be to leave " entities as they are but to unescape any doubly-escaped ampersands.

** Is there any use case for that? —[[User:TomMorris|Tom Morris]] 12:32, 14 September 2013 (UTC)
** +1 we need documentation of use case and existing sites publishing iframe srcdoc like this - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
** Rejected by consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 properties on select ===
How should select elements with properties be treated any differently?

Awaiting real world examples / stronger use-cases, until then no special treatment of select elements with properties:
<div class="discussion">
* Are there any real world examples of select elements with microformats properties?
* What would the use-case be for putting a microformats property class name on a select element?
* Nothing special. By consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 root name on form ===
See what to do about <em>root class names</em> on <code><form></code> elements in particular:
* [[hcard-input]]

Awaiting real world examples / stronger use-cases, until then, no special treatment of root class names on <code><form></code> elements:
<div class="discussion">
* Are there any real world examples of a <code><form></code> element with a microformats root class name?
* [[hcard-input]] is one possible use-case, is anyone attempting to use forms for hCard input, e.g. with scripts to help make it work?
* Are there other use-cases for putting a microformats root class name on a <code><form></code> element?
* As of [[2015-01-20]] - no consensus - need more input as to when/why this is useful to do anything special.
</div>

===Parsing Literal Values===
Issue raised by: [[User:BenWard|Ben Ward]]

It is proposed for microformats2 that all microformats be parsable from just their root element, e.g. <code><p class="h-card">Ben Ward</p></code> would create an hCard with the following properties after parsing:

<source lang=javascript>
{
'type': ['h-card'],
'properties': {
'name': ['Ben Ward']
}
}
</source>

This is a four-fold change from the current [[hCard]]:
# type is generically identifiable as a microformat root, even in parsed form. The use of the 'h-' prefix persists into the type of the object. This is deliberately so, as a result of re-using the JSON data model of microdata which itself is re-using a common JSON convention, such that microformatted data is clearly distinguishable (as opposed to any other random schema that may be using a similar data model).
# root-class-only support. Per [[microformats-2-implied-properties]], the ''name'' property is implied by the entirety of the root class name element.
# 'name' instead of 'fn'. As also documented in [[microformats-2-implied-properties]], the continuous challenges/problems and need to repeatedly re-explain 'fn' over the years combined with the real-world market response of nearly every other party doing a person vocabulary renaming 'fn' to 'name', microformats 2 makes this change as well.
# There is no automatic parse-time inferring of <code>'given-name': ['Ben']</code> and <code>'family-name': ['Ward']</code>. Any such inferring *might* be made by a vCard converter, but is left up to that specific application (not all applications) built on that vocabulary, though even in that case it may not be necessary, as an empty "N:;;;" [[vCard]] property is sufficient to satisfy the N property requirement of [[vCard]], and also causes no problems when imported into various [[vcard-implementations]].

It is required of the extractor to understand that when a microformats object specifies no explicit child properties, that it must treat <code>h-card</code> as having a <code>p-name</code>. But, the parser is generic, so it also treats <code>h-review</code>, <code>h-entry</code>, <code>h-recipe</code>, <code>h-geo</code> as having a ‘<code>p-name</code>’.

As a result, specific vocabularies are evolved to drop their specific form of name (e.g. fn, summary, entry-title) and simplified to use a common 'name' property instead.

Note: while the overwhelming majority of real world publishing/consuming uses of microformats do so with proper nouns which have names (and thus this parser-level incorporation of an implied 'name'), there are some formats that do not have a 'name' semantic. For example, [[geo]], [[adr]], and possibly if/when developed, units of measure, length, cost. The current thinking is that the benefits to the far greater proper-noun use-case of microformats outweigh the technical inelegance of having an extra/ignored 'name' property on formats that lack such a semantic.

Some formats also may appear in theory to better imply some other property, e.g. a review might be thought to imply its ''content'', not its name, and an Atom entry its ''content'', not its title, but in practice (actual publishing patterns) this is not the case. Typically, brief unstructured reviews (or mentions thereof) provide a ''summary'' (often hyperlinked to an expanded structured form) of that review, not its content, and similarly, brief unstructured posts (e.g. RSS items) have historically most often been link blog items which include the title of an item and a link. Short status updates as well established by Twitter are newer and would seem to imply purely content with no title, at least semantically, however, even Twitter populates the RSS title and ATOM entry title of their feeds with the content. It's not clear what went into that decision, however, that's likely irrelevant, as the outcome turns out to be emergent consistency among publishing behaviors.

To avoid overloading or undermining the semantics of a vocabulary, I propose that we handle this at the extractor level in a simpler fashion: Define a new property for literal data, that an extractor will provide if no other information was available. All ''interpreters'' may then be instructed that in the event that an object has no properties, it can attempt to interpret the literal value from the page instead.

* This was one of the design iterations I went through which led me to the current implied 'name' design. Another iteration was the ability for a vocabulary to specify a single required property which was implied if there were no properties provided. However, the combination of the fact that in most cases such single required properties were quite name-like, and that a vocabulary-specific rule like that would then bind parsers to specific vocabularies (even so slightly) led me to collapse them into implying a 'name'. It's not perfect, but it's the best alternative so far that balances practical convenience of publishing/consuming, avoids vocabulary-specific knowledge in the parser, and technical (in)elegance. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

In existing microformats, the closest existing example we have for this is the <code>label</code> property in hCard, which is used to represent the literal address label for a place. It is a corresponding piece of <code>fn</code>, <code>org</code> and <code>adr</code> in combination, but has no structure in and of itself. Possibly, every microformat could have a <code>label</code> form where structured data is unavailable.

However in practice, the hCard <code>label</code> property is both little understood and little used. It's not even clear that it ought to be kept for microformats 2 (no known consumers, very few (if any?) real-world non-test publishers). This disuse is likely a good indicator that we should avoid basing anything on its design.

Alternatively, <code>value</code> is used throughout microformats to target a generic value (e.g. in combination with <code>price</code> in hListing.) It has been proposed that when parsing properties that are also themselves microformats, we create native objects of the form:

{
'value': '1900 12th Street, San Francisco, CA 94'
, 'type': ['h-adr']
, 'properties': {
'street-address': '1900 12th Street'
, 'etc': 'etc'
}
}

We could apply this same pattern to the root level:

{
type: [h-card]
, properties: {}
, value: 'Ben Ward'
}

In this case, an interpreter or implementation is responsible for using <code>value</code> in place of <code>fn</code>, or restructuring the object. It would be the responsibility of each vocabulary to define its root property. The parsing layer of microformats 2.0 would not impose semantics or naming onto that.

For another example, h-geo would end up like this:

{
type: [h-geo]
, properties: {}
, value: '1.3232;-0.543'
}

* This is an alternative I've been considering as well: [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)
** 'value' is more generic than 'name' (applies to more vocabularies) with the trade-off that it naturally has less (weaker) semantics.
*** +1 I think that having naturally weaker semantics would be appropriate for this parsing functionality. —[[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC)
** The interesting thing that this analysis has revealed is that there appear to be two distinct clusters of microformats, the much more commonly used/understood/useful proper-noun microformats which markup things with names (people, events, reviews, recipes), and the less used compound-data microformats which are often used ''inside'' other microformats and just have some sort of semi-structured value (adr, geo, measure, and perhaps even things like tel). Perhaps this is implying the possibility and some degree of utility for ''two'' microformats root class name prefixes, 'h-' for existing proper-noun microformats, and something else ('m-' for microformat/molecule?, 's-' for structured-value?, 'v-' for value (though historically "v-"/"v." has meant "vendor-specific")?) for unnamed structured data microformats.
*** This more and more feels like a good idea, and I'm leaning toward "s-" for struct / structure / structured value. "s-" works just like "h-" except that it doesn't imply any properties at parse time. We can try it and see what happens. There's also no harm if publishers just use "h-" structures, they just (possibly) get a few extra properties if they happen to omit properties.
** Parallels the same JSON when a property has both a string value ''and'' is a structure itself.
*** Changed my mind on this. The parallel is not quite there. 'name'/'url'/'photo' are only implied if there are NO properties, where as the JSON string value + structure convention *always* provides a 'value'. [[User:Tantek|Tantek]] 22:39, 4 October 2011 (UTC)
*** And due to this difference in behavior ('value' is there when nested properties are present, whereas 'name' is only implied when there are no properties specified), I think it's correct to keep them separate, i.e. stick with implied 'name'. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
** However, I'm still currently leaning towards the practical convenience of providing a 'name' for the vast majority of microformats uses, rather than diluting this feature for the sake of avoiding implying inapplicable semantics to the few plain structured data microformats, and even then, only when no properties are explicitly specified! I'd rather introduce a new root prefix for those than lose the simplicity and utility of implied 'name'. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

== resolved ==
=== When to collapse whitespace in properties ===

The spec doesn’t explicitly require whitespace to be collapsed or not. The official mf2 test suite requires it to be collapsed.

Reasons why whitespace ''shouldn’t'' be collapsed:
* Plaintext property representations of syntax-highlighted code, poetry and song lyrics require whitespace to be present
* Whether or not whitespace is an important part of the content being parsed is determined by css white-space and CANNOT be inferred from HTML markup alone

Resolution 2013-11-12: Agreed, whitespace should not be collapsed (other than normal HTML5 parsing rules). The spec now refers to "textContent" rather than "innertext" to make this explicit.

=== How to interpret mf2 classnames on form inputs ===
E.G. how to parse:

<source lang=html4strict>
<input class="u-url" value="https://brennannovak.com/notes/338" />
</source>

Examples in the wild: https://brennannovak.com/notes/338

See proposal:
* [[hcard-parsing-brainstorming#input_element_handling]]

Resolution 2013-11-12: Per that proposal, p- u- dt- properties on input[value] elements now use the value attribute.

=== mixture of microformats2 and classic microformats classnames on different elements ===
Some sites in the wild have mistakenly combined classic mf and mf2 markup in ways which misrepresent the content if parsed in BC mode.

Typically this is caused by putting classic and mf2 classnames for the same vocabulary on different elements, e.g:

<source lang="html4strict">
<body class="hentry">
<article class="h-entry">
<h1 class="p-name"></h1>
</article>
</body>
</source>

Sites where this has been observed:
* http://acegiak.machinespirit.net/2013/10/17/barnaby-walters-notes-another-thing-i-love-about-the-web-users-have-the-power-to-take-control-of-their-uis-and-improve-their-own-experiences-aside-drm-for-html-would-prevent-this-from-being-possibl/
* http://shawfactor.com/2013/08/06/thoughts-on-extending-webmentions/ (fixed)
* http://notizblog.org/2013/06/18/the-rise-of-the-indieweb/ (fixed)

Discussion:

* As far as I can tell, the problems in all of these examples were caused by mf2 markup being injected by a wordpress plugin, but classic mf classnames being present further up the DOM in the themes. When parsed in compatibility mode, the classic mf classnames are transformed into mf2 classnames, making the original mf2 classnames look like children of empty items.
* Turns out this isn’t theme-specific, WordPress injects hentry via PHP [http://indiewebcamp.com/irc/2013-10-22/line/1382448759]. The bug with the wordpress mf2 plugin is resolved as of [http://indiewebcamp.com/irc/2013-10-22/line/1382449035 2013-10-22] --[[User:Barnabywalters|bw]] 13:38, 22 October 2013 (UTC)

=== e- and p- escaping levels ===
<div class="discussion">
* The fact that the parsed value of any element with .e-* is at a different level of escaping to the parsed values of p-*, dt-* etc. without any indication of how the property was parsed in the output is a security problem. For example:

<table style="width: 100%">
<tr>
<th>input</th>
<th>output</th>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="p-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="e-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
</table>

* As a parser developer, the most straightforward way I can think of solving this is to add an option (enabled by default) which encodes HTML special characters on all non e-* properties, so the developer knows that all property values are going to be at the same level of escaping. --[[User:Barnabywalters|bw]] 20:00, 15 June 2013 (UTC)
** Your suggestion of auto-HTML-encoding p-*/u-*/dt-* property values is the most sensible I think. I would NOT make it an option, as it makes sense write consistent microformats2 consumers. - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
** Can you think of any existing apps/consumers of microformats2 via the parser that would break? What would indieweb comments parsers do? - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
*** The only breakage which might occur would be over-encoding of non e-* properties, but I’ll release this update as v0.2.0 and warn people about the changes. The worst thing which could happen is that some comments look a bit weird, as opposed to the current worst possible scenario of easy XSS attacks --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** We should also decide exactly which characters get encoded — just angle brackets, or quotes/ampersands as well? --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** I am not sure about this, it seems more like a helper function rather than a core feature of the parser. Personally I would like to store data as text and encode only when I am going to use and I known the format it is going to be use in. --[[User:GlennJones|Glenn Jones]] 9:54, 14 July 2013 (UTC)
***After the discussion on the indiewebcamp IRC with Barnaby Walters I now understand the XSS issue that this change is trying to address. A rogue author could include HTML with scripts to execute a XSS attack. These could be masked by switch prefixes i.e. p-* to e-* on a well use property. As the consumer does not see the prefix in the JSON output they have no idea if a property will content HTML or text. I will update my two parsers and the test suite --[[User:GlennJones|Glenn Jones]] 8:02, 17 July 2013 (UTC)
**So what about an author setting a property to e-* when it would normal be p-*, dt-* or u-* i.e.
<source lang=html4strict>
<div class="h-card"><p class="e-name"><script> alert('xss test') </script></p></div>
</source>
** per [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]], parsers should never automatically attempt to HTML-special-characters encode - as that would provide the client of the parser a false sense of security. It's *always* up to client code to escape any text being output to HTML *at the moment it is output to HTML* and never before, because they can never trust that any text from storage/elsewhere has for sure been escaped or not. - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** Should we not encode e-* as well and the consumer can decode at their own risk --[[User:GlennJones|Glenn Jones]] 18:42, 21 July 2013 (UTC)
*** No, never, per above point from [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** See [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] etherpad: https://etherpad.mozilla.org/microformats2parsing for more details on the resolution to this issue - and incorporate here (then move to resolved section below). - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
* Resolved by changes to the parsing spec: all properties are plaintext (non-HTML escaped), e-* properties result in a dictionary with <code>value</code> = plaintext version, <code>html</code> = raw HTML version
----

</div>

=== br hr empty string ===
<div class="discussion">
* The parsing rule 'else if br.p-x or hr.p-x, then return "" (empty string)' for p-* can cause any code consuming the API to become quite bloated. It means that you have test every array value to see if its an empty string. It is also unclear to me what the purpose of this mark-up pattern is for [[User:GlennJones|Glenn Jones]]
** Upon reconsidering this, I agree with you, this is an unlikely use case. If a publisher wants to explicitly set an empty property "p-foo" they can simply write <code><span class="p-foo"></span></code> which looks explicit. Whereas BR and HR tags are often just presentational, so we should both not encourage usage of them for semantics, and anyone that did use them would be subject to likely loss of semantics upon a redesign (that got rid of those particular BR and HR tags). I'm going to remove them from the parsing spec. - [[User:Tantek|Tantek]] 15:29, 10 February 2013 (UTC)
</div>

=== datetime examples without T delimiter ===
<div class="discussion">
* The examples in the wiki microformats-2 pages such h-entry and h-entry had datetime without the 'T' delimiter between date and time. ie
<source lang="html4strict">
<time class="dt-published" datetime="2013-06-13 12:00:00">13<sup>th</sup> June 2013</time>
</source>
I have updated the pages. As far as I known this is a new pattern for dates. Was it a mistake in the examples or is it a new datetime pattern.
** The [[HTML5]] "time" element, and "datetime" attribute allow for space <span style="white-space:nowrap">" "</span> as a separator between date and time as well as "T", thus we allow it for microformats as well. The <span style="white-space:nowrap">" "</span> separator is preferred as the date and time are more readable when separated by a space. The examples noted in those specs deliberately use this. - [[User:Tantek|Tantek]] 18:48, 15 July 2013 (UTC)
</div>

=== rel-alternate absent optional attributes ===
<div class="discussion">
* What should rel-alternate parsing do when one of the optional attributes specified (<kbd>hreflang</kbd> or <kbd>media</kbd> or both) is not there? The options seem to be:
*# leave the corresponding key out of the alternate JSON object
*#* This one. Leave the corresponding key out.
*# include the corresponding key in the alternate JSON object, but set the value to the JSON null object
*# include the corresponding key in the alternate JSON object, but set the value to a blank string
*# something I haven't thought of

I haven't checked the existing implementations, but Barnaby said he's not sure what the appropriate way to deal with it is either. —[[User:TomMorris|Tom Morris]] 15:41, 9 August 2013 (UTC)
</div>

=== rel-alternate and type attribute ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Should rel-alternate parsing also pick up the <code>type</code> attribute? It’s fairly widely used, e.g. for ATOM feeds.
** Numerous existing sites/pages have various [[rel-alternate]] uses with a type attribute for feeds/APIs so that's good enough to add this for help with discovery in general. Rel parsing updated. - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
</div>

=== Extraction vs Interpretation ===
Issue raised by: [[User:BenWard|Ben Ward]]

A microformats ‘1.0’ parser performs the following function:

* Given a piece of HTML content, discover a known microformat, extract it, apply various extraction patterns based upon the HTML mark-up used (e.g. include pattern, <code>abbr</code> patterns, date-time patterns, value-title pattern), apply various content optimisations where applicable, and return the result in an object native to the programming language.

This is performing two types of function: Extraction of data from an HTML document or fragment, ''and'' interpretation and optimisation of that content to match the rules set out by a vocabulary specification.

It is only possible to write a generic parser that covers the first half of this task: Extraction, and application of global rules based on HTML elements and patterns common to all formats.

The purpose of a generic parser (as supported by use cases such as search engines, and other crawlers) is:

To provide a way for tools to extract rich data from a page for native storage, such that the data may be interpreted later by applications. This allows microformats to be crawled, and indexed, and removes the need to include complex HTML parsing within every implementation of microformat data.

Microformats will continue to define various vocabulary-specific optimisations. as part of the design to be optimised for authors. For example: The <code>fn</code> pattern in [[hcard]], or the <code>lat;long</code> pattern in [[geo]], as well as default values for properties, such as the maximum rating in an [[hreview]].
* Actually, no, as it is defined currently, microformats 2 ''drops'' vocabulary-specific optimizations. Such optimizations have often been too inapplicable, error prone or i18n-unsafe (e.g. fn to given-name + family-name fails for both numerous cases where middlenames/initials are used, and in general in numerous Asian languages where given/family name order is the reverse of Western English conventions, or languages with multiple family-names, e.g. Spanish - see [[hcard-issues-resolved]] for more). This is a deliberate cutting of a "feature" from microformats 1, it is a deliberate model simplification design decision. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

==== Extraction resolution ====
Proposed resolution:

Microformats2 should refer only to ''extraction'' of microformats. Vocabularies should in turn document their appropriate optimisations, which will need to be applied by implementations, or a companion to an extractor, which I'll refer to here as an ‘interpreter’.
* Vocabularies will no longer have optimizations, this is again deliberately, as they've been shown to be more error prone than helpful. Thus there should be no need for any vocabulary-specific 'interpreters'. However, due to design quirks in various legacy/interchange formats, ''export conversions algorithms'' to those legacy/interchange formats will require some additional legacy-format-specific rules (e.g. odd "required" rules in [[Atom]] or [[vCard]] will require specific synthesis rules, limitations in said formats will require filtering of some values, e.g. [[vcard3]] BDAY disallows vague birthdays like year-month and --month-day - subsequently allowed in [[vcard4]]). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

A microformats2 ‘extractor’, in combination with the functionality of a domain and format-aware ‘interpreter’ (either another shared component, or part of the implementation itself) would be equivalent to a microformats 1.0 ‘parser.’
* A microformats2 parser is both generic (no knowledge of specific vocabularies), and lacks any/all such vocabulary-specific rules as compared to a microformats 1.0 [[hcard-parsing|parser]] with the exception of a 1) a limited list of well-established/interoperable backward compat root class names (of current [[microformats]] that are or can be soon shown to be specifications/standards per the [[process]]), 2) flat sets of backward compat property names (some with prefix/name specific conversion) for each of those backward compat root class names. This is a deliberate design decision that makes microformats 2 more "micro", and yes this means that even with such backward compat support, this simple form of backward compat may mean that some existing microformats 1 content breaks. We'll assess those and iterate on a documented case-by-case basis rather than attempt to maintain theoretical 100% backward compatibility (since many current microformats format-specific-features are either unused, or may have caused more problems than solutions). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

N.B. I'll rewrite some of these as [[microformats2-parsing-faq]] to help better clarify. The reasoning that led to most of these design decisions is documented in the [[microformats-2#About_This_Brainstorm|microformats 2: About This Brainstorm]] section and following sections. I'll recheck those sections to see if/where reasoning for some of the above noted design decisions may have been missed, and back-fill accordingly. This is necessary because [[microformats2]] is a evolutionary result of simultaneously addressing both numerous generic [[issues]] as well as various common [[hcard-issues-resolved|format]]-[[hcalendar-issues-resolved|specific]] [[mfo|problems]] in microformats1 syntax and vocabularies. The very number of changes may make it more challenging (from a microformats1 perspective) to see why any particular design change has been made. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

This issue can be moved from resolved to closed once the above-mentioned write-ups have occurred.

===Parsing properties from rel attributes===
tl;dr resolution: As of 2013, [[microformats2-parsing]] handles parsing all link and a href rel values at document scope level, and producing canonical JSON accordingly. - [[User:Tantek|Tantek]]

Issue raised by [[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC):

* Currently, hAtom parses `bookmark` as a permalink
* Various microformats parse `rel=tag` as tags
* The current proposal for parsing does not allow parsing properties from rel attributes.

Microformats parsers could instead extract ''all'' link relationships from rel attributes within an microformat object, parsing them as if a u- prefixed property.
* Minor nit: Rather than same as a u- prefixed property, I think such "rel" properties should be parsed purely from the <code>href</code> attribute on <code><a></code> and <code><area></code> elements and nothing more. I would strongly disagree to extending rel to apply to other elements with URLs like img src, object data, or to apply to elements in general like div. That's the path that RDFa has taken and caused much confusion as a result. [[User:Tantek|Tantek]] 07:39, 5 October 2011 (UTC)
** Agree: That seems like a perfectly reasonable restriction. --[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)

This results in:

* Continuing use of the <code>rel</code> attribute in HTML, thereby building on HTML semantics rather than bypassing them or ignoring them in favour of something less meaningful.
* Parsing hAtom objects contain a property named <code>bookmark</code>, in place of <code>permalink</code>.
* All microformats that use <code>rel-tag</code> would contain a property named… <code>tag</code>. Perfect.

Since <code>rel</code> attributes are not overloaded for other functionality like class is, and other uses of <code>rel</code> within content are low (and non-semantic uses are nil, to the best of my knowledge) the risk of property pollution would be extremely low.

Note, with regard to this last point, that a generic microformats parser ''will'' parse false-positive properties, and ''will'' parse objects in combined chunks, rather than individually by format. Extracted objects will often not represent a vocabulary without further processing.

<div class="discussion">
* This sounds like it might be workable. Let's try it and see how well authors "get it". - [[User:Tantek|Tantek]]
* Possible issue: do we have any collisions between class property names and rel names? (I don't think so offhand, but useful to ask the question). - [[User:Tantek|Tantek]]
** None that I can think of in microformats. There is the case of Google's <code>rel=author</code> and <code>p-author</code> in hAtom. However, the next point, about mfo scoping, would cover it in most situations (rel-author on a hyperlink within an hcard wouldn't be applied to the hentry.) The one situation in a parse tree where it's ambiguous would be this:
<source lang=html4strict>
<a href="p-author h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
** I can think of two quite reasonable solutions:
*** 1. Declare that class properties take precedence over rel properties of the same name, discarding rel values if a class is also found, or
*** 2. Since all properties are now multi-value anyway, the hAtom object could be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
** —[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)
*** Option 2 makes sense and is consistent with the rest of the multi-value parsing/handling. - [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
*** What about without the 'p-author'?
<source lang=html4strict>
<a href="h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
Should that be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
Or
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': 'http://benward.me' /* from the rel="author" */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},

],
…
}
}
</source>
*** And if the former, then we're presumably saying that the value parsed due to the presence of a rel is always its own value, and does not combine with any other structures. I am fine with this, but I wanted to make sure we are ok with that explicitly. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
**** +1 I think that since the rel attribute is specifically concerned with the relation to an href attribute, it should not be combined with other structures that are rightly declared uses classes.
***** The more I've thought about this and how consuming applications may want to treat rel semantics, the more it seems correct to keep rel semantics distinct from class semantics. Class semantics are quite general/flexible, whereas rel is quite specific, naming something else in terms of a relationship from the current page/microformat's perspective. I think we should consider putting rel values in their own 'rel' collection, separate from the 'properties' collection. E.g. the original rel-author p-author h-card markup example would be parsed into this:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
}
],
…
}
'rel': {
'author': ['http://benward.me'] /* from the rel="author" */
}
}
</source>
***** and if a post had multiple authors:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from p-author */
'type': ['h-card'], /* from h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
{
'value': ['Tantek Çelik'], /* from 2nd p-author */
'type': ['h-card'], /* from 2nd h-card ... */
'properties': {
'name': ['Tantek Çelik'],
'url': ['http://tantek.com']
},
],
…
}
'rel': {
'author': [
'http://benward.me', /* from rel="author" */
'http://tantek.com' /* from 2nd rel="author" */
]
}
}
</source>
***** This preserves the semantic distinction between rel and properties in general, and leaves it up to a higher-level application to implement any logic around showing "more info" about a rel-author, e.g. by correlating the rel-author URL with the 'url' of an hCard it found in the same entry. However, note that even in the earlier JSON data model, the rel-author value just shows up as another property value, and any higher level application would still have to do some correlation logic. At least with this JSON data model, applications that may be looking for a rel value in particular, or a property value in particular can do so without having one unintentionally pollute the other. [[User:Tantek|Tantek]] 17:33, 6 October 2011 (UTC)

* Presumably we'd apply all the same property scoping rules to rel scoping as well. E.g. a rel hyperlink inside a microformat won't be seen by any containing microformat. - [[User:Tantek|Tantek]]
** Correct, it should be parsed in the same scope as all other class properties in the object.
*** Update: all rel microformats are now parsed at page-scope. Per-microformat scoping of rel has been found to be too confusing in practice (and against the general semantic of rel expressed in the HTML/HTML5 specs) [[User:Tantek|Tantek]] 01:00, 10 July 2014 (UTC)

This issue can be moved from resolved to closed once we've verified that all the above-mentioned and implied needs to write things up have occurred.
</div>

=== deduping of rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-02 by [[User:Kevin Marks|Kevin Marks]]
* 2015-06-05 resolved by consensus and one real world implementation proof of implementability and verification of expected results. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

Many sites have multiple duplicate rel links to the same url - a very common case is WordPress home pages eg [http://ma.tt ma.tt]

Each post on the page has a block like
<code><pre>
<div class="entry-meta">
<span class="date">
<a href="http://ma.tt/2015/05/beethoven-mozart-bach/"
title="Permalink to Beethoven, Mozart, Bach" rel="bookmark">
<time class="entry-date" datetime="2015-05-31T22:42:00+00:00">May 31, 2015</time></a></span>
<span class="categories-links">
<a href="http://ma.tt/category/asides/" rel="category tag">Asides</a></span>
<span class="author vcard">
<a class="url fn n" href="http://ma.tt/author/saxmatt/"
title="View all posts by Matt" rel="author">Matt</a></span>
</div></pre></code>

As currently defined, the parser will create duplicate entries in <code>rels</code> for each post:
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/",
"https://ma.tt/"
],
}
</pre></code>

and in the <code>rel-urls</code> we will also see:
<code><pre>
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author",
"author",
"author",
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home",
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag",
"category",
"tag",
"category",
"tag",
"category",
"tag"
],
"text": "Asides"
}
</pre></code>
These duplicates are unhelpful for parser consumers. We should:
* make them both sets - only listing distinct values. This will remove ordering information, but order is irrelevant for rel in html.
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/"
],
}
…
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag"
],
"text": "Asides"
}
</pre></code>

* possibly we could also make <code>title</code> <code>text</code> <code>type</code> sets too. That would solve the information loss issue with the current parsers
** Resolution: in the case of duplicate other attributes, first one set wins. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

<div class="discussion">
* +1 as the proposer. A version of mf2py that does this is running at unmung,com. see [http://www.unmung.com/mf2?url=https%3A%2F%2Fma.tt&html=&pretty=on fro ma.tt] or [http://www.unmung.com/?html=%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E&pretty=on a simple test] [[User:Kevin Marks|Kevin Marks]] 23:49, 2 June 2015 (UTC)
* +1 makes sense to me, and not having them be sets in the current spec is likely an oversight on my part. Thanks for noting this issue. [[User:Tantek|Tantek]] 05:28, 3 June 2015 (UTC)
</div>

=== include alternates in rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 resolved per consensus and one real world implementation proof of implementability. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* add "alternate" rels to the "rels" collection to make them easier to look-up in "rel-urls" - that is, all rel values end up in "rels" collections. No exceptions.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls".
* +1 This makes sense to me, as the <code>rels</code> and <code>rel-urls</code> should match so you can lookup in rels first, then get details about urls from rel-urls. We can drop "alternates" independently from this change. [[User:Kevin Marks|Kevin Marks]] 00:23, 2 June 2015 (UTC)
** +1 drop "alternates" independently now made a separate issue. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
* +1 Makes sense. And I agree with Kevin; I think parsers should deprecate "alternates" for now and drop it after a version cycle or two. [[User:Kylewm|Kylewm]] 00:30, 2 June 2015 (UTC)
* implemented in [https://github.com/kevinmarks/mf2py/commit/4dba45200eef11da811f64817d02044ab9e98b77 my fork of mf2py] and running on [http://www.unmung.com/?html=%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fa%22%3Eauthor+a%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fb%22%3Eauthor+b%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F1%22%3Epost+1%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F2%22%3Epost+2%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22alternate+home%22%0D%0A+++href%3D%22http%3A%2F%2Fexample.com%2Ffr%22%0D%0A+++media%3D%22handheld%22%0D%0A+++hreflang%3D%22fr%22%3EFrench+mobile+homepage%3C%2Fa%3E&pretty=on unmung] [[User:Kevin Marks|Kevin Marks]] 01:29, 2 June 2015 (UTC)
</div>

=== Empty properties overridden by implied rules against user expectation ===
Status: resolved, existing behavior correct, no changes to parsing spec.

2015-07-03: raised by [[User:Glenn Jones|Glenn Jones]]

Emma Kuo brought up an issue (https://github.com/glennjones/microformat-node/issues/22) based on following the indieweb note pattern, where the content of a note is given both the e-content and p-name classes. If the element containing the notes only has none text content like image the p-name can have unexpected value. Here is the example she gave:

<code><pre>
<div class="h-entry">
<a href="http://this.site/photo" class="u-url"></a>
<div class="e-content p-name"><img src="photo.jpg" class="u-photo"/></div>
Some extraneous text
<div class="h-cite">
<a href="http://someother.site/like" class="u-url"></a>
<a href="http://this.site/photo" class="u-like-of"></a>
<div class="e-content p-name">liked this</div>
</div>
</div>
</pre></code>

At the moment I parser this as follows: - if a property (p-name) is empty do not add it to the output. In this case "empty" is classed as not containing any non-whitespace text. As far as I known there is no guidance on how to handle "empty" properties in microformats paring rules, so I followed the conventions of JSON API's not to return "empty" properties.

The side effect of the above is that p-name also has a number of "implied rules". The "implied rules" try to automatically fill properties like p-name if there is no defined value. In the example above it uses the textContent of the parent h-entry, so value of the h-entry>p-name is the text content of the h-cite i.e. "likes this".

Options:

1. We should not allow the "implied name rule" to get textContent from within a child h-*
<div class="discussion">
* <strike>+1 I believe this is inline with how we parse properties and will meet user/author expectations [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* -1 A nested h-* is still part of the content of the parent h-*, I don't quite understand the rationale for excluding it. For example, I may include lots of h-cards in the body of a post that references people and wouldn't want them to be excluded from the implied name generation. [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* -1 I'm not sure this would solve the problem because auto-filled text could come from the parent h-* ("some extraneous text" in the example above) [[User:emmak|Emma Kuo]] 20:50, 4 July 2015 (UTC)
* -1 I agree with the other -1s. This would break some of the simplicity of the model. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
</div>
2. We should not execute the "implied rules" where there is an author defined "empty" property.
<div class="discussion">
* <strike>-1 Although the output would meet author expectations it is complex for parsers as they will have to keep state for each property through the whole series of parsing rules. [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* +1 An explicit, empty, p-name property should prevent an implicit p-name from being generated. For example tantek.com includes <span class="p-name"></span> at the start of the h-feed to prevent a giant name from being auto-generated. From my reading of the parsing spec, I don't see any reason that blank strings should be excluded from parsing. (mf2py and php-mf2 will both happily include empty strings in their output) [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* +1 We already have interop on this between mf2py and phpmf2, as well as people depending on it to explicitly set empty property values. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
* +1 As we already have interop with two parsers and solid user issue from Emma we should take this approach. [[User:GlennJones|Glenn Jones]] 11:51, 29 July 2015 (UTC)</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== uf2 children inside a classic microformats root class name ===
Status: incorporated into [[microformats2-parsing]]

2015-020: (raised by kylewm) What should microformats2 children inside a classic microformats root class name do?

Options:

1. Nothing. Any unattached uf2 children inside a classic microformats root are ignored. Problems:
<div class="discussion">
* However then there's a possible surprise if/when the author upgrades the classic microformats root to uf2, then all of a sudden all the new uf2 children show-up.
* Another downside: author adds uf2 markup, can't figure out why nothing is happening (because somewhere up the tree in code they didn't touch is classic microformats that are hiding these unattached uf2 children.
</div>
2. Show up in the children collection of the classic microformats root
<div class="discussion">
* Feels most predictable. When you add uf2 root class names anywhere, they will show up in the JSON output hierarchy.
* When you convert ancestor class microformats root class names to uf2 root class names, no surprise in terms of which microformats show up. Same children collection.
* +1 Thus I'm leaning towards this one, despite the fact that classic microformats never had a concept of generic unattached children. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)
* +1 I think this is the best option I will implement it and update the wiki once its in the JavaScript parser. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>
3. Show up as peers to the classic microformats root. Issue(s)
<div class="discussion">
* Has ths surprise aspect of if/when you convert the classic root class name to a uf2 root class name, the former peers become unattached children.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== any h- root class name overrides and stops backcompat root ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: The presence of any h-* root class name overrides and stop any backcompat parsing of classic microformats root class names on that same element. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for restricting backcompat root class name to only seeing backcompat property class names
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
* I don't think I understand this rule. If I was stop all parsing of of classic microformats in the presence of any h-* root in a document then some of the other rules such as "uf2 children inside a classic microformats root class name" do not make sense. Could this item be expanded and explained a bit more? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** added "on that same element" as that was what we were discussing/implying in this issue. [[User:Tantek|Tantek]] 22:49, 18 September 2015 (UTC)
</div>

=== backcompat classic microformats should only see backcompat properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats vocabulary that indicates a backcompat root class name (and thus an absence of the microformats2 equivalent on the same element), parsers must only look for the backcompat properties that are specified explicitly for that backcompat root class.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such behaviour was never expected by authors, and crossing a classic microformats root class name with microformats2 property names were never explicitly expected nor specified to work.

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== microformats2 root class names should only see microformats2 properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats2 root class name, only explicit microformats2 properties should be parsed. Any backcompat property names must be ignored.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such microformats2 authors should be expected to do all their microformats markup with microformats2 class names - this is a deliberate expectation so that their microformats aren't polluted with other (classic microformats) coincidentally named generic class names.

Thoughts?
<div class="discussion">
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== implied properties on backcompat parsing unlikely to be intended ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
Since classic microformats had no notion of implied properties, when implied property parsing occurs on backward compat classic microformats root class names, it is unlikely that any implied property (p-name u-url u-photo) was ever intended by the author of the classic microformat. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
Examples:
* see https://indiewebcamp.com/h-entry#bad_hentry_properties for a growing list

'''Proposed resolution:'''

* Be explicit in implied property parsing that it must only be done for explicit 'h-*' root class name microformats, not for any (back)compat parsing of microformats. Please comment on this proposal with "** comment" on new lines below. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
** +1 This makes a lot of sense to me. We should strive to parse mf1 as it was intended by the author, and I think you're right that implied rules are unlikely to be what was intended [[User:Kylewm|Kylewm]] 03:22, 30 December 2014 (UTC)
** +1 I think this will help backcompat parsing, but there are two major things to consider. It may well break some consumer code as the output for a microformats currently always has the name property, there may not be the defences code to check this is true when we remove the implied name rule for classic microformats. The test suite will also need major updating as all the test output for classic microformats will have. I will look into implementing this and report back to the wiki. [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** Also it should be made clear that we are only removing the implied rules from classic microformats parsing and not the value property? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
*** The "parsing for implied properties" section only references name, photo, url properties. Where (in the spec) is the confusion about "value" coming from? [[User:Tantek|Tantek]]
** RESOLVED at [[2015-01-20]] meetup. [[User:Tantek|Tantek]] 04:09, 21 January 2015 (UTC)
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Set implied properties by microformat version"

=== link elements and u- parsing ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Raised by tantek on 2014-07-08 on [http://logs.glob.uno/?c=freenode%23microformats&s=8+Jul+2014&e=9+Jul+2014#c72916 irc]: should the parsing specification for handling u- properties be modified to include the <code>link</code> element? The potential downside is that [[invisible-metadata-is-considered-harmful]], however all known real world examples of <code>link</code> are <em>semi-</em>visible data (not fully hidden).

There are potential cases for wanting to use link as an alternative to <code>a</code> (and <code>area</code>), such as a whole page where the root <code>html</code> element is an <code>h-card</code> and the properties are included across the page: some in visible data in the <code>body</code> while others are in the <code>head</code> as <code>link</code> elements. Example:

One specific use-case is the semi-visible <code>link rel="shortcut icon" href="..."</code> - which is visible sometimes in browser UI, and also when a user chooses "Add to Home Screen" on a mobile device. Such page level icons may be used as a <code>u-photo</code> or <code>u-logo</code> of the containing <code>h-*</code> object on the <code>html</code> element.
* http://adactio.com/about/myself/ on 2014-190
** <em>could</em> use <code><html class=h-card></code> - page is all about Jeremy Keith the person
** <em>icon / logo is only</em> on <code><link></code> tag which <em>could</em> use <code>class=u-logo</code>: <br/><code><link rel="shortcut icon apple-touch-icon" type="image/png" href="/icon.png" /></code>

Another specific use-case is a post permalink page, e.g. with <code><html class=h-entry></code>
* http://waterpigs.co.uk/notes/4WjHpC/
** <em>has</em> <code><html class="no-js h-entry hentry h-as-note" lang="en"></code>

Another use-case is publishing links to PGP/GPG keys linked from the head which is currently handled by <code><link rel=pgpkey></code> which is already supported in existing [[microformats2-parsing#parse_a_hyperlink_element_for_rel_microformats|microformats2 rel parsing]] of <code>link rel</code> elements. Thus there is a (admittedly weak) argument for consistently parsing <em>both</em> <code><link rel></code> <em>and</em> <code><link class="u-*"></code>.

E.g. inside that aforementioned real world <code><html class=h-entry></code> post permalink page example,
* why should <code><link rel="in-reply-to"></code> work
* but not <code><link class="u-in-reply-to"></code> ?
The slightly stronger argument for consistency of link handling is that it <strong>[[simpler|simplifies]]</strong> the publisher (and parser) model:
* <code><a></code> and <code><area></code> work for both <code>rel</code> and <code>class</code>
* why does <code><link></code> only work for <code>rel</code> ?
* it would be <em>simpler</em> if all three tags just worked (in the same way) for both <code>rel</code> and <code>class</code>

'''Should the parsing spec be modified to handle these cases?''' —[[User:TomMorris|Tom Morris]] 09:25, 9 July 2014 (UTC)

** I'm generally in favour. It'd be good to see what other parser developers think. —[[User:TomMorris|Tom Morris]] 10:16, 9 July 2014 (UTC)
** adding this to the parsers won't be an issue. <del datetime="2014-07-09T18:45">The question is should the door be opened to hidden mf data?</del> <ins datetime="2014-07-09T18:45">Up on further reflection, there seems to be no need to distinguish between <code>rel=property</code> and <code>class=u-property</code> on link elements. So I am in favour for consistency.</ins> [[User:KP|Kartik]] 18:30, 2014-07-09 (EST)
** RESOLVED at [[2015-01-20]] meetup. Make link consistent with a.
</div>

=== drop alternates collection ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 split into separate issue from include alternates in rels per implementation feedback from Kevin Marks. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* drop "alternates" as its no longer needed, and all current consuming code clients like rel-urls better anyway.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls" in original issue now "include alternates in rels", we no longer need "alternates", and those with client consuming code have universally indicated that they would rather use rel-urls anyway. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
</div>

== see also ==
* [[microformats2-parsing]]
* [[microformats2]]

microformats2-parsing-issues

2016-03-13T20:58:21Z

Barnabywalters: /* default generated HTML */

This page is for documenting issues with the [[microformats2-parsing]] specification.

== issues ==
Open issues in various states of partial resolution from none to nearly resolved.

=== ignore u-camelCase properties ===
Due to Suit CSS (and others? citations?) recent (2015-?) use of "u-*" class names for so-called "[http://davidtheclark.com/on-utility-classes/ utility classes]", we are seeing some false positives in a few very rare instances, e.g.: http://www.unmung.com/mf2?url=http%3A%2F%2Fwww.kevinmarks.com%2Ftwitterutils.html&html=&pretty=on

(Nearly) all these "utility classes" use camelCase for the class name suffixes, thus we can filter them out by looking for camelCase (since microformats class name conventions are always all lowercase and hyphenated), or even just looking for (and rejecting) *any* capital letters.

Proposal:
* microformats2 parsers MUST IGNORE u-* classnames where the * has any uppercase letter(s).

<div class="discussion">
* +1 [[User:Tantek|Tantek]] Let's get this fix rolling quickly to avoid further pollution.
* +1 [[User:Barnabywalters|Barnaby]] php-mf2 already ignores classnames with capitalised prefixes, ignoring any classnames with capital letters seems totally reasonable
* ...
</div>

=== exclude style elements before parsing ===
[http://logs.glob.uno/?c=freenode%23microformats#c85457 2016-01-25 raised in #microformats]

Ran into an issue of a <style> element being parsed as plain text in a p-name. Should [[microformats2-parsing]] be updated to indicate <style> should be excluded when parsing? Appears to implicitly fall under [[microformats2-parsing#note_HTML_parsing_rules]]

Sample link: http://veganstraightedge.com/notes/2016/01/16/tonight-s-dinner-tacocleanse-beverly-hills-c

The <script> tag can be similarly problematic.

Proposal: Drop both <script> and <style> elements completely when parsing any property (including e-* HTML values). [[User:Tantek|Tantek]] 01:01, 29 February 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Aaronpk|aaronpk]] as a consumer of HTML from an e-* property, I will always be sanitizing the HTML and removing <script> and <style> anyway
* +1 [[User:Kylewm|kylewm]]
* 0 [[User:Barnabywalters|Barnaby]] +1 to removing the contents of <script> and <style> from all plaintext properties (and 'value' property in HTML dicts), -1 to removing <script> and <style> from HTML. That’s a job for a sanitization stage. As aaronpk points out, sanitization will have to be done anyway if the content is to be reposted, so doing so in the parser doesn’t actually save anyone any work, but removes information which could be useful to people (example use cases: publishing posts with embedded per-post styling, publishing interactive HTML documents with embedded javascript)
** +1 this seems like reasonable feedback to make a new refined proposal. [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)
</div>

Proposal 2: Drop both <script> and <style> elements completely when parsing any property (except for e-* HTML values, which preserve all markup). [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Barnabywalters|Barnaby]
* ...
</div>

=== use poster if no src on video for u props ===
[https://indiewebcamp.com/irc/2015-12-13#t1450035721661 2015-12-13 raised in #indiewebcamp]

There is a use-case of marking up the "poster" of a video element as the u-featured of an [[h-entry]], to do that, we need to change [[microformats2-parsing#parsing_a_u-_property|u- property parsing]] to look at the poster attribute of the video element, after it's looked for the src attribute.
<blockquote>" else if video.u-x[poster], then get the poster attribute "</blockquote>

Real-world example of markup in the wild:
* http://veganstraightedge.com/videos/2013/5/31/1/backyard-squirrel-buddy
** and likely all other videos posted there.

Background discussion that led to this proposal:
* https://indiewebcamp.com/irc/2015-12-13#t1450035721661

This seems very straightforward so I've added it as PROPOSED directly in the parsing spec. This issue is for tracking the discussion.

Feedback from parser implementers please!
<div class="discussion">
* +1 [[User:Barnabywalters|Barnaby]] easy to implement and based on real-world markup, no objections
* ...
</div>

=== uf2 children on backcompat properties ===
[http://logs.glob.uno/?c=freenode%23microformats&s=today#c84632 2015-11-24 raised by Calli] in #microformats

Related but different from [[#uf2_children_inside_a_classic_microformats_root_class_name]], when there is a uf2 child directly on a backcompat property, what should happen? E.g.

<source lang=html4strict>
<div class="vcard">
<div class="adr h-adr">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

What is the expected behavior and parser output?

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-adr"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

<div class="discussion">
* Proposal: the nested "adr h-adr" child is treated as an mf2 object, not backcompat, and thus the resulting parsed "locality" property has a single value of "MF2". Proposed by Calli, noting that Glenn Jones's microformatshiv gets that result currently, and it would be easier for him (Calli) to implement this way.
** +1 Tantek, seems reasonable and the reasoning provided is good (we have one implementation this way already)
** +1 Kyle, this is consistent with the resolution to the related issue
** +1 Calli, yes, this is easier for me to implement (than taking both MF1 and MF2 properties) because it is consistent - for me, consistency is the controlling factor in favor rather than ease of parser implementation
** +1 Barnaby, php-mf2’s mf1 backcompat produces this exact result, and it makes a lot of sense to me
** ...
</div>

Another example:

<source lang=html4strict>
<div class="vcard">
<div class="adr h-custom">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-custom"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

Per the [[#any_h-_root_class_name_overrides_and_stops_backcompat_root]] resolution, the class name "h-custom" overrides the use of "adr" as a backcompat root.

=== default generated HTML ===
2015-09-08 raised by Tantek in #indiewebcamp

Should there be a default (perhaps not quite "canonical") way to map/generate HTML+microformats2 from a parsed mf2 JSON output?

E.g. straw proposal:
* JSON/mf2 -> [[XOXO]]+mf2

Existing work / mappings:
* https://github.com/snarfed/granary/blob/master/granary/microformats2.py#L295

Related to:
* https://github.com/snarfed/granary/issues/31

Use-cases:
* default webview / presentation for a site that stores mf2 JSON output
* possibly a way to implement a distributed HTTP webcache retrieval protocol

Thoughts?
<div class="discussion">
* +1 [[User:Tantek|Tantek]] I think we should have this, but am open to proposals on specifics!
* +1 [[User:GlennJones|Glenn]] Also think this is worth looking at, but I am not sure it should be part of the parser spec. Feels like it should be built as a separate library and have it own spec on the microformats wiki.
* +1 [[User:Barnabywalters|Barnaby]] agreed with Glenn, this would be a nice thing to have, but IMO it’s out of scope for the parser and should be specified separately. Personally I would probably implement it separately too, depending on how much work it is.
* ...
</div>

=== Noscript skip/parse ===
2015-07-28

Should mf parsers skip <code><noscript></code> tag in the HTML, like the <code><template></code> tag mentioned in http://microformats.org/wiki/microformats2-parsing#note_HTML_parsing_rules ?

mf2py skips <code><noscript></code> when using the html5lib DOM parser but no when using lxml parser. Example use of <code><noscript></code> https://kartikprabhu.com/ featured images have a no javascript fallback image inside <code><noscript></code> with <code>class='u-featured'</code> markup.
* html5lib actually HTML-escapes the contents of <code><noscript></code>, so to mf2py it just looks like plain text with no tags. In Woodwind, I've resorted to using regex to strip out <code><noscript></code> tags before parsing (very hacky). [[User:Kylewm|Kylewm]] 15:52, 25 August 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] skip noscript (and inside) because in today's typical browsing contexts, nothing in noscript is displayed, thus we should discourage marking up effectively invisible content.
** Proposed change to [[microformats2-parsing#parse_a_document_for_microformats]]:
*** from: "follow the HTML parsing rules"
*** to: "follow the HTML parsing rules (including skipping/omitting <code><noscript></code> elements, e.g. like the html5lib DOM parser)
* -1 [[User:GlennJones|Glenn]] This subject does need to be address, but differently to proposed change. My personal view is that e-* html should be passed through raw and then the consumer can process it in a way they feel fit. Its a case for helper libraries. I am about to build a helper library to do this based on the Readability code to post process e-* html. Other people may want to take different approaches, defining this in the spec feels like move into a whole area of new functionally.

As a separate new point we need to consider "exclude tags" lists for parsed text from html. We should consider <code><noscript></code>, <code><noframe></code> and <code><template></code> there maybe other I have not gone through all the tags in current HTML spec. Also we should consider what to do about the more common pattern of fallback text within media tags <code><video></code>, <code><audio></code> etc. This should be explicitly discussed in the parsing rules. At the moment my experimental text normalisation does exclude tags, but the default text parse does not. Currently the fallback content in media tags like <code><video></code> is added to the parse text. 12:56, 25 Septemeber 2015 (UTC)
* ...
</div>

=== Standard datetime format ===
2015-07-28

http://microformats.org/wiki/microformats2-parsing#parsing_a_dt-_property does not specify any standard format to use for datetimes. e.g. <pre>2015-07-28T12:55:33</pre> vs <pre>2015-07-28 12:55:33</pre>
Would be good to standardize this to compare various parser outputs.

2015-07-29: This subject is (somewhat) covered in http://microformats.org/wiki/iso-8601 As it stands the JavaScript parsers support output in the 3 main profiles, 'W3C Note', 'RFC 3339' and 'HTML5' plus 'auto' which keeps authors format. The default date output for the JavaScript parsers is the same format as the date was originally authored in. This can be changes by setting the options.dateFormat switch to any of the other profiles mentioned. It would be good if other parser also had a switch to force output to a common profiles so we could compare various parser outputs, but I think the default should be how a date was authored. All output whatever profile should also keeps the authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string. This is important if you want to compare parser outputs.

The only exception to this where date and times are combined such as the implied h-event rule for dt-start and dt-end where I output in the HTML5 style 2015-07-29 12:55:33 as there is no predefined author preference and HTML5 profile is more human readable. [[User:GlennJones|Glenn Jones]] 11:02, 29 July 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] output more human readable <code>2015-07-28 12:55:33</code> canonically, with authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string.
** Let's update any test cases as needed for this. - [[User:Tantek|Tantek]]
* ...
</div>

=== implied date for dt properties both mf2 and backcompat ===
The [[value-class-pattern#microformats2_parsers|value class pattern dt-* date proposal]] should apply to both mf2 dt-* properties, and backcompat classic microformats, to preserve the hAtom / hCalendar optimizations noted on that page, but in a generic way.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] 16:12, 18 August 2015 (UTC)
* +1 [[User:Glenn Jones|Glenn Jones]] 20 August 2015
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== implied properties when an explicit class is provided ===
<div class="discussion">
Should "u-url" still be implied if another explicit class is already provided, as below. This is a contrived example, but it is taken from Bridgy's unit tests.

<code><pre>
<article class="h-entry">
<a class="u-like-of" href="http://orig.domain/baz">liked this</a>
</article>
</pre></code>

In this case, http://orig.domain/baz is almost certainly not the u-url, so IMO it would be better to leave it out —[[User:Kylewm|Kylewm]] 15:10, 7 October 2014 (UTC)

'''2015-01-20 consensus'''
* Changed my mind. Simpler to do nothing. Example provided is artificially constructed, does not reflect likely real world confusion of if we make implied properties more complicated. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
* ++ Consensus on do nothing for this case. At [[2015-01-20]]

'''Proposed resolution:'''
* Changed again. Due to indiewebcamp.com/edit use-case, this now makes sense for all implied properties. That is:
** If an element has any explicit property class name(s) on it, then it must not be used to imply any properties. [[User:Tantek|Tantek]] 20:50, 27 May 2015 (UTC)
*** +1 this seems reasonable, if a publisher is going to add an mf2 class, it is unlikely they want other classes automatically implied from the same value [[User:Aaronpk|Aaronpk]] 23:19, 29 November 2015 (UTC)
*** -1 for now. To my knowledge, this has only been observed in artificially constructed unit tests and examples, and it adds some weird edge cases that are hard to reason about. [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** ... provide input on this proposal here
** Refined: Or should this be refined by per parsing prefix? [[User:Tantek|Tantek]] 22:59, 18 September 2015 (UTC)
*** Any explicit "p-*" property means no implied "p-name" from that element
*** Any explicit "u-*" property means no implied "u-url" nor "u-photo" from that element.
*** ... provide input on this refined proposal here
** Suggestion: split this issue up per property. I think it makes sense for u-url and can be easily added to the spec as e.g. ".h-x>a[href]:only-of-type:not[.h-*<strong>,.u-*</strong>]". [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** Obviously wrong to assume a link explicitly pointing elsewhere is our "url"
*** More difficult to make a case for photo and especially for name.
*** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
*** ... provide input on this refined proposal here
</div>

=== whitespace collapsing revisited ===
2015-05-27: (raised by [[User:Kevin Marks|Kevin Marks]] per Glenn Jones)

Revising the microformats tests to conform to the "don't collapse whitespace" rule below reveals some non-intuitive cases.
preserving whitespace in addresses is somewhat defensible, but in an implied name it is often unhelpful, as it preserves non-user visible space there for authoring reasons.

For example:
[https://github.com/microformats/tests/commit/a325e0e9bc2089507e69b1883f7065a3316e07c2#diff-d577012c1438978a571c4049179607f0 this test] shows how extraneous whitespace ends up in the <code>name</code>

<code><pre>
<div class="h-review-aggregate">
<div class="p-item h-event">
<h3 class="p-name">Fullfrontal</h3>
<p class="p-description">A one day JavaScript Conference held in Brighton</p>
<p><time class="dt-start" datetime="2012-11-09">9th November 2012</time></p>
</div>

<p class="p-rating">
<span class="p-average value">9.9</span> out of
<span class="p-best">10</span>
based on <span class="p-count">62</span> reviews
</p>
</div>
</pre></code>

give a parsed result of:

<code><pre>
{
"items": [{
"type": ["h-review-aggregate"],
"properties": {
"item": [{
"value": "Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012",
"type": ["h-event"],
"properties": {
"name": ["Fullfrontal"],
"description": ["A one day JavaScript Conference held in Brighton"],
"start": ["2012-11-09"]
}
}],
"rating": ["9.9"],
"average": ["9.9"],
"best": ["10"],
"count": ["62"],
"name": ["Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012\n\n\n9.9 out of \n 10 \n based on 62 reviews"]
}
}],
"rels": {}
}
</pre></code>

The <code>value</code> is a reasonable textual representation of the event, but the implied <code>name</code> is full of spurious whitespace that any consumer would have to strip.

[https://github.com/microformats/tests/commit/4c9690b53b0a2f40440abac8e609c51ac7dd6d56 h-review] has similar issues

2015-05-28: (Addition by [[User:GlennJones|Glenn Jones]])

The example below shows the type of markup most effected by the "implied name" and "don't collapse whitespace" rule working together to produce output that is hard to use without further processing.

<code><pre>
<a class="h-card" href="http://glennjones.net">
<span class="p-given-name">Glenn</span>
<span class="p-family-name">Jones</span>
</a>
</pre></code>

The output for the name property from the above HTML would be <code>Glenn\r\n Jones</code> using the (trim lead/trailing) suggested in the parsing spec. I could of course move the spans onto one line, but it feels fragile to consider whitespace sensitivity in HTML like this. Added to the fact that HTML templating environments often take away that level of whitespace control from authors anyway.

There are issues with both: keeping whitespace, returns and tabs from parsed HTML or collapse that whitespace. If we return the whitespace it becomes mal-formatted for humans because it was only added to make the HTML code understandable and in most cases was not meant to be used/read outside of that context. If we collapse the whitespace we can have issues of whitespace sensitive text from <code><pre></code> etc. being incorrectly formatted.

Providing a CSS aware innerText feature would produce the most useable output, but this is too complex/time consuming to build for most parser developers. In the face of no perfect solution I have taken the 80:20 view, whereby errant whitespace, causes me considerably more problems than mal-formatted <code><pre></code> content so I collapse whitespace on all text returned.

This feature is a non-CSS aware version of innerText. It does not cover all rendering edge cases, but enough to produce practical output.

For now, I have started changing the node parser to flag "white-space collapsing" as an experimental feature which is off by default i.e. http://glennjones.net/tools/microformats/ but personally I will parse everything with this on as I find it the most practical solution.

Not sure where that leaves me on the options below.

Options:

Choose from:
# keep as is and every parser client has to post process for common cases.
# '''keep as is but have mf2 parser trim leading/trailing whitespace (likely to provide desired result and be reasonably backcompat)'''
#* +1 my preference of the two options. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
#* +1 though this doesn't solve any of the problems discussed above, it's still worth doing [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
#* +1 will help parsers be more consistent with each other, and I haven't ever encountered a case where preserving leading/trailing whitespace was desirable [[User:Kylewm|Kylewm]] 20:45, 8 June 2015 (UTC)

2015-06-08 option 2 resolved by consensus and implementation in mf2py.

Somewhat orthogonal:
* make <code>value</code> on properties with children normalise whitespace
** -1 Seems like a bad idea as this "value" is supposed to be the same as if there was no embedded child microformat. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
* make implied <code>name</code> normalise whitespace.
** +0 This is reasonable and already done somewhat in the parsing spec (trim lead/trailing). [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** +1 Given the universality of name, this would fix most of the issues we see. [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
* Put \n in textual forms if there is a <code><p></code> tag in the original.
** -1 that's a long path to go down with whitespace equivalents for HTML markup. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** would only preserving whitespace if in <pre> be an 80:20 compromise? [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)

Because there are both code markup and specific vocabulary (label) needs for preserving whitespace, we are compelled to preserve in general, perhaps except for very specific limited generic cases (e.g. trim leading/trailing, "value" parsing, implied name). [[User:Tantek|Tantek]]

=== u- parsing iframe src ===
Currently if I put u-* on an iframe it gets the value of the fallback text. This seems a shame. Getting the URL seems a sensible answer.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== i- parsing iframe src ===

More controversially, what about using an iframe for transclusion? A use case here is comments on a static site. Currently, on eg http://www.kevinmarks.com/microformatschema.html the comments are injected via JS, making them opaque to parsers and thus precluding further parsing such as salmentions.

If instead they were an iframe embedding them, a parser could optionally fetch its contents, parse them, and include them in the parsed mf2 output at that point. Overloading u-* for this seems wrong; e-* as below for srcdoc would have a different effect; this implies a new prefix directive would be needed. A strawman i-* (for include) may work.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== e- parsing iframe srcdoc ===
<div class="discussion">
* Proposal: addition of a new e-* parsing rule for iframe elements with srcdoc attributes. E.G.

<source lang="html4strict">
<div class="h-entry">
<iframe class="e-content" srcdoc="<p>A paragraph of HTML with "quoted quotes" &amp; doubly quoted ampersands</p>" />
</div>
</source>
<source lang="javascript">
{
"items": [{
"type": ["h-entry"],
"properties": {
"content": ["<p>A paragraph of HTML with "quoted quotes" & doubly quoted ampersands</p>"]
}
}]
}
</source>

This would allow, for example, HTML comments to be sandboxed inside iframes but still parsable as microformats.

I believe the correct processing would be to leave " entities as they are but to unescape any doubly-escaped ampersands.

** Is there any use case for that? —[[User:TomMorris|Tom Morris]] 12:32, 14 September 2013 (UTC)
** +1 we need documentation of use case and existing sites publishing iframe srcdoc like this - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
** Rejected by consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 properties on select ===
How should select elements with properties be treated any differently?

Awaiting real world examples / stronger use-cases, until then no special treatment of select elements with properties:
<div class="discussion">
* Are there any real world examples of select elements with microformats properties?
* What would the use-case be for putting a microformats property class name on a select element?
* Nothing special. By consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 root name on form ===
See what to do about <em>root class names</em> on <code><form></code> elements in particular:
* [[hcard-input]]

Awaiting real world examples / stronger use-cases, until then, no special treatment of root class names on <code><form></code> elements:
<div class="discussion">
* Are there any real world examples of a <code><form></code> element with a microformats root class name?
* [[hcard-input]] is one possible use-case, is anyone attempting to use forms for hCard input, e.g. with scripts to help make it work?
* Are there other use-cases for putting a microformats root class name on a <code><form></code> element?
* As of [[2015-01-20]] - no consensus - need more input as to when/why this is useful to do anything special.
</div>

===Parsing Literal Values===
Issue raised by: [[User:BenWard|Ben Ward]]

It is proposed for microformats2 that all microformats be parsable from just their root element, e.g. <code><p class="h-card">Ben Ward</p></code> would create an hCard with the following properties after parsing:

<source lang=javascript>
{
'type': ['h-card'],
'properties': {
'name': ['Ben Ward']
}
}
</source>

This is a four-fold change from the current [[hCard]]:
# type is generically identifiable as a microformat root, even in parsed form. The use of the 'h-' prefix persists into the type of the object. This is deliberately so, as a result of re-using the JSON data model of microdata which itself is re-using a common JSON convention, such that microformatted data is clearly distinguishable (as opposed to any other random schema that may be using a similar data model).
# root-class-only support. Per [[microformats-2-implied-properties]], the ''name'' property is implied by the entirety of the root class name element.
# 'name' instead of 'fn'. As also documented in [[microformats-2-implied-properties]], the continuous challenges/problems and need to repeatedly re-explain 'fn' over the years combined with the real-world market response of nearly every other party doing a person vocabulary renaming 'fn' to 'name', microformats 2 makes this change as well.
# There is no automatic parse-time inferring of <code>'given-name': ['Ben']</code> and <code>'family-name': ['Ward']</code>. Any such inferring *might* be made by a vCard converter, but is left up to that specific application (not all applications) built on that vocabulary, though even in that case it may not be necessary, as an empty "N:;;;" [[vCard]] property is sufficient to satisfy the N property requirement of [[vCard]], and also causes no problems when imported into various [[vcard-implementations]].

It is required of the extractor to understand that when a microformats object specifies no explicit child properties, that it must treat <code>h-card</code> as having a <code>p-name</code>. But, the parser is generic, so it also treats <code>h-review</code>, <code>h-entry</code>, <code>h-recipe</code>, <code>h-geo</code> as having a ‘<code>p-name</code>’.

As a result, specific vocabularies are evolved to drop their specific form of name (e.g. fn, summary, entry-title) and simplified to use a common 'name' property instead.

Note: while the overwhelming majority of real world publishing/consuming uses of microformats do so with proper nouns which have names (and thus this parser-level incorporation of an implied 'name'), there are some formats that do not have a 'name' semantic. For example, [[geo]], [[adr]], and possibly if/when developed, units of measure, length, cost. The current thinking is that the benefits to the far greater proper-noun use-case of microformats outweigh the technical inelegance of having an extra/ignored 'name' property on formats that lack such a semantic.

Some formats also may appear in theory to better imply some other property, e.g. a review might be thought to imply its ''content'', not its name, and an Atom entry its ''content'', not its title, but in practice (actual publishing patterns) this is not the case. Typically, brief unstructured reviews (or mentions thereof) provide a ''summary'' (often hyperlinked to an expanded structured form) of that review, not its content, and similarly, brief unstructured posts (e.g. RSS items) have historically most often been link blog items which include the title of an item and a link. Short status updates as well established by Twitter are newer and would seem to imply purely content with no title, at least semantically, however, even Twitter populates the RSS title and ATOM entry title of their feeds with the content. It's not clear what went into that decision, however, that's likely irrelevant, as the outcome turns out to be emergent consistency among publishing behaviors.

To avoid overloading or undermining the semantics of a vocabulary, I propose that we handle this at the extractor level in a simpler fashion: Define a new property for literal data, that an extractor will provide if no other information was available. All ''interpreters'' may then be instructed that in the event that an object has no properties, it can attempt to interpret the literal value from the page instead.

* This was one of the design iterations I went through which led me to the current implied 'name' design. Another iteration was the ability for a vocabulary to specify a single required property which was implied if there were no properties provided. However, the combination of the fact that in most cases such single required properties were quite name-like, and that a vocabulary-specific rule like that would then bind parsers to specific vocabularies (even so slightly) led me to collapse them into implying a 'name'. It's not perfect, but it's the best alternative so far that balances practical convenience of publishing/consuming, avoids vocabulary-specific knowledge in the parser, and technical (in)elegance. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

In existing microformats, the closest existing example we have for this is the <code>label</code> property in hCard, which is used to represent the literal address label for a place. It is a corresponding piece of <code>fn</code>, <code>org</code> and <code>adr</code> in combination, but has no structure in and of itself. Possibly, every microformat could have a <code>label</code> form where structured data is unavailable.

However in practice, the hCard <code>label</code> property is both little understood and little used. It's not even clear that it ought to be kept for microformats 2 (no known consumers, very few (if any?) real-world non-test publishers). This disuse is likely a good indicator that we should avoid basing anything on its design.

Alternatively, <code>value</code> is used throughout microformats to target a generic value (e.g. in combination with <code>price</code> in hListing.) It has been proposed that when parsing properties that are also themselves microformats, we create native objects of the form:

{
'value': '1900 12th Street, San Francisco, CA 94'
, 'type': ['h-adr']
, 'properties': {
'street-address': '1900 12th Street'
, 'etc': 'etc'
}
}

We could apply this same pattern to the root level:

{
type: [h-card]
, properties: {}
, value: 'Ben Ward'
}

In this case, an interpreter or implementation is responsible for using <code>value</code> in place of <code>fn</code>, or restructuring the object. It would be the responsibility of each vocabulary to define its root property. The parsing layer of microformats 2.0 would not impose semantics or naming onto that.

For another example, h-geo would end up like this:

{
type: [h-geo]
, properties: {}
, value: '1.3232;-0.543'
}

* This is an alternative I've been considering as well: [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)
** 'value' is more generic than 'name' (applies to more vocabularies) with the trade-off that it naturally has less (weaker) semantics.
*** +1 I think that having naturally weaker semantics would be appropriate for this parsing functionality. —[[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC)
** The interesting thing that this analysis has revealed is that there appear to be two distinct clusters of microformats, the much more commonly used/understood/useful proper-noun microformats which markup things with names (people, events, reviews, recipes), and the less used compound-data microformats which are often used ''inside'' other microformats and just have some sort of semi-structured value (adr, geo, measure, and perhaps even things like tel). Perhaps this is implying the possibility and some degree of utility for ''two'' microformats root class name prefixes, 'h-' for existing proper-noun microformats, and something else ('m-' for microformat/molecule?, 's-' for structured-value?, 'v-' for value (though historically "v-"/"v." has meant "vendor-specific")?) for unnamed structured data microformats.
*** This more and more feels like a good idea, and I'm leaning toward "s-" for struct / structure / structured value. "s-" works just like "h-" except that it doesn't imply any properties at parse time. We can try it and see what happens. There's also no harm if publishers just use "h-" structures, they just (possibly) get a few extra properties if they happen to omit properties.
** Parallels the same JSON when a property has both a string value ''and'' is a structure itself.
*** Changed my mind on this. The parallel is not quite there. 'name'/'url'/'photo' are only implied if there are NO properties, where as the JSON string value + structure convention *always* provides a 'value'. [[User:Tantek|Tantek]] 22:39, 4 October 2011 (UTC)
*** And due to this difference in behavior ('value' is there when nested properties are present, whereas 'name' is only implied when there are no properties specified), I think it's correct to keep them separate, i.e. stick with implied 'name'. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
** However, I'm still currently leaning towards the practical convenience of providing a 'name' for the vast majority of microformats uses, rather than diluting this feature for the sake of avoiding implying inapplicable semantics to the few plain structured data microformats, and even then, only when no properties are explicitly specified! I'd rather introduce a new root prefix for those than lose the simplicity and utility of implied 'name'. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

== resolved ==
=== When to collapse whitespace in properties ===

The spec doesn’t explicitly require whitespace to be collapsed or not. The official mf2 test suite requires it to be collapsed.

Reasons why whitespace ''shouldn’t'' be collapsed:
* Plaintext property representations of syntax-highlighted code, poetry and song lyrics require whitespace to be present
* Whether or not whitespace is an important part of the content being parsed is determined by css white-space and CANNOT be inferred from HTML markup alone

Resolution 2013-11-12: Agreed, whitespace should not be collapsed (other than normal HTML5 parsing rules). The spec now refers to "textContent" rather than "innertext" to make this explicit.

=== How to interpret mf2 classnames on form inputs ===
E.G. how to parse:

<source lang=html4strict>
<input class="u-url" value="https://brennannovak.com/notes/338" />
</source>

Examples in the wild: https://brennannovak.com/notes/338

See proposal:
* [[hcard-parsing-brainstorming#input_element_handling]]

Resolution 2013-11-12: Per that proposal, p- u- dt- properties on input[value] elements now use the value attribute.

=== mixture of microformats2 and classic microformats classnames on different elements ===
Some sites in the wild have mistakenly combined classic mf and mf2 markup in ways which misrepresent the content if parsed in BC mode.

Typically this is caused by putting classic and mf2 classnames for the same vocabulary on different elements, e.g:

<source lang="html4strict">
<body class="hentry">
<article class="h-entry">
<h1 class="p-name"></h1>
</article>
</body>
</source>

Sites where this has been observed:
* http://acegiak.machinespirit.net/2013/10/17/barnaby-walters-notes-another-thing-i-love-about-the-web-users-have-the-power-to-take-control-of-their-uis-and-improve-their-own-experiences-aside-drm-for-html-would-prevent-this-from-being-possibl/
* http://shawfactor.com/2013/08/06/thoughts-on-extending-webmentions/ (fixed)
* http://notizblog.org/2013/06/18/the-rise-of-the-indieweb/ (fixed)

Discussion:

* As far as I can tell, the problems in all of these examples were caused by mf2 markup being injected by a wordpress plugin, but classic mf classnames being present further up the DOM in the themes. When parsed in compatibility mode, the classic mf classnames are transformed into mf2 classnames, making the original mf2 classnames look like children of empty items.
* Turns out this isn’t theme-specific, WordPress injects hentry via PHP [http://indiewebcamp.com/irc/2013-10-22/line/1382448759]. The bug with the wordpress mf2 plugin is resolved as of [http://indiewebcamp.com/irc/2013-10-22/line/1382449035 2013-10-22] --[[User:Barnabywalters|bw]] 13:38, 22 October 2013 (UTC)

=== e- and p- escaping levels ===
<div class="discussion">
* The fact that the parsed value of any element with .e-* is at a different level of escaping to the parsed values of p-*, dt-* etc. without any indication of how the property was parsed in the output is a security problem. For example:

<table style="width: 100%">
<tr>
<th>input</th>
<th>output</th>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="p-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="e-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
</table>

* As a parser developer, the most straightforward way I can think of solving this is to add an option (enabled by default) which encodes HTML special characters on all non e-* properties, so the developer knows that all property values are going to be at the same level of escaping. --[[User:Barnabywalters|bw]] 20:00, 15 June 2013 (UTC)
** Your suggestion of auto-HTML-encoding p-*/u-*/dt-* property values is the most sensible I think. I would NOT make it an option, as it makes sense write consistent microformats2 consumers. - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
** Can you think of any existing apps/consumers of microformats2 via the parser that would break? What would indieweb comments parsers do? - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
*** The only breakage which might occur would be over-encoding of non e-* properties, but I’ll release this update as v0.2.0 and warn people about the changes. The worst thing which could happen is that some comments look a bit weird, as opposed to the current worst possible scenario of easy XSS attacks --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** We should also decide exactly which characters get encoded — just angle brackets, or quotes/ampersands as well? --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** I am not sure about this, it seems more like a helper function rather than a core feature of the parser. Personally I would like to store data as text and encode only when I am going to use and I known the format it is going to be use in. --[[User:GlennJones|Glenn Jones]] 9:54, 14 July 2013 (UTC)
***After the discussion on the indiewebcamp IRC with Barnaby Walters I now understand the XSS issue that this change is trying to address. A rogue author could include HTML with scripts to execute a XSS attack. These could be masked by switch prefixes i.e. p-* to e-* on a well use property. As the consumer does not see the prefix in the JSON output they have no idea if a property will content HTML or text. I will update my two parsers and the test suite --[[User:GlennJones|Glenn Jones]] 8:02, 17 July 2013 (UTC)
**So what about an author setting a property to e-* when it would normal be p-*, dt-* or u-* i.e.
<source lang=html4strict>
<div class="h-card"><p class="e-name"><script> alert('xss test') </script></p></div>
</source>
** per [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]], parsers should never automatically attempt to HTML-special-characters encode - as that would provide the client of the parser a false sense of security. It's *always* up to client code to escape any text being output to HTML *at the moment it is output to HTML* and never before, because they can never trust that any text from storage/elsewhere has for sure been escaped or not. - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** Should we not encode e-* as well and the consumer can decode at their own risk --[[User:GlennJones|Glenn Jones]] 18:42, 21 July 2013 (UTC)
*** No, never, per above point from [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** See [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] etherpad: https://etherpad.mozilla.org/microformats2parsing for more details on the resolution to this issue - and incorporate here (then move to resolved section below). - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
* Resolved by changes to the parsing spec: all properties are plaintext (non-HTML escaped), e-* properties result in a dictionary with <code>value</code> = plaintext version, <code>html</code> = raw HTML version
----

</div>

=== br hr empty string ===
<div class="discussion">
* The parsing rule 'else if br.p-x or hr.p-x, then return "" (empty string)' for p-* can cause any code consuming the API to become quite bloated. It means that you have test every array value to see if its an empty string. It is also unclear to me what the purpose of this mark-up pattern is for [[User:GlennJones|Glenn Jones]]
** Upon reconsidering this, I agree with you, this is an unlikely use case. If a publisher wants to explicitly set an empty property "p-foo" they can simply write <code><span class="p-foo"></span></code> which looks explicit. Whereas BR and HR tags are often just presentational, so we should both not encourage usage of them for semantics, and anyone that did use them would be subject to likely loss of semantics upon a redesign (that got rid of those particular BR and HR tags). I'm going to remove them from the parsing spec. - [[User:Tantek|Tantek]] 15:29, 10 February 2013 (UTC)
</div>

=== datetime examples without T delimiter ===
<div class="discussion">
* The examples in the wiki microformats-2 pages such h-entry and h-entry had datetime without the 'T' delimiter between date and time. ie
<source lang="html4strict">
<time class="dt-published" datetime="2013-06-13 12:00:00">13<sup>th</sup> June 2013</time>
</source>
I have updated the pages. As far as I known this is a new pattern for dates. Was it a mistake in the examples or is it a new datetime pattern.
** The [[HTML5]] "time" element, and "datetime" attribute allow for space <span style="white-space:nowrap">" "</span> as a separator between date and time as well as "T", thus we allow it for microformats as well. The <span style="white-space:nowrap">" "</span> separator is preferred as the date and time are more readable when separated by a space. The examples noted in those specs deliberately use this. - [[User:Tantek|Tantek]] 18:48, 15 July 2013 (UTC)
</div>

=== rel-alternate absent optional attributes ===
<div class="discussion">
* What should rel-alternate parsing do when one of the optional attributes specified (<kbd>hreflang</kbd> or <kbd>media</kbd> or both) is not there? The options seem to be:
*# leave the corresponding key out of the alternate JSON object
*#* This one. Leave the corresponding key out.
*# include the corresponding key in the alternate JSON object, but set the value to the JSON null object
*# include the corresponding key in the alternate JSON object, but set the value to a blank string
*# something I haven't thought of

I haven't checked the existing implementations, but Barnaby said he's not sure what the appropriate way to deal with it is either. —[[User:TomMorris|Tom Morris]] 15:41, 9 August 2013 (UTC)
</div>

=== rel-alternate and type attribute ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Should rel-alternate parsing also pick up the <code>type</code> attribute? It’s fairly widely used, e.g. for ATOM feeds.
** Numerous existing sites/pages have various [[rel-alternate]] uses with a type attribute for feeds/APIs so that's good enough to add this for help with discovery in general. Rel parsing updated. - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
</div>

=== Extraction vs Interpretation ===
Issue raised by: [[User:BenWard|Ben Ward]]

A microformats ‘1.0’ parser performs the following function:

* Given a piece of HTML content, discover a known microformat, extract it, apply various extraction patterns based upon the HTML mark-up used (e.g. include pattern, <code>abbr</code> patterns, date-time patterns, value-title pattern), apply various content optimisations where applicable, and return the result in an object native to the programming language.

This is performing two types of function: Extraction of data from an HTML document or fragment, ''and'' interpretation and optimisation of that content to match the rules set out by a vocabulary specification.

It is only possible to write a generic parser that covers the first half of this task: Extraction, and application of global rules based on HTML elements and patterns common to all formats.

The purpose of a generic parser (as supported by use cases such as search engines, and other crawlers) is:

To provide a way for tools to extract rich data from a page for native storage, such that the data may be interpreted later by applications. This allows microformats to be crawled, and indexed, and removes the need to include complex HTML parsing within every implementation of microformat data.

Microformats will continue to define various vocabulary-specific optimisations. as part of the design to be optimised for authors. For example: The <code>fn</code> pattern in [[hcard]], or the <code>lat;long</code> pattern in [[geo]], as well as default values for properties, such as the maximum rating in an [[hreview]].
* Actually, no, as it is defined currently, microformats 2 ''drops'' vocabulary-specific optimizations. Such optimizations have often been too inapplicable, error prone or i18n-unsafe (e.g. fn to given-name + family-name fails for both numerous cases where middlenames/initials are used, and in general in numerous Asian languages where given/family name order is the reverse of Western English conventions, or languages with multiple family-names, e.g. Spanish - see [[hcard-issues-resolved]] for more). This is a deliberate cutting of a "feature" from microformats 1, it is a deliberate model simplification design decision. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

==== Extraction resolution ====
Proposed resolution:

Microformats2 should refer only to ''extraction'' of microformats. Vocabularies should in turn document their appropriate optimisations, which will need to be applied by implementations, or a companion to an extractor, which I'll refer to here as an ‘interpreter’.
* Vocabularies will no longer have optimizations, this is again deliberately, as they've been shown to be more error prone than helpful. Thus there should be no need for any vocabulary-specific 'interpreters'. However, due to design quirks in various legacy/interchange formats, ''export conversions algorithms'' to those legacy/interchange formats will require some additional legacy-format-specific rules (e.g. odd "required" rules in [[Atom]] or [[vCard]] will require specific synthesis rules, limitations in said formats will require filtering of some values, e.g. [[vcard3]] BDAY disallows vague birthdays like year-month and --month-day - subsequently allowed in [[vcard4]]). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

A microformats2 ‘extractor’, in combination with the functionality of a domain and format-aware ‘interpreter’ (either another shared component, or part of the implementation itself) would be equivalent to a microformats 1.0 ‘parser.’
* A microformats2 parser is both generic (no knowledge of specific vocabularies), and lacks any/all such vocabulary-specific rules as compared to a microformats 1.0 [[hcard-parsing|parser]] with the exception of a 1) a limited list of well-established/interoperable backward compat root class names (of current [[microformats]] that are or can be soon shown to be specifications/standards per the [[process]]), 2) flat sets of backward compat property names (some with prefix/name specific conversion) for each of those backward compat root class names. This is a deliberate design decision that makes microformats 2 more "micro", and yes this means that even with such backward compat support, this simple form of backward compat may mean that some existing microformats 1 content breaks. We'll assess those and iterate on a documented case-by-case basis rather than attempt to maintain theoretical 100% backward compatibility (since many current microformats format-specific-features are either unused, or may have caused more problems than solutions). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

N.B. I'll rewrite some of these as [[microformats2-parsing-faq]] to help better clarify. The reasoning that led to most of these design decisions is documented in the [[microformats-2#About_This_Brainstorm|microformats 2: About This Brainstorm]] section and following sections. I'll recheck those sections to see if/where reasoning for some of the above noted design decisions may have been missed, and back-fill accordingly. This is necessary because [[microformats2]] is a evolutionary result of simultaneously addressing both numerous generic [[issues]] as well as various common [[hcard-issues-resolved|format]]-[[hcalendar-issues-resolved|specific]] [[mfo|problems]] in microformats1 syntax and vocabularies. The very number of changes may make it more challenging (from a microformats1 perspective) to see why any particular design change has been made. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

This issue can be moved from resolved to closed once the above-mentioned write-ups have occurred.

===Parsing properties from rel attributes===
tl;dr resolution: As of 2013, [[microformats2-parsing]] handles parsing all link and a href rel values at document scope level, and producing canonical JSON accordingly. - [[User:Tantek|Tantek]]

Issue raised by [[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC):

* Currently, hAtom parses `bookmark` as a permalink
* Various microformats parse `rel=tag` as tags
* The current proposal for parsing does not allow parsing properties from rel attributes.

Microformats parsers could instead extract ''all'' link relationships from rel attributes within an microformat object, parsing them as if a u- prefixed property.
* Minor nit: Rather than same as a u- prefixed property, I think such "rel" properties should be parsed purely from the <code>href</code> attribute on <code><a></code> and <code><area></code> elements and nothing more. I would strongly disagree to extending rel to apply to other elements with URLs like img src, object data, or to apply to elements in general like div. That's the path that RDFa has taken and caused much confusion as a result. [[User:Tantek|Tantek]] 07:39, 5 October 2011 (UTC)
** Agree: That seems like a perfectly reasonable restriction. --[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)

This results in:

* Continuing use of the <code>rel</code> attribute in HTML, thereby building on HTML semantics rather than bypassing them or ignoring them in favour of something less meaningful.
* Parsing hAtom objects contain a property named <code>bookmark</code>, in place of <code>permalink</code>.
* All microformats that use <code>rel-tag</code> would contain a property named… <code>tag</code>. Perfect.

Since <code>rel</code> attributes are not overloaded for other functionality like class is, and other uses of <code>rel</code> within content are low (and non-semantic uses are nil, to the best of my knowledge) the risk of property pollution would be extremely low.

Note, with regard to this last point, that a generic microformats parser ''will'' parse false-positive properties, and ''will'' parse objects in combined chunks, rather than individually by format. Extracted objects will often not represent a vocabulary without further processing.

<div class="discussion">
* This sounds like it might be workable. Let's try it and see how well authors "get it". - [[User:Tantek|Tantek]]
* Possible issue: do we have any collisions between class property names and rel names? (I don't think so offhand, but useful to ask the question). - [[User:Tantek|Tantek]]
** None that I can think of in microformats. There is the case of Google's <code>rel=author</code> and <code>p-author</code> in hAtom. However, the next point, about mfo scoping, would cover it in most situations (rel-author on a hyperlink within an hcard wouldn't be applied to the hentry.) The one situation in a parse tree where it's ambiguous would be this:
<source lang=html4strict>
<a href="p-author h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
** I can think of two quite reasonable solutions:
*** 1. Declare that class properties take precedence over rel properties of the same name, discarding rel values if a class is also found, or
*** 2. Since all properties are now multi-value anyway, the hAtom object could be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
** —[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)
*** Option 2 makes sense and is consistent with the rest of the multi-value parsing/handling. - [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
*** What about without the 'p-author'?
<source lang=html4strict>
<a href="h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
Should that be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
Or
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': 'http://benward.me' /* from the rel="author" */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},

],
…
}
}
</source>
*** And if the former, then we're presumably saying that the value parsed due to the presence of a rel is always its own value, and does not combine with any other structures. I am fine with this, but I wanted to make sure we are ok with that explicitly. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
**** +1 I think that since the rel attribute is specifically concerned with the relation to an href attribute, it should not be combined with other structures that are rightly declared uses classes.
***** The more I've thought about this and how consuming applications may want to treat rel semantics, the more it seems correct to keep rel semantics distinct from class semantics. Class semantics are quite general/flexible, whereas rel is quite specific, naming something else in terms of a relationship from the current page/microformat's perspective. I think we should consider putting rel values in their own 'rel' collection, separate from the 'properties' collection. E.g. the original rel-author p-author h-card markup example would be parsed into this:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
}
],
…
}
'rel': {
'author': ['http://benward.me'] /* from the rel="author" */
}
}
</source>
***** and if a post had multiple authors:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from p-author */
'type': ['h-card'], /* from h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
{
'value': ['Tantek Çelik'], /* from 2nd p-author */
'type': ['h-card'], /* from 2nd h-card ... */
'properties': {
'name': ['Tantek Çelik'],
'url': ['http://tantek.com']
},
],
…
}
'rel': {
'author': [
'http://benward.me', /* from rel="author" */
'http://tantek.com' /* from 2nd rel="author" */
]
}
}
</source>
***** This preserves the semantic distinction between rel and properties in general, and leaves it up to a higher-level application to implement any logic around showing "more info" about a rel-author, e.g. by correlating the rel-author URL with the 'url' of an hCard it found in the same entry. However, note that even in the earlier JSON data model, the rel-author value just shows up as another property value, and any higher level application would still have to do some correlation logic. At least with this JSON data model, applications that may be looking for a rel value in particular, or a property value in particular can do so without having one unintentionally pollute the other. [[User:Tantek|Tantek]] 17:33, 6 October 2011 (UTC)

* Presumably we'd apply all the same property scoping rules to rel scoping as well. E.g. a rel hyperlink inside a microformat won't be seen by any containing microformat. - [[User:Tantek|Tantek]]
** Correct, it should be parsed in the same scope as all other class properties in the object.
*** Update: all rel microformats are now parsed at page-scope. Per-microformat scoping of rel has been found to be too confusing in practice (and against the general semantic of rel expressed in the HTML/HTML5 specs) [[User:Tantek|Tantek]] 01:00, 10 July 2014 (UTC)

This issue can be moved from resolved to closed once we've verified that all the above-mentioned and implied needs to write things up have occurred.
</div>

=== deduping of rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-02 by [[User:Kevin Marks|Kevin Marks]]
* 2015-06-05 resolved by consensus and one real world implementation proof of implementability and verification of expected results. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

Many sites have multiple duplicate rel links to the same url - a very common case is WordPress home pages eg [http://ma.tt ma.tt]

Each post on the page has a block like
<code><pre>
<div class="entry-meta">
<span class="date">
<a href="http://ma.tt/2015/05/beethoven-mozart-bach/"
title="Permalink to Beethoven, Mozart, Bach" rel="bookmark">
<time class="entry-date" datetime="2015-05-31T22:42:00+00:00">May 31, 2015</time></a></span>
<span class="categories-links">
<a href="http://ma.tt/category/asides/" rel="category tag">Asides</a></span>
<span class="author vcard">
<a class="url fn n" href="http://ma.tt/author/saxmatt/"
title="View all posts by Matt" rel="author">Matt</a></span>
</div></pre></code>

As currently defined, the parser will create duplicate entries in <code>rels</code> for each post:
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/",
"https://ma.tt/"
],
}
</pre></code>

and in the <code>rel-urls</code> we will also see:
<code><pre>
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author",
"author",
"author",
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home",
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag",
"category",
"tag",
"category",
"tag",
"category",
"tag"
],
"text": "Asides"
}
</pre></code>
These duplicates are unhelpful for parser consumers. We should:
* make them both sets - only listing distinct values. This will remove ordering information, but order is irrelevant for rel in html.
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/"
],
}
…
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag"
],
"text": "Asides"
}
</pre></code>

* possibly we could also make <code>title</code> <code>text</code> <code>type</code> sets too. That would solve the information loss issue with the current parsers
** Resolution: in the case of duplicate other attributes, first one set wins. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

<div class="discussion">
* +1 as the proposer. A version of mf2py that does this is running at unmung,com. see [http://www.unmung.com/mf2?url=https%3A%2F%2Fma.tt&html=&pretty=on fro ma.tt] or [http://www.unmung.com/?html=%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E&pretty=on a simple test] [[User:Kevin Marks|Kevin Marks]] 23:49, 2 June 2015 (UTC)
* +1 makes sense to me, and not having them be sets in the current spec is likely an oversight on my part. Thanks for noting this issue. [[User:Tantek|Tantek]] 05:28, 3 June 2015 (UTC)
</div>

=== include alternates in rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 resolved per consensus and one real world implementation proof of implementability. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* add "alternate" rels to the "rels" collection to make them easier to look-up in "rel-urls" - that is, all rel values end up in "rels" collections. No exceptions.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls".
* +1 This makes sense to me, as the <code>rels</code> and <code>rel-urls</code> should match so you can lookup in rels first, then get details about urls from rel-urls. We can drop "alternates" independently from this change. [[User:Kevin Marks|Kevin Marks]] 00:23, 2 June 2015 (UTC)
** +1 drop "alternates" independently now made a separate issue. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
* +1 Makes sense. And I agree with Kevin; I think parsers should deprecate "alternates" for now and drop it after a version cycle or two. [[User:Kylewm|Kylewm]] 00:30, 2 June 2015 (UTC)
* implemented in [https://github.com/kevinmarks/mf2py/commit/4dba45200eef11da811f64817d02044ab9e98b77 my fork of mf2py] and running on [http://www.unmung.com/?html=%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fa%22%3Eauthor+a%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fb%22%3Eauthor+b%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F1%22%3Epost+1%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F2%22%3Epost+2%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22alternate+home%22%0D%0A+++href%3D%22http%3A%2F%2Fexample.com%2Ffr%22%0D%0A+++media%3D%22handheld%22%0D%0A+++hreflang%3D%22fr%22%3EFrench+mobile+homepage%3C%2Fa%3E&pretty=on unmung] [[User:Kevin Marks|Kevin Marks]] 01:29, 2 June 2015 (UTC)
</div>

=== Empty properties overridden by implied rules against user expectation ===
Status: resolved, existing behavior correct, no changes to parsing spec.

2015-07-03: raised by [[User:Glenn Jones|Glenn Jones]]

Emma Kuo brought up an issue (https://github.com/glennjones/microformat-node/issues/22) based on following the indieweb note pattern, where the content of a note is given both the e-content and p-name classes. If the element containing the notes only has none text content like image the p-name can have unexpected value. Here is the example she gave:

<code><pre>
<div class="h-entry">
<a href="http://this.site/photo" class="u-url"></a>
<div class="e-content p-name"><img src="photo.jpg" class="u-photo"/></div>
Some extraneous text
<div class="h-cite">
<a href="http://someother.site/like" class="u-url"></a>
<a href="http://this.site/photo" class="u-like-of"></a>
<div class="e-content p-name">liked this</div>
</div>
</div>
</pre></code>

At the moment I parser this as follows: - if a property (p-name) is empty do not add it to the output. In this case "empty" is classed as not containing any non-whitespace text. As far as I known there is no guidance on how to handle "empty" properties in microformats paring rules, so I followed the conventions of JSON API's not to return "empty" properties.

The side effect of the above is that p-name also has a number of "implied rules". The "implied rules" try to automatically fill properties like p-name if there is no defined value. In the example above it uses the textContent of the parent h-entry, so value of the h-entry>p-name is the text content of the h-cite i.e. "likes this".

Options:

1. We should not allow the "implied name rule" to get textContent from within a child h-*
<div class="discussion">
* <strike>+1 I believe this is inline with how we parse properties and will meet user/author expectations [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* -1 A nested h-* is still part of the content of the parent h-*, I don't quite understand the rationale for excluding it. For example, I may include lots of h-cards in the body of a post that references people and wouldn't want them to be excluded from the implied name generation. [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* -1 I'm not sure this would solve the problem because auto-filled text could come from the parent h-* ("some extraneous text" in the example above) [[User:emmak|Emma Kuo]] 20:50, 4 July 2015 (UTC)
* -1 I agree with the other -1s. This would break some of the simplicity of the model. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
</div>
2. We should not execute the "implied rules" where there is an author defined "empty" property.
<div class="discussion">
* <strike>-1 Although the output would meet author expectations it is complex for parsers as they will have to keep state for each property through the whole series of parsing rules. [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* +1 An explicit, empty, p-name property should prevent an implicit p-name from being generated. For example tantek.com includes <span class="p-name"></span> at the start of the h-feed to prevent a giant name from being auto-generated. From my reading of the parsing spec, I don't see any reason that blank strings should be excluded from parsing. (mf2py and php-mf2 will both happily include empty strings in their output) [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* +1 We already have interop on this between mf2py and phpmf2, as well as people depending on it to explicitly set empty property values. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
* +1 As we already have interop with two parsers and solid user issue from Emma we should take this approach. [[User:GlennJones|Glenn Jones]] 11:51, 29 July 2015 (UTC)</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== uf2 children inside a classic microformats root class name ===
Status: incorporated into [[microformats2-parsing]]

2015-020: (raised by kylewm) What should microformats2 children inside a classic microformats root class name do?

Options:

1. Nothing. Any unattached uf2 children inside a classic microformats root are ignored. Problems:
<div class="discussion">
* However then there's a possible surprise if/when the author upgrades the classic microformats root to uf2, then all of a sudden all the new uf2 children show-up.
* Another downside: author adds uf2 markup, can't figure out why nothing is happening (because somewhere up the tree in code they didn't touch is classic microformats that are hiding these unattached uf2 children.
</div>
2. Show up in the children collection of the classic microformats root
<div class="discussion">
* Feels most predictable. When you add uf2 root class names anywhere, they will show up in the JSON output hierarchy.
* When you convert ancestor class microformats root class names to uf2 root class names, no surprise in terms of which microformats show up. Same children collection.
* +1 Thus I'm leaning towards this one, despite the fact that classic microformats never had a concept of generic unattached children. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)
* +1 I think this is the best option I will implement it and update the wiki once its in the JavaScript parser. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>
3. Show up as peers to the classic microformats root. Issue(s)
<div class="discussion">
* Has ths surprise aspect of if/when you convert the classic root class name to a uf2 root class name, the former peers become unattached children.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== any h- root class name overrides and stops backcompat root ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: The presence of any h-* root class name overrides and stop any backcompat parsing of classic microformats root class names on that same element. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for restricting backcompat root class name to only seeing backcompat property class names
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
* I don't think I understand this rule. If I was stop all parsing of of classic microformats in the presence of any h-* root in a document then some of the other rules such as "uf2 children inside a classic microformats root class name" do not make sense. Could this item be expanded and explained a bit more? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** added "on that same element" as that was what we were discussing/implying in this issue. [[User:Tantek|Tantek]] 22:49, 18 September 2015 (UTC)
</div>

=== backcompat classic microformats should only see backcompat properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats vocabulary that indicates a backcompat root class name (and thus an absence of the microformats2 equivalent on the same element), parsers must only look for the backcompat properties that are specified explicitly for that backcompat root class.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such behaviour was never expected by authors, and crossing a classic microformats root class name with microformats2 property names were never explicitly expected nor specified to work.

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== microformats2 root class names should only see microformats2 properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats2 root class name, only explicit microformats2 properties should be parsed. Any backcompat property names must be ignored.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such microformats2 authors should be expected to do all their microformats markup with microformats2 class names - this is a deliberate expectation so that their microformats aren't polluted with other (classic microformats) coincidentally named generic class names.

Thoughts?
<div class="discussion">
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== implied properties on backcompat parsing unlikely to be intended ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
Since classic microformats had no notion of implied properties, when implied property parsing occurs on backward compat classic microformats root class names, it is unlikely that any implied property (p-name u-url u-photo) was ever intended by the author of the classic microformat. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
Examples:
* see https://indiewebcamp.com/h-entry#bad_hentry_properties for a growing list

'''Proposed resolution:'''

* Be explicit in implied property parsing that it must only be done for explicit 'h-*' root class name microformats, not for any (back)compat parsing of microformats. Please comment on this proposal with "** comment" on new lines below. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
** +1 This makes a lot of sense to me. We should strive to parse mf1 as it was intended by the author, and I think you're right that implied rules are unlikely to be what was intended [[User:Kylewm|Kylewm]] 03:22, 30 December 2014 (UTC)
** +1 I think this will help backcompat parsing, but there are two major things to consider. It may well break some consumer code as the output for a microformats currently always has the name property, there may not be the defences code to check this is true when we remove the implied name rule for classic microformats. The test suite will also need major updating as all the test output for classic microformats will have. I will look into implementing this and report back to the wiki. [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** Also it should be made clear that we are only removing the implied rules from classic microformats parsing and not the value property? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
*** The "parsing for implied properties" section only references name, photo, url properties. Where (in the spec) is the confusion about "value" coming from? [[User:Tantek|Tantek]]
** RESOLVED at [[2015-01-20]] meetup. [[User:Tantek|Tantek]] 04:09, 21 January 2015 (UTC)
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Set implied properties by microformat version"

=== link elements and u- parsing ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Raised by tantek on 2014-07-08 on [http://logs.glob.uno/?c=freenode%23microformats&s=8+Jul+2014&e=9+Jul+2014#c72916 irc]: should the parsing specification for handling u- properties be modified to include the <code>link</code> element? The potential downside is that [[invisible-metadata-is-considered-harmful]], however all known real world examples of <code>link</code> are <em>semi-</em>visible data (not fully hidden).

There are potential cases for wanting to use link as an alternative to <code>a</code> (and <code>area</code>), such as a whole page where the root <code>html</code> element is an <code>h-card</code> and the properties are included across the page: some in visible data in the <code>body</code> while others are in the <code>head</code> as <code>link</code> elements. Example:

One specific use-case is the semi-visible <code>link rel="shortcut icon" href="..."</code> - which is visible sometimes in browser UI, and also when a user chooses "Add to Home Screen" on a mobile device. Such page level icons may be used as a <code>u-photo</code> or <code>u-logo</code> of the containing <code>h-*</code> object on the <code>html</code> element.
* http://adactio.com/about/myself/ on 2014-190
** <em>could</em> use <code><html class=h-card></code> - page is all about Jeremy Keith the person
** <em>icon / logo is only</em> on <code><link></code> tag which <em>could</em> use <code>class=u-logo</code>: <br/><code><link rel="shortcut icon apple-touch-icon" type="image/png" href="/icon.png" /></code>

Another specific use-case is a post permalink page, e.g. with <code><html class=h-entry></code>
* http://waterpigs.co.uk/notes/4WjHpC/
** <em>has</em> <code><html class="no-js h-entry hentry h-as-note" lang="en"></code>

Another use-case is publishing links to PGP/GPG keys linked from the head which is currently handled by <code><link rel=pgpkey></code> which is already supported in existing [[microformats2-parsing#parse_a_hyperlink_element_for_rel_microformats|microformats2 rel parsing]] of <code>link rel</code> elements. Thus there is a (admittedly weak) argument for consistently parsing <em>both</em> <code><link rel></code> <em>and</em> <code><link class="u-*"></code>.

E.g. inside that aforementioned real world <code><html class=h-entry></code> post permalink page example,
* why should <code><link rel="in-reply-to"></code> work
* but not <code><link class="u-in-reply-to"></code> ?
The slightly stronger argument for consistency of link handling is that it <strong>[[simpler|simplifies]]</strong> the publisher (and parser) model:
* <code><a></code> and <code><area></code> work for both <code>rel</code> and <code>class</code>
* why does <code><link></code> only work for <code>rel</code> ?
* it would be <em>simpler</em> if all three tags just worked (in the same way) for both <code>rel</code> and <code>class</code>

'''Should the parsing spec be modified to handle these cases?''' —[[User:TomMorris|Tom Morris]] 09:25, 9 July 2014 (UTC)

** I'm generally in favour. It'd be good to see what other parser developers think. —[[User:TomMorris|Tom Morris]] 10:16, 9 July 2014 (UTC)
** adding this to the parsers won't be an issue. <del datetime="2014-07-09T18:45">The question is should the door be opened to hidden mf data?</del> <ins datetime="2014-07-09T18:45">Up on further reflection, there seems to be no need to distinguish between <code>rel=property</code> and <code>class=u-property</code> on link elements. So I am in favour for consistency.</ins> [[User:KP|Kartik]] 18:30, 2014-07-09 (EST)
** RESOLVED at [[2015-01-20]] meetup. Make link consistent with a.
</div>

=== drop alternates collection ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 split into separate issue from include alternates in rels per implementation feedback from Kevin Marks. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* drop "alternates" as its no longer needed, and all current consuming code clients like rel-urls better anyway.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls" in original issue now "include alternates in rels", we no longer need "alternates", and those with client consuming code have universally indicated that they would rather use rel-urls anyway. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
</div>

== see also ==
* [[microformats2-parsing]]
* [[microformats2]]

microformats2-parsing-issues

2016-03-13T20:56:11Z

Barnabywalters: /* uf2 children on backcompat properties */

This page is for documenting issues with the [[microformats2-parsing]] specification.

== issues ==
Open issues in various states of partial resolution from none to nearly resolved.

=== ignore u-camelCase properties ===
Due to Suit CSS (and others? citations?) recent (2015-?) use of "u-*" class names for so-called "[http://davidtheclark.com/on-utility-classes/ utility classes]", we are seeing some false positives in a few very rare instances, e.g.: http://www.unmung.com/mf2?url=http%3A%2F%2Fwww.kevinmarks.com%2Ftwitterutils.html&html=&pretty=on

(Nearly) all these "utility classes" use camelCase for the class name suffixes, thus we can filter them out by looking for camelCase (since microformats class name conventions are always all lowercase and hyphenated), or even just looking for (and rejecting) *any* capital letters.

Proposal:
* microformats2 parsers MUST IGNORE u-* classnames where the * has any uppercase letter(s).

<div class="discussion">
* +1 [[User:Tantek|Tantek]] Let's get this fix rolling quickly to avoid further pollution.
* +1 [[User:Barnabywalters|Barnaby]] php-mf2 already ignores classnames with capitalised prefixes, ignoring any classnames with capital letters seems totally reasonable
* ...
</div>

=== exclude style elements before parsing ===
[http://logs.glob.uno/?c=freenode%23microformats#c85457 2016-01-25 raised in #microformats]

Ran into an issue of a <style> element being parsed as plain text in a p-name. Should [[microformats2-parsing]] be updated to indicate <style> should be excluded when parsing? Appears to implicitly fall under [[microformats2-parsing#note_HTML_parsing_rules]]

Sample link: http://veganstraightedge.com/notes/2016/01/16/tonight-s-dinner-tacocleanse-beverly-hills-c

The <script> tag can be similarly problematic.

Proposal: Drop both <script> and <style> elements completely when parsing any property (including e-* HTML values). [[User:Tantek|Tantek]] 01:01, 29 February 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Aaronpk|aaronpk]] as a consumer of HTML from an e-* property, I will always be sanitizing the HTML and removing <script> and <style> anyway
* +1 [[User:Kylewm|kylewm]]
* 0 [[User:Barnabywalters|Barnaby]] +1 to removing the contents of <script> and <style> from all plaintext properties (and 'value' property in HTML dicts), -1 to removing <script> and <style> from HTML. That’s a job for a sanitization stage. As aaronpk points out, sanitization will have to be done anyway if the content is to be reposted, so doing so in the parser doesn’t actually save anyone any work, but removes information which could be useful to people (example use cases: publishing posts with embedded per-post styling, publishing interactive HTML documents with embedded javascript)
** +1 this seems like reasonable feedback to make a new refined proposal. [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)
</div>

Proposal 2: Drop both <script> and <style> elements completely when parsing any property (except for e-* HTML values, which preserve all markup). [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Barnabywalters|Barnaby]
* ...
</div>

=== use poster if no src on video for u props ===
[https://indiewebcamp.com/irc/2015-12-13#t1450035721661 2015-12-13 raised in #indiewebcamp]

There is a use-case of marking up the "poster" of a video element as the u-featured of an [[h-entry]], to do that, we need to change [[microformats2-parsing#parsing_a_u-_property|u- property parsing]] to look at the poster attribute of the video element, after it's looked for the src attribute.
<blockquote>" else if video.u-x[poster], then get the poster attribute "</blockquote>

Real-world example of markup in the wild:
* http://veganstraightedge.com/videos/2013/5/31/1/backyard-squirrel-buddy
** and likely all other videos posted there.

Background discussion that led to this proposal:
* https://indiewebcamp.com/irc/2015-12-13#t1450035721661

This seems very straightforward so I've added it as PROPOSED directly in the parsing spec. This issue is for tracking the discussion.

Feedback from parser implementers please!
<div class="discussion">
* +1 [[User:Barnabywalters|Barnaby]] easy to implement and based on real-world markup, no objections
* ...
</div>

=== uf2 children on backcompat properties ===
[http://logs.glob.uno/?c=freenode%23microformats&s=today#c84632 2015-11-24 raised by Calli] in #microformats

Related but different from [[#uf2_children_inside_a_classic_microformats_root_class_name]], when there is a uf2 child directly on a backcompat property, what should happen? E.g.

<source lang=html4strict>
<div class="vcard">
<div class="adr h-adr">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

What is the expected behavior and parser output?

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-adr"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

<div class="discussion">
* Proposal: the nested "adr h-adr" child is treated as an mf2 object, not backcompat, and thus the resulting parsed "locality" property has a single value of "MF2". Proposed by Calli, noting that Glenn Jones's microformatshiv gets that result currently, and it would be easier for him (Calli) to implement this way.
** +1 Tantek, seems reasonable and the reasoning provided is good (we have one implementation this way already)
** +1 Kyle, this is consistent with the resolution to the related issue
** +1 Calli, yes, this is easier for me to implement (than taking both MF1 and MF2 properties) because it is consistent - for me, consistency is the controlling factor in favor rather than ease of parser implementation
** +1 Barnaby, php-mf2’s mf1 backcompat produces this exact result, and it makes a lot of sense to me
** ...
</div>

Another example:

<source lang=html4strict>
<div class="vcard">
<div class="adr h-custom">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-custom"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

Per the [[#any_h-_root_class_name_overrides_and_stops_backcompat_root]] resolution, the class name "h-custom" overrides the use of "adr" as a backcompat root.

=== default generated HTML ===
2015-09-08 raised by Tantek in #indiewebcamp

Should there be a default (perhaps not quite "canonical") way to map/generate HTML+microformats2 from a parsed mf2 JSON output?

E.g. straw proposal:
* JSON/mf2 -> [[XOXO]]+mf2

Existing work / mappings:
* https://github.com/snarfed/granary/blob/master/granary/microformats2.py#L295

Related to:
* https://github.com/snarfed/granary/issues/31

Use-cases:
* default webview / presentation for a site that stores mf2 JSON output
* possibly a way to implement a distributed HTTP webcache retrieval protocol

Thoughts?
<div class="discussion">
* +1 [[User:Tantek|Tantek]] I think we should have this, but am open to proposals on specifics!
* +1 [[User:GlennJones|Glenn]] Also think this is worth looking at, but I am not sure it should be part of the parser spec. Feels like it should be built as a separate library and have it own spec on the microformats wiki.
* ...
</div>

=== Noscript skip/parse ===
2015-07-28

Should mf parsers skip <code><noscript></code> tag in the HTML, like the <code><template></code> tag mentioned in http://microformats.org/wiki/microformats2-parsing#note_HTML_parsing_rules ?

mf2py skips <code><noscript></code> when using the html5lib DOM parser but no when using lxml parser. Example use of <code><noscript></code> https://kartikprabhu.com/ featured images have a no javascript fallback image inside <code><noscript></code> with <code>class='u-featured'</code> markup.
* html5lib actually HTML-escapes the contents of <code><noscript></code>, so to mf2py it just looks like plain text with no tags. In Woodwind, I've resorted to using regex to strip out <code><noscript></code> tags before parsing (very hacky). [[User:Kylewm|Kylewm]] 15:52, 25 August 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] skip noscript (and inside) because in today's typical browsing contexts, nothing in noscript is displayed, thus we should discourage marking up effectively invisible content.
** Proposed change to [[microformats2-parsing#parse_a_document_for_microformats]]:
*** from: "follow the HTML parsing rules"
*** to: "follow the HTML parsing rules (including skipping/omitting <code><noscript></code> elements, e.g. like the html5lib DOM parser)
* -1 [[User:GlennJones|Glenn]] This subject does need to be address, but differently to proposed change. My personal view is that e-* html should be passed through raw and then the consumer can process it in a way they feel fit. Its a case for helper libraries. I am about to build a helper library to do this based on the Readability code to post process e-* html. Other people may want to take different approaches, defining this in the spec feels like move into a whole area of new functionally.

As a separate new point we need to consider "exclude tags" lists for parsed text from html. We should consider <code><noscript></code>, <code><noframe></code> and <code><template></code> there maybe other I have not gone through all the tags in current HTML spec. Also we should consider what to do about the more common pattern of fallback text within media tags <code><video></code>, <code><audio></code> etc. This should be explicitly discussed in the parsing rules. At the moment my experimental text normalisation does exclude tags, but the default text parse does not. Currently the fallback content in media tags like <code><video></code> is added to the parse text. 12:56, 25 Septemeber 2015 (UTC)
* ...
</div>

=== Standard datetime format ===
2015-07-28

http://microformats.org/wiki/microformats2-parsing#parsing_a_dt-_property does not specify any standard format to use for datetimes. e.g. <pre>2015-07-28T12:55:33</pre> vs <pre>2015-07-28 12:55:33</pre>
Would be good to standardize this to compare various parser outputs.

2015-07-29: This subject is (somewhat) covered in http://microformats.org/wiki/iso-8601 As it stands the JavaScript parsers support output in the 3 main profiles, 'W3C Note', 'RFC 3339' and 'HTML5' plus 'auto' which keeps authors format. The default date output for the JavaScript parsers is the same format as the date was originally authored in. This can be changes by setting the options.dateFormat switch to any of the other profiles mentioned. It would be good if other parser also had a switch to force output to a common profiles so we could compare various parser outputs, but I think the default should be how a date was authored. All output whatever profile should also keeps the authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string. This is important if you want to compare parser outputs.

The only exception to this where date and times are combined such as the implied h-event rule for dt-start and dt-end where I output in the HTML5 style 2015-07-29 12:55:33 as there is no predefined author preference and HTML5 profile is more human readable. [[User:GlennJones|Glenn Jones]] 11:02, 29 July 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] output more human readable <code>2015-07-28 12:55:33</code> canonically, with authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string.
** Let's update any test cases as needed for this. - [[User:Tantek|Tantek]]
* ...
</div>

=== implied date for dt properties both mf2 and backcompat ===
The [[value-class-pattern#microformats2_parsers|value class pattern dt-* date proposal]] should apply to both mf2 dt-* properties, and backcompat classic microformats, to preserve the hAtom / hCalendar optimizations noted on that page, but in a generic way.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] 16:12, 18 August 2015 (UTC)
* +1 [[User:Glenn Jones|Glenn Jones]] 20 August 2015
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== implied properties when an explicit class is provided ===
<div class="discussion">
Should "u-url" still be implied if another explicit class is already provided, as below. This is a contrived example, but it is taken from Bridgy's unit tests.

<code><pre>
<article class="h-entry">
<a class="u-like-of" href="http://orig.domain/baz">liked this</a>
</article>
</pre></code>

In this case, http://orig.domain/baz is almost certainly not the u-url, so IMO it would be better to leave it out —[[User:Kylewm|Kylewm]] 15:10, 7 October 2014 (UTC)

'''2015-01-20 consensus'''
* Changed my mind. Simpler to do nothing. Example provided is artificially constructed, does not reflect likely real world confusion of if we make implied properties more complicated. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
* ++ Consensus on do nothing for this case. At [[2015-01-20]]

'''Proposed resolution:'''
* Changed again. Due to indiewebcamp.com/edit use-case, this now makes sense for all implied properties. That is:
** If an element has any explicit property class name(s) on it, then it must not be used to imply any properties. [[User:Tantek|Tantek]] 20:50, 27 May 2015 (UTC)
*** +1 this seems reasonable, if a publisher is going to add an mf2 class, it is unlikely they want other classes automatically implied from the same value [[User:Aaronpk|Aaronpk]] 23:19, 29 November 2015 (UTC)
*** -1 for now. To my knowledge, this has only been observed in artificially constructed unit tests and examples, and it adds some weird edge cases that are hard to reason about. [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** ... provide input on this proposal here
** Refined: Or should this be refined by per parsing prefix? [[User:Tantek|Tantek]] 22:59, 18 September 2015 (UTC)
*** Any explicit "p-*" property means no implied "p-name" from that element
*** Any explicit "u-*" property means no implied "u-url" nor "u-photo" from that element.
*** ... provide input on this refined proposal here
** Suggestion: split this issue up per property. I think it makes sense for u-url and can be easily added to the spec as e.g. ".h-x>a[href]:only-of-type:not[.h-*<strong>,.u-*</strong>]". [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** Obviously wrong to assume a link explicitly pointing elsewhere is our "url"
*** More difficult to make a case for photo and especially for name.
*** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
*** ... provide input on this refined proposal here
</div>

=== whitespace collapsing revisited ===
2015-05-27: (raised by [[User:Kevin Marks|Kevin Marks]] per Glenn Jones)

Revising the microformats tests to conform to the "don't collapse whitespace" rule below reveals some non-intuitive cases.
preserving whitespace in addresses is somewhat defensible, but in an implied name it is often unhelpful, as it preserves non-user visible space there for authoring reasons.

For example:
[https://github.com/microformats/tests/commit/a325e0e9bc2089507e69b1883f7065a3316e07c2#diff-d577012c1438978a571c4049179607f0 this test] shows how extraneous whitespace ends up in the <code>name</code>

<code><pre>
<div class="h-review-aggregate">
<div class="p-item h-event">
<h3 class="p-name">Fullfrontal</h3>
<p class="p-description">A one day JavaScript Conference held in Brighton</p>
<p><time class="dt-start" datetime="2012-11-09">9th November 2012</time></p>
</div>

<p class="p-rating">
<span class="p-average value">9.9</span> out of
<span class="p-best">10</span>
based on <span class="p-count">62</span> reviews
</p>
</div>
</pre></code>

give a parsed result of:

<code><pre>
{
"items": [{
"type": ["h-review-aggregate"],
"properties": {
"item": [{
"value": "Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012",
"type": ["h-event"],
"properties": {
"name": ["Fullfrontal"],
"description": ["A one day JavaScript Conference held in Brighton"],
"start": ["2012-11-09"]
}
}],
"rating": ["9.9"],
"average": ["9.9"],
"best": ["10"],
"count": ["62"],
"name": ["Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012\n\n\n9.9 out of \n 10 \n based on 62 reviews"]
}
}],
"rels": {}
}
</pre></code>

The <code>value</code> is a reasonable textual representation of the event, but the implied <code>name</code> is full of spurious whitespace that any consumer would have to strip.

[https://github.com/microformats/tests/commit/4c9690b53b0a2f40440abac8e609c51ac7dd6d56 h-review] has similar issues

2015-05-28: (Addition by [[User:GlennJones|Glenn Jones]])

The example below shows the type of markup most effected by the "implied name" and "don't collapse whitespace" rule working together to produce output that is hard to use without further processing.

<code><pre>
<a class="h-card" href="http://glennjones.net">
<span class="p-given-name">Glenn</span>
<span class="p-family-name">Jones</span>
</a>
</pre></code>

The output for the name property from the above HTML would be <code>Glenn\r\n Jones</code> using the (trim lead/trailing) suggested in the parsing spec. I could of course move the spans onto one line, but it feels fragile to consider whitespace sensitivity in HTML like this. Added to the fact that HTML templating environments often take away that level of whitespace control from authors anyway.

There are issues with both: keeping whitespace, returns and tabs from parsed HTML or collapse that whitespace. If we return the whitespace it becomes mal-formatted for humans because it was only added to make the HTML code understandable and in most cases was not meant to be used/read outside of that context. If we collapse the whitespace we can have issues of whitespace sensitive text from <code><pre></code> etc. being incorrectly formatted.

Providing a CSS aware innerText feature would produce the most useable output, but this is too complex/time consuming to build for most parser developers. In the face of no perfect solution I have taken the 80:20 view, whereby errant whitespace, causes me considerably more problems than mal-formatted <code><pre></code> content so I collapse whitespace on all text returned.

This feature is a non-CSS aware version of innerText. It does not cover all rendering edge cases, but enough to produce practical output.

For now, I have started changing the node parser to flag "white-space collapsing" as an experimental feature which is off by default i.e. http://glennjones.net/tools/microformats/ but personally I will parse everything with this on as I find it the most practical solution.

Not sure where that leaves me on the options below.

Options:

Choose from:
# keep as is and every parser client has to post process for common cases.
# '''keep as is but have mf2 parser trim leading/trailing whitespace (likely to provide desired result and be reasonably backcompat)'''
#* +1 my preference of the two options. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
#* +1 though this doesn't solve any of the problems discussed above, it's still worth doing [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
#* +1 will help parsers be more consistent with each other, and I haven't ever encountered a case where preserving leading/trailing whitespace was desirable [[User:Kylewm|Kylewm]] 20:45, 8 June 2015 (UTC)

2015-06-08 option 2 resolved by consensus and implementation in mf2py.

Somewhat orthogonal:
* make <code>value</code> on properties with children normalise whitespace
** -1 Seems like a bad idea as this "value" is supposed to be the same as if there was no embedded child microformat. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
* make implied <code>name</code> normalise whitespace.
** +0 This is reasonable and already done somewhat in the parsing spec (trim lead/trailing). [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** +1 Given the universality of name, this would fix most of the issues we see. [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
* Put \n in textual forms if there is a <code><p></code> tag in the original.
** -1 that's a long path to go down with whitespace equivalents for HTML markup. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** would only preserving whitespace if in <pre> be an 80:20 compromise? [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)

Because there are both code markup and specific vocabulary (label) needs for preserving whitespace, we are compelled to preserve in general, perhaps except for very specific limited generic cases (e.g. trim leading/trailing, "value" parsing, implied name). [[User:Tantek|Tantek]]

=== u- parsing iframe src ===
Currently if I put u-* on an iframe it gets the value of the fallback text. This seems a shame. Getting the URL seems a sensible answer.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== i- parsing iframe src ===

More controversially, what about using an iframe for transclusion? A use case here is comments on a static site. Currently, on eg http://www.kevinmarks.com/microformatschema.html the comments are injected via JS, making them opaque to parsers and thus precluding further parsing such as salmentions.

If instead they were an iframe embedding them, a parser could optionally fetch its contents, parse them, and include them in the parsed mf2 output at that point. Overloading u-* for this seems wrong; e-* as below for srcdoc would have a different effect; this implies a new prefix directive would be needed. A strawman i-* (for include) may work.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== e- parsing iframe srcdoc ===
<div class="discussion">
* Proposal: addition of a new e-* parsing rule for iframe elements with srcdoc attributes. E.G.

<source lang="html4strict">
<div class="h-entry">
<iframe class="e-content" srcdoc="<p>A paragraph of HTML with "quoted quotes" &amp; doubly quoted ampersands</p>" />
</div>
</source>
<source lang="javascript">
{
"items": [{
"type": ["h-entry"],
"properties": {
"content": ["<p>A paragraph of HTML with "quoted quotes" & doubly quoted ampersands</p>"]
}
}]
}
</source>

This would allow, for example, HTML comments to be sandboxed inside iframes but still parsable as microformats.

I believe the correct processing would be to leave " entities as they are but to unescape any doubly-escaped ampersands.

** Is there any use case for that? —[[User:TomMorris|Tom Morris]] 12:32, 14 September 2013 (UTC)
** +1 we need documentation of use case and existing sites publishing iframe srcdoc like this - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
** Rejected by consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 properties on select ===
How should select elements with properties be treated any differently?

Awaiting real world examples / stronger use-cases, until then no special treatment of select elements with properties:
<div class="discussion">
* Are there any real world examples of select elements with microformats properties?
* What would the use-case be for putting a microformats property class name on a select element?
* Nothing special. By consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 root name on form ===
See what to do about <em>root class names</em> on <code><form></code> elements in particular:
* [[hcard-input]]

Awaiting real world examples / stronger use-cases, until then, no special treatment of root class names on <code><form></code> elements:
<div class="discussion">
* Are there any real world examples of a <code><form></code> element with a microformats root class name?
* [[hcard-input]] is one possible use-case, is anyone attempting to use forms for hCard input, e.g. with scripts to help make it work?
* Are there other use-cases for putting a microformats root class name on a <code><form></code> element?
* As of [[2015-01-20]] - no consensus - need more input as to when/why this is useful to do anything special.
</div>

===Parsing Literal Values===
Issue raised by: [[User:BenWard|Ben Ward]]

It is proposed for microformats2 that all microformats be parsable from just their root element, e.g. <code><p class="h-card">Ben Ward</p></code> would create an hCard with the following properties after parsing:

<source lang=javascript>
{
'type': ['h-card'],
'properties': {
'name': ['Ben Ward']
}
}
</source>

This is a four-fold change from the current [[hCard]]:
# type is generically identifiable as a microformat root, even in parsed form. The use of the 'h-' prefix persists into the type of the object. This is deliberately so, as a result of re-using the JSON data model of microdata which itself is re-using a common JSON convention, such that microformatted data is clearly distinguishable (as opposed to any other random schema that may be using a similar data model).
# root-class-only support. Per [[microformats-2-implied-properties]], the ''name'' property is implied by the entirety of the root class name element.
# 'name' instead of 'fn'. As also documented in [[microformats-2-implied-properties]], the continuous challenges/problems and need to repeatedly re-explain 'fn' over the years combined with the real-world market response of nearly every other party doing a person vocabulary renaming 'fn' to 'name', microformats 2 makes this change as well.
# There is no automatic parse-time inferring of <code>'given-name': ['Ben']</code> and <code>'family-name': ['Ward']</code>. Any such inferring *might* be made by a vCard converter, but is left up to that specific application (not all applications) built on that vocabulary, though even in that case it may not be necessary, as an empty "N:;;;" [[vCard]] property is sufficient to satisfy the N property requirement of [[vCard]], and also causes no problems when imported into various [[vcard-implementations]].

It is required of the extractor to understand that when a microformats object specifies no explicit child properties, that it must treat <code>h-card</code> as having a <code>p-name</code>. But, the parser is generic, so it also treats <code>h-review</code>, <code>h-entry</code>, <code>h-recipe</code>, <code>h-geo</code> as having a ‘<code>p-name</code>’.

As a result, specific vocabularies are evolved to drop their specific form of name (e.g. fn, summary, entry-title) and simplified to use a common 'name' property instead.

Note: while the overwhelming majority of real world publishing/consuming uses of microformats do so with proper nouns which have names (and thus this parser-level incorporation of an implied 'name'), there are some formats that do not have a 'name' semantic. For example, [[geo]], [[adr]], and possibly if/when developed, units of measure, length, cost. The current thinking is that the benefits to the far greater proper-noun use-case of microformats outweigh the technical inelegance of having an extra/ignored 'name' property on formats that lack such a semantic.

Some formats also may appear in theory to better imply some other property, e.g. a review might be thought to imply its ''content'', not its name, and an Atom entry its ''content'', not its title, but in practice (actual publishing patterns) this is not the case. Typically, brief unstructured reviews (or mentions thereof) provide a ''summary'' (often hyperlinked to an expanded structured form) of that review, not its content, and similarly, brief unstructured posts (e.g. RSS items) have historically most often been link blog items which include the title of an item and a link. Short status updates as well established by Twitter are newer and would seem to imply purely content with no title, at least semantically, however, even Twitter populates the RSS title and ATOM entry title of their feeds with the content. It's not clear what went into that decision, however, that's likely irrelevant, as the outcome turns out to be emergent consistency among publishing behaviors.

To avoid overloading or undermining the semantics of a vocabulary, I propose that we handle this at the extractor level in a simpler fashion: Define a new property for literal data, that an extractor will provide if no other information was available. All ''interpreters'' may then be instructed that in the event that an object has no properties, it can attempt to interpret the literal value from the page instead.

* This was one of the design iterations I went through which led me to the current implied 'name' design. Another iteration was the ability for a vocabulary to specify a single required property which was implied if there were no properties provided. However, the combination of the fact that in most cases such single required properties were quite name-like, and that a vocabulary-specific rule like that would then bind parsers to specific vocabularies (even so slightly) led me to collapse them into implying a 'name'. It's not perfect, but it's the best alternative so far that balances practical convenience of publishing/consuming, avoids vocabulary-specific knowledge in the parser, and technical (in)elegance. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

In existing microformats, the closest existing example we have for this is the <code>label</code> property in hCard, which is used to represent the literal address label for a place. It is a corresponding piece of <code>fn</code>, <code>org</code> and <code>adr</code> in combination, but has no structure in and of itself. Possibly, every microformat could have a <code>label</code> form where structured data is unavailable.

However in practice, the hCard <code>label</code> property is both little understood and little used. It's not even clear that it ought to be kept for microformats 2 (no known consumers, very few (if any?) real-world non-test publishers). This disuse is likely a good indicator that we should avoid basing anything on its design.

Alternatively, <code>value</code> is used throughout microformats to target a generic value (e.g. in combination with <code>price</code> in hListing.) It has been proposed that when parsing properties that are also themselves microformats, we create native objects of the form:

{
'value': '1900 12th Street, San Francisco, CA 94'
, 'type': ['h-adr']
, 'properties': {
'street-address': '1900 12th Street'
, 'etc': 'etc'
}
}

We could apply this same pattern to the root level:

{
type: [h-card]
, properties: {}
, value: 'Ben Ward'
}

In this case, an interpreter or implementation is responsible for using <code>value</code> in place of <code>fn</code>, or restructuring the object. It would be the responsibility of each vocabulary to define its root property. The parsing layer of microformats 2.0 would not impose semantics or naming onto that.

For another example, h-geo would end up like this:

{
type: [h-geo]
, properties: {}
, value: '1.3232;-0.543'
}

* This is an alternative I've been considering as well: [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)
** 'value' is more generic than 'name' (applies to more vocabularies) with the trade-off that it naturally has less (weaker) semantics.
*** +1 I think that having naturally weaker semantics would be appropriate for this parsing functionality. —[[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC)
** The interesting thing that this analysis has revealed is that there appear to be two distinct clusters of microformats, the much more commonly used/understood/useful proper-noun microformats which markup things with names (people, events, reviews, recipes), and the less used compound-data microformats which are often used ''inside'' other microformats and just have some sort of semi-structured value (adr, geo, measure, and perhaps even things like tel). Perhaps this is implying the possibility and some degree of utility for ''two'' microformats root class name prefixes, 'h-' for existing proper-noun microformats, and something else ('m-' for microformat/molecule?, 's-' for structured-value?, 'v-' for value (though historically "v-"/"v." has meant "vendor-specific")?) for unnamed structured data microformats.
*** This more and more feels like a good idea, and I'm leaning toward "s-" for struct / structure / structured value. "s-" works just like "h-" except that it doesn't imply any properties at parse time. We can try it and see what happens. There's also no harm if publishers just use "h-" structures, they just (possibly) get a few extra properties if they happen to omit properties.
** Parallels the same JSON when a property has both a string value ''and'' is a structure itself.
*** Changed my mind on this. The parallel is not quite there. 'name'/'url'/'photo' are only implied if there are NO properties, where as the JSON string value + structure convention *always* provides a 'value'. [[User:Tantek|Tantek]] 22:39, 4 October 2011 (UTC)
*** And due to this difference in behavior ('value' is there when nested properties are present, whereas 'name' is only implied when there are no properties specified), I think it's correct to keep them separate, i.e. stick with implied 'name'. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
** However, I'm still currently leaning towards the practical convenience of providing a 'name' for the vast majority of microformats uses, rather than diluting this feature for the sake of avoiding implying inapplicable semantics to the few plain structured data microformats, and even then, only when no properties are explicitly specified! I'd rather introduce a new root prefix for those than lose the simplicity and utility of implied 'name'. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

== resolved ==
=== When to collapse whitespace in properties ===

The spec doesn’t explicitly require whitespace to be collapsed or not. The official mf2 test suite requires it to be collapsed.

Reasons why whitespace ''shouldn’t'' be collapsed:
* Plaintext property representations of syntax-highlighted code, poetry and song lyrics require whitespace to be present
* Whether or not whitespace is an important part of the content being parsed is determined by css white-space and CANNOT be inferred from HTML markup alone

Resolution 2013-11-12: Agreed, whitespace should not be collapsed (other than normal HTML5 parsing rules). The spec now refers to "textContent" rather than "innertext" to make this explicit.

=== How to interpret mf2 classnames on form inputs ===
E.G. how to parse:

<source lang=html4strict>
<input class="u-url" value="https://brennannovak.com/notes/338" />
</source>

Examples in the wild: https://brennannovak.com/notes/338

See proposal:
* [[hcard-parsing-brainstorming#input_element_handling]]

Resolution 2013-11-12: Per that proposal, p- u- dt- properties on input[value] elements now use the value attribute.

=== mixture of microformats2 and classic microformats classnames on different elements ===
Some sites in the wild have mistakenly combined classic mf and mf2 markup in ways which misrepresent the content if parsed in BC mode.

Typically this is caused by putting classic and mf2 classnames for the same vocabulary on different elements, e.g:

<source lang="html4strict">
<body class="hentry">
<article class="h-entry">
<h1 class="p-name"></h1>
</article>
</body>
</source>

Sites where this has been observed:
* http://acegiak.machinespirit.net/2013/10/17/barnaby-walters-notes-another-thing-i-love-about-the-web-users-have-the-power-to-take-control-of-their-uis-and-improve-their-own-experiences-aside-drm-for-html-would-prevent-this-from-being-possibl/
* http://shawfactor.com/2013/08/06/thoughts-on-extending-webmentions/ (fixed)
* http://notizblog.org/2013/06/18/the-rise-of-the-indieweb/ (fixed)

Discussion:

* As far as I can tell, the problems in all of these examples were caused by mf2 markup being injected by a wordpress plugin, but classic mf classnames being present further up the DOM in the themes. When parsed in compatibility mode, the classic mf classnames are transformed into mf2 classnames, making the original mf2 classnames look like children of empty items.
* Turns out this isn’t theme-specific, WordPress injects hentry via PHP [http://indiewebcamp.com/irc/2013-10-22/line/1382448759]. The bug with the wordpress mf2 plugin is resolved as of [http://indiewebcamp.com/irc/2013-10-22/line/1382449035 2013-10-22] --[[User:Barnabywalters|bw]] 13:38, 22 October 2013 (UTC)

=== e- and p- escaping levels ===
<div class="discussion">
* The fact that the parsed value of any element with .e-* is at a different level of escaping to the parsed values of p-*, dt-* etc. without any indication of how the property was parsed in the output is a security problem. For example:

<table style="width: 100%">
<tr>
<th>input</th>
<th>output</th>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="p-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="e-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
</table>

* As a parser developer, the most straightforward way I can think of solving this is to add an option (enabled by default) which encodes HTML special characters on all non e-* properties, so the developer knows that all property values are going to be at the same level of escaping. --[[User:Barnabywalters|bw]] 20:00, 15 June 2013 (UTC)
** Your suggestion of auto-HTML-encoding p-*/u-*/dt-* property values is the most sensible I think. I would NOT make it an option, as it makes sense write consistent microformats2 consumers. - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
** Can you think of any existing apps/consumers of microformats2 via the parser that would break? What would indieweb comments parsers do? - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
*** The only breakage which might occur would be over-encoding of non e-* properties, but I’ll release this update as v0.2.0 and warn people about the changes. The worst thing which could happen is that some comments look a bit weird, as opposed to the current worst possible scenario of easy XSS attacks --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** We should also decide exactly which characters get encoded — just angle brackets, or quotes/ampersands as well? --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** I am not sure about this, it seems more like a helper function rather than a core feature of the parser. Personally I would like to store data as text and encode only when I am going to use and I known the format it is going to be use in. --[[User:GlennJones|Glenn Jones]] 9:54, 14 July 2013 (UTC)
***After the discussion on the indiewebcamp IRC with Barnaby Walters I now understand the XSS issue that this change is trying to address. A rogue author could include HTML with scripts to execute a XSS attack. These could be masked by switch prefixes i.e. p-* to e-* on a well use property. As the consumer does not see the prefix in the JSON output they have no idea if a property will content HTML or text. I will update my two parsers and the test suite --[[User:GlennJones|Glenn Jones]] 8:02, 17 July 2013 (UTC)
**So what about an author setting a property to e-* when it would normal be p-*, dt-* or u-* i.e.
<source lang=html4strict>
<div class="h-card"><p class="e-name"><script> alert('xss test') </script></p></div>
</source>
** per [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]], parsers should never automatically attempt to HTML-special-characters encode - as that would provide the client of the parser a false sense of security. It's *always* up to client code to escape any text being output to HTML *at the moment it is output to HTML* and never before, because they can never trust that any text from storage/elsewhere has for sure been escaped or not. - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** Should we not encode e-* as well and the consumer can decode at their own risk --[[User:GlennJones|Glenn Jones]] 18:42, 21 July 2013 (UTC)
*** No, never, per above point from [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** See [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] etherpad: https://etherpad.mozilla.org/microformats2parsing for more details on the resolution to this issue - and incorporate here (then move to resolved section below). - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
* Resolved by changes to the parsing spec: all properties are plaintext (non-HTML escaped), e-* properties result in a dictionary with <code>value</code> = plaintext version, <code>html</code> = raw HTML version
----

</div>

=== br hr empty string ===
<div class="discussion">
* The parsing rule 'else if br.p-x or hr.p-x, then return "" (empty string)' for p-* can cause any code consuming the API to become quite bloated. It means that you have test every array value to see if its an empty string. It is also unclear to me what the purpose of this mark-up pattern is for [[User:GlennJones|Glenn Jones]]
** Upon reconsidering this, I agree with you, this is an unlikely use case. If a publisher wants to explicitly set an empty property "p-foo" they can simply write <code><span class="p-foo"></span></code> which looks explicit. Whereas BR and HR tags are often just presentational, so we should both not encourage usage of them for semantics, and anyone that did use them would be subject to likely loss of semantics upon a redesign (that got rid of those particular BR and HR tags). I'm going to remove them from the parsing spec. - [[User:Tantek|Tantek]] 15:29, 10 February 2013 (UTC)
</div>

=== datetime examples without T delimiter ===
<div class="discussion">
* The examples in the wiki microformats-2 pages such h-entry and h-entry had datetime without the 'T' delimiter between date and time. ie
<source lang="html4strict">
<time class="dt-published" datetime="2013-06-13 12:00:00">13<sup>th</sup> June 2013</time>
</source>
I have updated the pages. As far as I known this is a new pattern for dates. Was it a mistake in the examples or is it a new datetime pattern.
** The [[HTML5]] "time" element, and "datetime" attribute allow for space <span style="white-space:nowrap">" "</span> as a separator between date and time as well as "T", thus we allow it for microformats as well. The <span style="white-space:nowrap">" "</span> separator is preferred as the date and time are more readable when separated by a space. The examples noted in those specs deliberately use this. - [[User:Tantek|Tantek]] 18:48, 15 July 2013 (UTC)
</div>

=== rel-alternate absent optional attributes ===
<div class="discussion">
* What should rel-alternate parsing do when one of the optional attributes specified (<kbd>hreflang</kbd> or <kbd>media</kbd> or both) is not there? The options seem to be:
*# leave the corresponding key out of the alternate JSON object
*#* This one. Leave the corresponding key out.
*# include the corresponding key in the alternate JSON object, but set the value to the JSON null object
*# include the corresponding key in the alternate JSON object, but set the value to a blank string
*# something I haven't thought of

I haven't checked the existing implementations, but Barnaby said he's not sure what the appropriate way to deal with it is either. —[[User:TomMorris|Tom Morris]] 15:41, 9 August 2013 (UTC)
</div>

=== rel-alternate and type attribute ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Should rel-alternate parsing also pick up the <code>type</code> attribute? It’s fairly widely used, e.g. for ATOM feeds.
** Numerous existing sites/pages have various [[rel-alternate]] uses with a type attribute for feeds/APIs so that's good enough to add this for help with discovery in general. Rel parsing updated. - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
</div>

=== Extraction vs Interpretation ===
Issue raised by: [[User:BenWard|Ben Ward]]

A microformats ‘1.0’ parser performs the following function:

* Given a piece of HTML content, discover a known microformat, extract it, apply various extraction patterns based upon the HTML mark-up used (e.g. include pattern, <code>abbr</code> patterns, date-time patterns, value-title pattern), apply various content optimisations where applicable, and return the result in an object native to the programming language.

This is performing two types of function: Extraction of data from an HTML document or fragment, ''and'' interpretation and optimisation of that content to match the rules set out by a vocabulary specification.

It is only possible to write a generic parser that covers the first half of this task: Extraction, and application of global rules based on HTML elements and patterns common to all formats.

The purpose of a generic parser (as supported by use cases such as search engines, and other crawlers) is:

To provide a way for tools to extract rich data from a page for native storage, such that the data may be interpreted later by applications. This allows microformats to be crawled, and indexed, and removes the need to include complex HTML parsing within every implementation of microformat data.

Microformats will continue to define various vocabulary-specific optimisations. as part of the design to be optimised for authors. For example: The <code>fn</code> pattern in [[hcard]], or the <code>lat;long</code> pattern in [[geo]], as well as default values for properties, such as the maximum rating in an [[hreview]].
* Actually, no, as it is defined currently, microformats 2 ''drops'' vocabulary-specific optimizations. Such optimizations have often been too inapplicable, error prone or i18n-unsafe (e.g. fn to given-name + family-name fails for both numerous cases where middlenames/initials are used, and in general in numerous Asian languages where given/family name order is the reverse of Western English conventions, or languages with multiple family-names, e.g. Spanish - see [[hcard-issues-resolved]] for more). This is a deliberate cutting of a "feature" from microformats 1, it is a deliberate model simplification design decision. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

==== Extraction resolution ====
Proposed resolution:

Microformats2 should refer only to ''extraction'' of microformats. Vocabularies should in turn document their appropriate optimisations, which will need to be applied by implementations, or a companion to an extractor, which I'll refer to here as an ‘interpreter’.
* Vocabularies will no longer have optimizations, this is again deliberately, as they've been shown to be more error prone than helpful. Thus there should be no need for any vocabulary-specific 'interpreters'. However, due to design quirks in various legacy/interchange formats, ''export conversions algorithms'' to those legacy/interchange formats will require some additional legacy-format-specific rules (e.g. odd "required" rules in [[Atom]] or [[vCard]] will require specific synthesis rules, limitations in said formats will require filtering of some values, e.g. [[vcard3]] BDAY disallows vague birthdays like year-month and --month-day - subsequently allowed in [[vcard4]]). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

A microformats2 ‘extractor’, in combination with the functionality of a domain and format-aware ‘interpreter’ (either another shared component, or part of the implementation itself) would be equivalent to a microformats 1.0 ‘parser.’
* A microformats2 parser is both generic (no knowledge of specific vocabularies), and lacks any/all such vocabulary-specific rules as compared to a microformats 1.0 [[hcard-parsing|parser]] with the exception of a 1) a limited list of well-established/interoperable backward compat root class names (of current [[microformats]] that are or can be soon shown to be specifications/standards per the [[process]]), 2) flat sets of backward compat property names (some with prefix/name specific conversion) for each of those backward compat root class names. This is a deliberate design decision that makes microformats 2 more "micro", and yes this means that even with such backward compat support, this simple form of backward compat may mean that some existing microformats 1 content breaks. We'll assess those and iterate on a documented case-by-case basis rather than attempt to maintain theoretical 100% backward compatibility (since many current microformats format-specific-features are either unused, or may have caused more problems than solutions). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

N.B. I'll rewrite some of these as [[microformats2-parsing-faq]] to help better clarify. The reasoning that led to most of these design decisions is documented in the [[microformats-2#About_This_Brainstorm|microformats 2: About This Brainstorm]] section and following sections. I'll recheck those sections to see if/where reasoning for some of the above noted design decisions may have been missed, and back-fill accordingly. This is necessary because [[microformats2]] is a evolutionary result of simultaneously addressing both numerous generic [[issues]] as well as various common [[hcard-issues-resolved|format]]-[[hcalendar-issues-resolved|specific]] [[mfo|problems]] in microformats1 syntax and vocabularies. The very number of changes may make it more challenging (from a microformats1 perspective) to see why any particular design change has been made. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

This issue can be moved from resolved to closed once the above-mentioned write-ups have occurred.

===Parsing properties from rel attributes===
tl;dr resolution: As of 2013, [[microformats2-parsing]] handles parsing all link and a href rel values at document scope level, and producing canonical JSON accordingly. - [[User:Tantek|Tantek]]

Issue raised by [[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC):

* Currently, hAtom parses `bookmark` as a permalink
* Various microformats parse `rel=tag` as tags
* The current proposal for parsing does not allow parsing properties from rel attributes.

Microformats parsers could instead extract ''all'' link relationships from rel attributes within an microformat object, parsing them as if a u- prefixed property.
* Minor nit: Rather than same as a u- prefixed property, I think such "rel" properties should be parsed purely from the <code>href</code> attribute on <code><a></code> and <code><area></code> elements and nothing more. I would strongly disagree to extending rel to apply to other elements with URLs like img src, object data, or to apply to elements in general like div. That's the path that RDFa has taken and caused much confusion as a result. [[User:Tantek|Tantek]] 07:39, 5 October 2011 (UTC)
** Agree: That seems like a perfectly reasonable restriction. --[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)

This results in:

* Continuing use of the <code>rel</code> attribute in HTML, thereby building on HTML semantics rather than bypassing them or ignoring them in favour of something less meaningful.
* Parsing hAtom objects contain a property named <code>bookmark</code>, in place of <code>permalink</code>.
* All microformats that use <code>rel-tag</code> would contain a property named… <code>tag</code>. Perfect.

Since <code>rel</code> attributes are not overloaded for other functionality like class is, and other uses of <code>rel</code> within content are low (and non-semantic uses are nil, to the best of my knowledge) the risk of property pollution would be extremely low.

Note, with regard to this last point, that a generic microformats parser ''will'' parse false-positive properties, and ''will'' parse objects in combined chunks, rather than individually by format. Extracted objects will often not represent a vocabulary without further processing.

<div class="discussion">
* This sounds like it might be workable. Let's try it and see how well authors "get it". - [[User:Tantek|Tantek]]
* Possible issue: do we have any collisions between class property names and rel names? (I don't think so offhand, but useful to ask the question). - [[User:Tantek|Tantek]]
** None that I can think of in microformats. There is the case of Google's <code>rel=author</code> and <code>p-author</code> in hAtom. However, the next point, about mfo scoping, would cover it in most situations (rel-author on a hyperlink within an hcard wouldn't be applied to the hentry.) The one situation in a parse tree where it's ambiguous would be this:
<source lang=html4strict>
<a href="p-author h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
** I can think of two quite reasonable solutions:
*** 1. Declare that class properties take precedence over rel properties of the same name, discarding rel values if a class is also found, or
*** 2. Since all properties are now multi-value anyway, the hAtom object could be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
** —[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)
*** Option 2 makes sense and is consistent with the rest of the multi-value parsing/handling. - [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
*** What about without the 'p-author'?
<source lang=html4strict>
<a href="h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
Should that be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
Or
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': 'http://benward.me' /* from the rel="author" */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},

],
…
}
}
</source>
*** And if the former, then we're presumably saying that the value parsed due to the presence of a rel is always its own value, and does not combine with any other structures. I am fine with this, but I wanted to make sure we are ok with that explicitly. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
**** +1 I think that since the rel attribute is specifically concerned with the relation to an href attribute, it should not be combined with other structures that are rightly declared uses classes.
***** The more I've thought about this and how consuming applications may want to treat rel semantics, the more it seems correct to keep rel semantics distinct from class semantics. Class semantics are quite general/flexible, whereas rel is quite specific, naming something else in terms of a relationship from the current page/microformat's perspective. I think we should consider putting rel values in their own 'rel' collection, separate from the 'properties' collection. E.g. the original rel-author p-author h-card markup example would be parsed into this:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
}
],
…
}
'rel': {
'author': ['http://benward.me'] /* from the rel="author" */
}
}
</source>
***** and if a post had multiple authors:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from p-author */
'type': ['h-card'], /* from h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
{
'value': ['Tantek Çelik'], /* from 2nd p-author */
'type': ['h-card'], /* from 2nd h-card ... */
'properties': {
'name': ['Tantek Çelik'],
'url': ['http://tantek.com']
},
],
…
}
'rel': {
'author': [
'http://benward.me', /* from rel="author" */
'http://tantek.com' /* from 2nd rel="author" */
]
}
}
</source>
***** This preserves the semantic distinction between rel and properties in general, and leaves it up to a higher-level application to implement any logic around showing "more info" about a rel-author, e.g. by correlating the rel-author URL with the 'url' of an hCard it found in the same entry. However, note that even in the earlier JSON data model, the rel-author value just shows up as another property value, and any higher level application would still have to do some correlation logic. At least with this JSON data model, applications that may be looking for a rel value in particular, or a property value in particular can do so without having one unintentionally pollute the other. [[User:Tantek|Tantek]] 17:33, 6 October 2011 (UTC)

* Presumably we'd apply all the same property scoping rules to rel scoping as well. E.g. a rel hyperlink inside a microformat won't be seen by any containing microformat. - [[User:Tantek|Tantek]]
** Correct, it should be parsed in the same scope as all other class properties in the object.
*** Update: all rel microformats are now parsed at page-scope. Per-microformat scoping of rel has been found to be too confusing in practice (and against the general semantic of rel expressed in the HTML/HTML5 specs) [[User:Tantek|Tantek]] 01:00, 10 July 2014 (UTC)

This issue can be moved from resolved to closed once we've verified that all the above-mentioned and implied needs to write things up have occurred.
</div>

=== deduping of rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-02 by [[User:Kevin Marks|Kevin Marks]]
* 2015-06-05 resolved by consensus and one real world implementation proof of implementability and verification of expected results. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

Many sites have multiple duplicate rel links to the same url - a very common case is WordPress home pages eg [http://ma.tt ma.tt]

Each post on the page has a block like
<code><pre>
<div class="entry-meta">
<span class="date">
<a href="http://ma.tt/2015/05/beethoven-mozart-bach/"
title="Permalink to Beethoven, Mozart, Bach" rel="bookmark">
<time class="entry-date" datetime="2015-05-31T22:42:00+00:00">May 31, 2015</time></a></span>
<span class="categories-links">
<a href="http://ma.tt/category/asides/" rel="category tag">Asides</a></span>
<span class="author vcard">
<a class="url fn n" href="http://ma.tt/author/saxmatt/"
title="View all posts by Matt" rel="author">Matt</a></span>
</div></pre></code>

As currently defined, the parser will create duplicate entries in <code>rels</code> for each post:
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/",
"https://ma.tt/"
],
}
</pre></code>

and in the <code>rel-urls</code> we will also see:
<code><pre>
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author",
"author",
"author",
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home",
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag",
"category",
"tag",
"category",
"tag",
"category",
"tag"
],
"text": "Asides"
}
</pre></code>
These duplicates are unhelpful for parser consumers. We should:
* make them both sets - only listing distinct values. This will remove ordering information, but order is irrelevant for rel in html.
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/"
],
}
…
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag"
],
"text": "Asides"
}
</pre></code>

* possibly we could also make <code>title</code> <code>text</code> <code>type</code> sets too. That would solve the information loss issue with the current parsers
** Resolution: in the case of duplicate other attributes, first one set wins. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

<div class="discussion">
* +1 as the proposer. A version of mf2py that does this is running at unmung,com. see [http://www.unmung.com/mf2?url=https%3A%2F%2Fma.tt&html=&pretty=on fro ma.tt] or [http://www.unmung.com/?html=%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E&pretty=on a simple test] [[User:Kevin Marks|Kevin Marks]] 23:49, 2 June 2015 (UTC)
* +1 makes sense to me, and not having them be sets in the current spec is likely an oversight on my part. Thanks for noting this issue. [[User:Tantek|Tantek]] 05:28, 3 June 2015 (UTC)
</div>

=== include alternates in rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 resolved per consensus and one real world implementation proof of implementability. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* add "alternate" rels to the "rels" collection to make them easier to look-up in "rel-urls" - that is, all rel values end up in "rels" collections. No exceptions.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls".
* +1 This makes sense to me, as the <code>rels</code> and <code>rel-urls</code> should match so you can lookup in rels first, then get details about urls from rel-urls. We can drop "alternates" independently from this change. [[User:Kevin Marks|Kevin Marks]] 00:23, 2 June 2015 (UTC)
** +1 drop "alternates" independently now made a separate issue. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
* +1 Makes sense. And I agree with Kevin; I think parsers should deprecate "alternates" for now and drop it after a version cycle or two. [[User:Kylewm|Kylewm]] 00:30, 2 June 2015 (UTC)
* implemented in [https://github.com/kevinmarks/mf2py/commit/4dba45200eef11da811f64817d02044ab9e98b77 my fork of mf2py] and running on [http://www.unmung.com/?html=%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fa%22%3Eauthor+a%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fb%22%3Eauthor+b%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F1%22%3Epost+1%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F2%22%3Epost+2%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22alternate+home%22%0D%0A+++href%3D%22http%3A%2F%2Fexample.com%2Ffr%22%0D%0A+++media%3D%22handheld%22%0D%0A+++hreflang%3D%22fr%22%3EFrench+mobile+homepage%3C%2Fa%3E&pretty=on unmung] [[User:Kevin Marks|Kevin Marks]] 01:29, 2 June 2015 (UTC)
</div>

=== Empty properties overridden by implied rules against user expectation ===
Status: resolved, existing behavior correct, no changes to parsing spec.

2015-07-03: raised by [[User:Glenn Jones|Glenn Jones]]

Emma Kuo brought up an issue (https://github.com/glennjones/microformat-node/issues/22) based on following the indieweb note pattern, where the content of a note is given both the e-content and p-name classes. If the element containing the notes only has none text content like image the p-name can have unexpected value. Here is the example she gave:

<code><pre>
<div class="h-entry">
<a href="http://this.site/photo" class="u-url"></a>
<div class="e-content p-name"><img src="photo.jpg" class="u-photo"/></div>
Some extraneous text
<div class="h-cite">
<a href="http://someother.site/like" class="u-url"></a>
<a href="http://this.site/photo" class="u-like-of"></a>
<div class="e-content p-name">liked this</div>
</div>
</div>
</pre></code>

At the moment I parser this as follows: - if a property (p-name) is empty do not add it to the output. In this case "empty" is classed as not containing any non-whitespace text. As far as I known there is no guidance on how to handle "empty" properties in microformats paring rules, so I followed the conventions of JSON API's not to return "empty" properties.

The side effect of the above is that p-name also has a number of "implied rules". The "implied rules" try to automatically fill properties like p-name if there is no defined value. In the example above it uses the textContent of the parent h-entry, so value of the h-entry>p-name is the text content of the h-cite i.e. "likes this".

Options:

1. We should not allow the "implied name rule" to get textContent from within a child h-*
<div class="discussion">
* <strike>+1 I believe this is inline with how we parse properties and will meet user/author expectations [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* -1 A nested h-* is still part of the content of the parent h-*, I don't quite understand the rationale for excluding it. For example, I may include lots of h-cards in the body of a post that references people and wouldn't want them to be excluded from the implied name generation. [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* -1 I'm not sure this would solve the problem because auto-filled text could come from the parent h-* ("some extraneous text" in the example above) [[User:emmak|Emma Kuo]] 20:50, 4 July 2015 (UTC)
* -1 I agree with the other -1s. This would break some of the simplicity of the model. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
</div>
2. We should not execute the "implied rules" where there is an author defined "empty" property.
<div class="discussion">
* <strike>-1 Although the output would meet author expectations it is complex for parsers as they will have to keep state for each property through the whole series of parsing rules. [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* +1 An explicit, empty, p-name property should prevent an implicit p-name from being generated. For example tantek.com includes <span class="p-name"></span> at the start of the h-feed to prevent a giant name from being auto-generated. From my reading of the parsing spec, I don't see any reason that blank strings should be excluded from parsing. (mf2py and php-mf2 will both happily include empty strings in their output) [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* +1 We already have interop on this between mf2py and phpmf2, as well as people depending on it to explicitly set empty property values. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
* +1 As we already have interop with two parsers and solid user issue from Emma we should take this approach. [[User:GlennJones|Glenn Jones]] 11:51, 29 July 2015 (UTC)</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== uf2 children inside a classic microformats root class name ===
Status: incorporated into [[microformats2-parsing]]

2015-020: (raised by kylewm) What should microformats2 children inside a classic microformats root class name do?

Options:

1. Nothing. Any unattached uf2 children inside a classic microformats root are ignored. Problems:
<div class="discussion">
* However then there's a possible surprise if/when the author upgrades the classic microformats root to uf2, then all of a sudden all the new uf2 children show-up.
* Another downside: author adds uf2 markup, can't figure out why nothing is happening (because somewhere up the tree in code they didn't touch is classic microformats that are hiding these unattached uf2 children.
</div>
2. Show up in the children collection of the classic microformats root
<div class="discussion">
* Feels most predictable. When you add uf2 root class names anywhere, they will show up in the JSON output hierarchy.
* When you convert ancestor class microformats root class names to uf2 root class names, no surprise in terms of which microformats show up. Same children collection.
* +1 Thus I'm leaning towards this one, despite the fact that classic microformats never had a concept of generic unattached children. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)
* +1 I think this is the best option I will implement it and update the wiki once its in the JavaScript parser. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>
3. Show up as peers to the classic microformats root. Issue(s)
<div class="discussion">
* Has ths surprise aspect of if/when you convert the classic root class name to a uf2 root class name, the former peers become unattached children.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== any h- root class name overrides and stops backcompat root ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: The presence of any h-* root class name overrides and stop any backcompat parsing of classic microformats root class names on that same element. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for restricting backcompat root class name to only seeing backcompat property class names
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
* I don't think I understand this rule. If I was stop all parsing of of classic microformats in the presence of any h-* root in a document then some of the other rules such as "uf2 children inside a classic microformats root class name" do not make sense. Could this item be expanded and explained a bit more? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** added "on that same element" as that was what we were discussing/implying in this issue. [[User:Tantek|Tantek]] 22:49, 18 September 2015 (UTC)
</div>

=== backcompat classic microformats should only see backcompat properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats vocabulary that indicates a backcompat root class name (and thus an absence of the microformats2 equivalent on the same element), parsers must only look for the backcompat properties that are specified explicitly for that backcompat root class.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such behaviour was never expected by authors, and crossing a classic microformats root class name with microformats2 property names were never explicitly expected nor specified to work.

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== microformats2 root class names should only see microformats2 properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats2 root class name, only explicit microformats2 properties should be parsed. Any backcompat property names must be ignored.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such microformats2 authors should be expected to do all their microformats markup with microformats2 class names - this is a deliberate expectation so that their microformats aren't polluted with other (classic microformats) coincidentally named generic class names.

Thoughts?
<div class="discussion">
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== implied properties on backcompat parsing unlikely to be intended ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
Since classic microformats had no notion of implied properties, when implied property parsing occurs on backward compat classic microformats root class names, it is unlikely that any implied property (p-name u-url u-photo) was ever intended by the author of the classic microformat. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
Examples:
* see https://indiewebcamp.com/h-entry#bad_hentry_properties for a growing list

'''Proposed resolution:'''

* Be explicit in implied property parsing that it must only be done for explicit 'h-*' root class name microformats, not for any (back)compat parsing of microformats. Please comment on this proposal with "** comment" on new lines below. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
** +1 This makes a lot of sense to me. We should strive to parse mf1 as it was intended by the author, and I think you're right that implied rules are unlikely to be what was intended [[User:Kylewm|Kylewm]] 03:22, 30 December 2014 (UTC)
** +1 I think this will help backcompat parsing, but there are two major things to consider. It may well break some consumer code as the output for a microformats currently always has the name property, there may not be the defences code to check this is true when we remove the implied name rule for classic microformats. The test suite will also need major updating as all the test output for classic microformats will have. I will look into implementing this and report back to the wiki. [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** Also it should be made clear that we are only removing the implied rules from classic microformats parsing and not the value property? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
*** The "parsing for implied properties" section only references name, photo, url properties. Where (in the spec) is the confusion about "value" coming from? [[User:Tantek|Tantek]]
** RESOLVED at [[2015-01-20]] meetup. [[User:Tantek|Tantek]] 04:09, 21 January 2015 (UTC)
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Set implied properties by microformat version"

=== link elements and u- parsing ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Raised by tantek on 2014-07-08 on [http://logs.glob.uno/?c=freenode%23microformats&s=8+Jul+2014&e=9+Jul+2014#c72916 irc]: should the parsing specification for handling u- properties be modified to include the <code>link</code> element? The potential downside is that [[invisible-metadata-is-considered-harmful]], however all known real world examples of <code>link</code> are <em>semi-</em>visible data (not fully hidden).

There are potential cases for wanting to use link as an alternative to <code>a</code> (and <code>area</code>), such as a whole page where the root <code>html</code> element is an <code>h-card</code> and the properties are included across the page: some in visible data in the <code>body</code> while others are in the <code>head</code> as <code>link</code> elements. Example:

One specific use-case is the semi-visible <code>link rel="shortcut icon" href="..."</code> - which is visible sometimes in browser UI, and also when a user chooses "Add to Home Screen" on a mobile device. Such page level icons may be used as a <code>u-photo</code> or <code>u-logo</code> of the containing <code>h-*</code> object on the <code>html</code> element.
* http://adactio.com/about/myself/ on 2014-190
** <em>could</em> use <code><html class=h-card></code> - page is all about Jeremy Keith the person
** <em>icon / logo is only</em> on <code><link></code> tag which <em>could</em> use <code>class=u-logo</code>: <br/><code><link rel="shortcut icon apple-touch-icon" type="image/png" href="/icon.png" /></code>

Another specific use-case is a post permalink page, e.g. with <code><html class=h-entry></code>
* http://waterpigs.co.uk/notes/4WjHpC/
** <em>has</em> <code><html class="no-js h-entry hentry h-as-note" lang="en"></code>

Another use-case is publishing links to PGP/GPG keys linked from the head which is currently handled by <code><link rel=pgpkey></code> which is already supported in existing [[microformats2-parsing#parse_a_hyperlink_element_for_rel_microformats|microformats2 rel parsing]] of <code>link rel</code> elements. Thus there is a (admittedly weak) argument for consistently parsing <em>both</em> <code><link rel></code> <em>and</em> <code><link class="u-*"></code>.

E.g. inside that aforementioned real world <code><html class=h-entry></code> post permalink page example,
* why should <code><link rel="in-reply-to"></code> work
* but not <code><link class="u-in-reply-to"></code> ?
The slightly stronger argument for consistency of link handling is that it <strong>[[simpler|simplifies]]</strong> the publisher (and parser) model:
* <code><a></code> and <code><area></code> work for both <code>rel</code> and <code>class</code>
* why does <code><link></code> only work for <code>rel</code> ?
* it would be <em>simpler</em> if all three tags just worked (in the same way) for both <code>rel</code> and <code>class</code>

'''Should the parsing spec be modified to handle these cases?''' —[[User:TomMorris|Tom Morris]] 09:25, 9 July 2014 (UTC)

** I'm generally in favour. It'd be good to see what other parser developers think. —[[User:TomMorris|Tom Morris]] 10:16, 9 July 2014 (UTC)
** adding this to the parsers won't be an issue. <del datetime="2014-07-09T18:45">The question is should the door be opened to hidden mf data?</del> <ins datetime="2014-07-09T18:45">Up on further reflection, there seems to be no need to distinguish between <code>rel=property</code> and <code>class=u-property</code> on link elements. So I am in favour for consistency.</ins> [[User:KP|Kartik]] 18:30, 2014-07-09 (EST)
** RESOLVED at [[2015-01-20]] meetup. Make link consistent with a.
</div>

=== drop alternates collection ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 split into separate issue from include alternates in rels per implementation feedback from Kevin Marks. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* drop "alternates" as its no longer needed, and all current consuming code clients like rel-urls better anyway.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls" in original issue now "include alternates in rels", we no longer need "alternates", and those with client consuming code have universally indicated that they would rather use rel-urls anyway. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
</div>

== see also ==
* [[microformats2-parsing]]
* [[microformats2]]

microformats2-parsing-issues

2016-03-13T20:44:33Z

Barnabywalters: /* use poster if no src on video for u props */

This page is for documenting issues with the [[microformats2-parsing]] specification.

== issues ==
Open issues in various states of partial resolution from none to nearly resolved.

=== ignore u-camelCase properties ===
Due to Suit CSS (and others? citations?) recent (2015-?) use of "u-*" class names for so-called "[http://davidtheclark.com/on-utility-classes/ utility classes]", we are seeing some false positives in a few very rare instances, e.g.: http://www.unmung.com/mf2?url=http%3A%2F%2Fwww.kevinmarks.com%2Ftwitterutils.html&html=&pretty=on

(Nearly) all these "utility classes" use camelCase for the class name suffixes, thus we can filter them out by looking for camelCase (since microformats class name conventions are always all lowercase and hyphenated), or even just looking for (and rejecting) *any* capital letters.

Proposal:
* microformats2 parsers MUST IGNORE u-* classnames where the * has any uppercase letter(s).

<div class="discussion">
* +1 [[User:Tantek|Tantek]] Let's get this fix rolling quickly to avoid further pollution.
* +1 [[User:Barnabywalters|Barnaby]] php-mf2 already ignores classnames with capitalised prefixes, ignoring any classnames with capital letters seems totally reasonable
* ...
</div>

=== exclude style elements before parsing ===
[http://logs.glob.uno/?c=freenode%23microformats#c85457 2016-01-25 raised in #microformats]

Ran into an issue of a <style> element being parsed as plain text in a p-name. Should [[microformats2-parsing]] be updated to indicate <style> should be excluded when parsing? Appears to implicitly fall under [[microformats2-parsing#note_HTML_parsing_rules]]

Sample link: http://veganstraightedge.com/notes/2016/01/16/tonight-s-dinner-tacocleanse-beverly-hills-c

The <script> tag can be similarly problematic.

Proposal: Drop both <script> and <style> elements completely when parsing any property (including e-* HTML values). [[User:Tantek|Tantek]] 01:01, 29 February 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Aaronpk|aaronpk]] as a consumer of HTML from an e-* property, I will always be sanitizing the HTML and removing <script> and <style> anyway
* +1 [[User:Kylewm|kylewm]]
* 0 [[User:Barnabywalters|Barnaby]] +1 to removing the contents of <script> and <style> from all plaintext properties (and 'value' property in HTML dicts), -1 to removing <script> and <style> from HTML. That’s a job for a sanitization stage. As aaronpk points out, sanitization will have to be done anyway if the content is to be reposted, so doing so in the parser doesn’t actually save anyone any work, but removes information which could be useful to people (example use cases: publishing posts with embedded per-post styling, publishing interactive HTML documents with embedded javascript)
** +1 this seems like reasonable feedback to make a new refined proposal. [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)
</div>

Proposal 2: Drop both <script> and <style> elements completely when parsing any property (except for e-* HTML values, which preserve all markup). [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Barnabywalters|Barnaby]
* ...
</div>

=== use poster if no src on video for u props ===
[https://indiewebcamp.com/irc/2015-12-13#t1450035721661 2015-12-13 raised in #indiewebcamp]

There is a use-case of marking up the "poster" of a video element as the u-featured of an [[h-entry]], to do that, we need to change [[microformats2-parsing#parsing_a_u-_property|u- property parsing]] to look at the poster attribute of the video element, after it's looked for the src attribute.
<blockquote>" else if video.u-x[poster], then get the poster attribute "</blockquote>

Real-world example of markup in the wild:
* http://veganstraightedge.com/videos/2013/5/31/1/backyard-squirrel-buddy
** and likely all other videos posted there.

Background discussion that led to this proposal:
* https://indiewebcamp.com/irc/2015-12-13#t1450035721661

This seems very straightforward so I've added it as PROPOSED directly in the parsing spec. This issue is for tracking the discussion.

Feedback from parser implementers please!
<div class="discussion">
* +1 [[User:Barnabywalters|Barnaby]] easy to implement and based on real-world markup, no objections
* ...
</div>

=== uf2 children on backcompat properties ===
[http://logs.glob.uno/?c=freenode%23microformats&s=today#c84632 2015-11-24 raised by Calli] in #microformats

Related but different from [[#uf2_children_inside_a_classic_microformats_root_class_name]], when there is a uf2 child directly on a backcompat property, what should happen? E.g.

<source lang=html4strict>
<div class="vcard">
<div class="adr h-adr">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

What is the expected behavior and parser output?

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-adr"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

<div class="discussion">
* Proposal: the nested "adr h-adr" child is treated as an mf2 object, not backcompat, and thus the resulting parsed "locality" property has a single value of "MF2". Proposed by Calli, noting that Glenn Jones's microformatshiv gets that result currently, and it would be easier for him (Calli) to implement this way.
** +1 Tantek, seems reasonable and the reasoning provided is good (we have one implementation this way already)
** +1 Kyle, this is consistent with the resolution to the related issue
** +1 Calli, yes, this is easier for me to implement (than taking both MF1 and MF2 properties) because it is consistent - for me, consistency is the controlling factor in favor rather than ease of parser implementation
** ...
</div>

Another example:

<source lang=html4strict>
<div class="vcard">
<div class="adr h-custom">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-custom"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

Per the [[#any_h-_root_class_name_overrides_and_stops_backcompat_root]] resolution, the class name "h-custom" overrides the use of "adr" as a backcompat root.

=== default generated HTML ===
2015-09-08 raised by Tantek in #indiewebcamp

Should there be a default (perhaps not quite "canonical") way to map/generate HTML+microformats2 from a parsed mf2 JSON output?

E.g. straw proposal:
* JSON/mf2 -> [[XOXO]]+mf2

Existing work / mappings:
* https://github.com/snarfed/granary/blob/master/granary/microformats2.py#L295

Related to:
* https://github.com/snarfed/granary/issues/31

Use-cases:
* default webview / presentation for a site that stores mf2 JSON output
* possibly a way to implement a distributed HTTP webcache retrieval protocol

Thoughts?
<div class="discussion">
* +1 [[User:Tantek|Tantek]] I think we should have this, but am open to proposals on specifics!
* +1 [[User:GlennJones|Glenn]] Also think this is worth looking at, but I am not sure it should be part of the parser spec. Feels like it should be built as a separate library and have it own spec on the microformats wiki.
* ...
</div>

=== Noscript skip/parse ===
2015-07-28

Should mf parsers skip <code><noscript></code> tag in the HTML, like the <code><template></code> tag mentioned in http://microformats.org/wiki/microformats2-parsing#note_HTML_parsing_rules ?

mf2py skips <code><noscript></code> when using the html5lib DOM parser but no when using lxml parser. Example use of <code><noscript></code> https://kartikprabhu.com/ featured images have a no javascript fallback image inside <code><noscript></code> with <code>class='u-featured'</code> markup.
* html5lib actually HTML-escapes the contents of <code><noscript></code>, so to mf2py it just looks like plain text with no tags. In Woodwind, I've resorted to using regex to strip out <code><noscript></code> tags before parsing (very hacky). [[User:Kylewm|Kylewm]] 15:52, 25 August 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] skip noscript (and inside) because in today's typical browsing contexts, nothing in noscript is displayed, thus we should discourage marking up effectively invisible content.
** Proposed change to [[microformats2-parsing#parse_a_document_for_microformats]]:
*** from: "follow the HTML parsing rules"
*** to: "follow the HTML parsing rules (including skipping/omitting <code><noscript></code> elements, e.g. like the html5lib DOM parser)
* -1 [[User:GlennJones|Glenn]] This subject does need to be address, but differently to proposed change. My personal view is that e-* html should be passed through raw and then the consumer can process it in a way they feel fit. Its a case for helper libraries. I am about to build a helper library to do this based on the Readability code to post process e-* html. Other people may want to take different approaches, defining this in the spec feels like move into a whole area of new functionally.

As a separate new point we need to consider "exclude tags" lists for parsed text from html. We should consider <code><noscript></code>, <code><noframe></code> and <code><template></code> there maybe other I have not gone through all the tags in current HTML spec. Also we should consider what to do about the more common pattern of fallback text within media tags <code><video></code>, <code><audio></code> etc. This should be explicitly discussed in the parsing rules. At the moment my experimental text normalisation does exclude tags, but the default text parse does not. Currently the fallback content in media tags like <code><video></code> is added to the parse text. 12:56, 25 Septemeber 2015 (UTC)
* ...
</div>

=== Standard datetime format ===
2015-07-28

http://microformats.org/wiki/microformats2-parsing#parsing_a_dt-_property does not specify any standard format to use for datetimes. e.g. <pre>2015-07-28T12:55:33</pre> vs <pre>2015-07-28 12:55:33</pre>
Would be good to standardize this to compare various parser outputs.

2015-07-29: This subject is (somewhat) covered in http://microformats.org/wiki/iso-8601 As it stands the JavaScript parsers support output in the 3 main profiles, 'W3C Note', 'RFC 3339' and 'HTML5' plus 'auto' which keeps authors format. The default date output for the JavaScript parsers is the same format as the date was originally authored in. This can be changes by setting the options.dateFormat switch to any of the other profiles mentioned. It would be good if other parser also had a switch to force output to a common profiles so we could compare various parser outputs, but I think the default should be how a date was authored. All output whatever profile should also keeps the authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string. This is important if you want to compare parser outputs.

The only exception to this where date and times are combined such as the implied h-event rule for dt-start and dt-end where I output in the HTML5 style 2015-07-29 12:55:33 as there is no predefined author preference and HTML5 profile is more human readable. [[User:GlennJones|Glenn Jones]] 11:02, 29 July 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] output more human readable <code>2015-07-28 12:55:33</code> canonically, with authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string.
** Let's update any test cases as needed for this. - [[User:Tantek|Tantek]]
* ...
</div>

=== implied date for dt properties both mf2 and backcompat ===
The [[value-class-pattern#microformats2_parsers|value class pattern dt-* date proposal]] should apply to both mf2 dt-* properties, and backcompat classic microformats, to preserve the hAtom / hCalendar optimizations noted on that page, but in a generic way.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] 16:12, 18 August 2015 (UTC)
* +1 [[User:Glenn Jones|Glenn Jones]] 20 August 2015
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== implied properties when an explicit class is provided ===
<div class="discussion">
Should "u-url" still be implied if another explicit class is already provided, as below. This is a contrived example, but it is taken from Bridgy's unit tests.

<code><pre>
<article class="h-entry">
<a class="u-like-of" href="http://orig.domain/baz">liked this</a>
</article>
</pre></code>

In this case, http://orig.domain/baz is almost certainly not the u-url, so IMO it would be better to leave it out —[[User:Kylewm|Kylewm]] 15:10, 7 October 2014 (UTC)

'''2015-01-20 consensus'''
* Changed my mind. Simpler to do nothing. Example provided is artificially constructed, does not reflect likely real world confusion of if we make implied properties more complicated. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
* ++ Consensus on do nothing for this case. At [[2015-01-20]]

'''Proposed resolution:'''
* Changed again. Due to indiewebcamp.com/edit use-case, this now makes sense for all implied properties. That is:
** If an element has any explicit property class name(s) on it, then it must not be used to imply any properties. [[User:Tantek|Tantek]] 20:50, 27 May 2015 (UTC)
*** +1 this seems reasonable, if a publisher is going to add an mf2 class, it is unlikely they want other classes automatically implied from the same value [[User:Aaronpk|Aaronpk]] 23:19, 29 November 2015 (UTC)
*** -1 for now. To my knowledge, this has only been observed in artificially constructed unit tests and examples, and it adds some weird edge cases that are hard to reason about. [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** ... provide input on this proposal here
** Refined: Or should this be refined by per parsing prefix? [[User:Tantek|Tantek]] 22:59, 18 September 2015 (UTC)
*** Any explicit "p-*" property means no implied "p-name" from that element
*** Any explicit "u-*" property means no implied "u-url" nor "u-photo" from that element.
*** ... provide input on this refined proposal here
** Suggestion: split this issue up per property. I think it makes sense for u-url and can be easily added to the spec as e.g. ".h-x>a[href]:only-of-type:not[.h-*<strong>,.u-*</strong>]". [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** Obviously wrong to assume a link explicitly pointing elsewhere is our "url"
*** More difficult to make a case for photo and especially for name.
*** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
*** ... provide input on this refined proposal here
</div>

=== whitespace collapsing revisited ===
2015-05-27: (raised by [[User:Kevin Marks|Kevin Marks]] per Glenn Jones)

Revising the microformats tests to conform to the "don't collapse whitespace" rule below reveals some non-intuitive cases.
preserving whitespace in addresses is somewhat defensible, but in an implied name it is often unhelpful, as it preserves non-user visible space there for authoring reasons.

For example:
[https://github.com/microformats/tests/commit/a325e0e9bc2089507e69b1883f7065a3316e07c2#diff-d577012c1438978a571c4049179607f0 this test] shows how extraneous whitespace ends up in the <code>name</code>

<code><pre>
<div class="h-review-aggregate">
<div class="p-item h-event">
<h3 class="p-name">Fullfrontal</h3>
<p class="p-description">A one day JavaScript Conference held in Brighton</p>
<p><time class="dt-start" datetime="2012-11-09">9th November 2012</time></p>
</div>

<p class="p-rating">
<span class="p-average value">9.9</span> out of
<span class="p-best">10</span>
based on <span class="p-count">62</span> reviews
</p>
</div>
</pre></code>

give a parsed result of:

<code><pre>
{
"items": [{
"type": ["h-review-aggregate"],
"properties": {
"item": [{
"value": "Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012",
"type": ["h-event"],
"properties": {
"name": ["Fullfrontal"],
"description": ["A one day JavaScript Conference held in Brighton"],
"start": ["2012-11-09"]
}
}],
"rating": ["9.9"],
"average": ["9.9"],
"best": ["10"],
"count": ["62"],
"name": ["Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012\n\n\n9.9 out of \n 10 \n based on 62 reviews"]
}
}],
"rels": {}
}
</pre></code>

The <code>value</code> is a reasonable textual representation of the event, but the implied <code>name</code> is full of spurious whitespace that any consumer would have to strip.

[https://github.com/microformats/tests/commit/4c9690b53b0a2f40440abac8e609c51ac7dd6d56 h-review] has similar issues

2015-05-28: (Addition by [[User:GlennJones|Glenn Jones]])

The example below shows the type of markup most effected by the "implied name" and "don't collapse whitespace" rule working together to produce output that is hard to use without further processing.

<code><pre>
<a class="h-card" href="http://glennjones.net">
<span class="p-given-name">Glenn</span>
<span class="p-family-name">Jones</span>
</a>
</pre></code>

The output for the name property from the above HTML would be <code>Glenn\r\n Jones</code> using the (trim lead/trailing) suggested in the parsing spec. I could of course move the spans onto one line, but it feels fragile to consider whitespace sensitivity in HTML like this. Added to the fact that HTML templating environments often take away that level of whitespace control from authors anyway.

There are issues with both: keeping whitespace, returns and tabs from parsed HTML or collapse that whitespace. If we return the whitespace it becomes mal-formatted for humans because it was only added to make the HTML code understandable and in most cases was not meant to be used/read outside of that context. If we collapse the whitespace we can have issues of whitespace sensitive text from <code><pre></code> etc. being incorrectly formatted.

Providing a CSS aware innerText feature would produce the most useable output, but this is too complex/time consuming to build for most parser developers. In the face of no perfect solution I have taken the 80:20 view, whereby errant whitespace, causes me considerably more problems than mal-formatted <code><pre></code> content so I collapse whitespace on all text returned.

This feature is a non-CSS aware version of innerText. It does not cover all rendering edge cases, but enough to produce practical output.

For now, I have started changing the node parser to flag "white-space collapsing" as an experimental feature which is off by default i.e. http://glennjones.net/tools/microformats/ but personally I will parse everything with this on as I find it the most practical solution.

Not sure where that leaves me on the options below.

Options:

Choose from:
# keep as is and every parser client has to post process for common cases.
# '''keep as is but have mf2 parser trim leading/trailing whitespace (likely to provide desired result and be reasonably backcompat)'''
#* +1 my preference of the two options. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
#* +1 though this doesn't solve any of the problems discussed above, it's still worth doing [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
#* +1 will help parsers be more consistent with each other, and I haven't ever encountered a case where preserving leading/trailing whitespace was desirable [[User:Kylewm|Kylewm]] 20:45, 8 June 2015 (UTC)

2015-06-08 option 2 resolved by consensus and implementation in mf2py.

Somewhat orthogonal:
* make <code>value</code> on properties with children normalise whitespace
** -1 Seems like a bad idea as this "value" is supposed to be the same as if there was no embedded child microformat. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
* make implied <code>name</code> normalise whitespace.
** +0 This is reasonable and already done somewhat in the parsing spec (trim lead/trailing). [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** +1 Given the universality of name, this would fix most of the issues we see. [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
* Put \n in textual forms if there is a <code><p></code> tag in the original.
** -1 that's a long path to go down with whitespace equivalents for HTML markup. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** would only preserving whitespace if in <pre> be an 80:20 compromise? [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)

Because there are both code markup and specific vocabulary (label) needs for preserving whitespace, we are compelled to preserve in general, perhaps except for very specific limited generic cases (e.g. trim leading/trailing, "value" parsing, implied name). [[User:Tantek|Tantek]]

=== u- parsing iframe src ===
Currently if I put u-* on an iframe it gets the value of the fallback text. This seems a shame. Getting the URL seems a sensible answer.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== i- parsing iframe src ===

More controversially, what about using an iframe for transclusion? A use case here is comments on a static site. Currently, on eg http://www.kevinmarks.com/microformatschema.html the comments are injected via JS, making them opaque to parsers and thus precluding further parsing such as salmentions.

If instead they were an iframe embedding them, a parser could optionally fetch its contents, parse them, and include them in the parsed mf2 output at that point. Overloading u-* for this seems wrong; e-* as below for srcdoc would have a different effect; this implies a new prefix directive would be needed. A strawman i-* (for include) may work.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== e- parsing iframe srcdoc ===
<div class="discussion">
* Proposal: addition of a new e-* parsing rule for iframe elements with srcdoc attributes. E.G.

<source lang="html4strict">
<div class="h-entry">
<iframe class="e-content" srcdoc="<p>A paragraph of HTML with "quoted quotes" &amp; doubly quoted ampersands</p>" />
</div>
</source>
<source lang="javascript">
{
"items": [{
"type": ["h-entry"],
"properties": {
"content": ["<p>A paragraph of HTML with "quoted quotes" & doubly quoted ampersands</p>"]
}
}]
}
</source>

This would allow, for example, HTML comments to be sandboxed inside iframes but still parsable as microformats.

I believe the correct processing would be to leave " entities as they are but to unescape any doubly-escaped ampersands.

** Is there any use case for that? —[[User:TomMorris|Tom Morris]] 12:32, 14 September 2013 (UTC)
** +1 we need documentation of use case and existing sites publishing iframe srcdoc like this - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
** Rejected by consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 properties on select ===
How should select elements with properties be treated any differently?

Awaiting real world examples / stronger use-cases, until then no special treatment of select elements with properties:
<div class="discussion">
* Are there any real world examples of select elements with microformats properties?
* What would the use-case be for putting a microformats property class name on a select element?
* Nothing special. By consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 root name on form ===
See what to do about <em>root class names</em> on <code><form></code> elements in particular:
* [[hcard-input]]

Awaiting real world examples / stronger use-cases, until then, no special treatment of root class names on <code><form></code> elements:
<div class="discussion">
* Are there any real world examples of a <code><form></code> element with a microformats root class name?
* [[hcard-input]] is one possible use-case, is anyone attempting to use forms for hCard input, e.g. with scripts to help make it work?
* Are there other use-cases for putting a microformats root class name on a <code><form></code> element?
* As of [[2015-01-20]] - no consensus - need more input as to when/why this is useful to do anything special.
</div>

===Parsing Literal Values===
Issue raised by: [[User:BenWard|Ben Ward]]

It is proposed for microformats2 that all microformats be parsable from just their root element, e.g. <code><p class="h-card">Ben Ward</p></code> would create an hCard with the following properties after parsing:

<source lang=javascript>
{
'type': ['h-card'],
'properties': {
'name': ['Ben Ward']
}
}
</source>

This is a four-fold change from the current [[hCard]]:
# type is generically identifiable as a microformat root, even in parsed form. The use of the 'h-' prefix persists into the type of the object. This is deliberately so, as a result of re-using the JSON data model of microdata which itself is re-using a common JSON convention, such that microformatted data is clearly distinguishable (as opposed to any other random schema that may be using a similar data model).
# root-class-only support. Per [[microformats-2-implied-properties]], the ''name'' property is implied by the entirety of the root class name element.
# 'name' instead of 'fn'. As also documented in [[microformats-2-implied-properties]], the continuous challenges/problems and need to repeatedly re-explain 'fn' over the years combined with the real-world market response of nearly every other party doing a person vocabulary renaming 'fn' to 'name', microformats 2 makes this change as well.
# There is no automatic parse-time inferring of <code>'given-name': ['Ben']</code> and <code>'family-name': ['Ward']</code>. Any such inferring *might* be made by a vCard converter, but is left up to that specific application (not all applications) built on that vocabulary, though even in that case it may not be necessary, as an empty "N:;;;" [[vCard]] property is sufficient to satisfy the N property requirement of [[vCard]], and also causes no problems when imported into various [[vcard-implementations]].

It is required of the extractor to understand that when a microformats object specifies no explicit child properties, that it must treat <code>h-card</code> as having a <code>p-name</code>. But, the parser is generic, so it also treats <code>h-review</code>, <code>h-entry</code>, <code>h-recipe</code>, <code>h-geo</code> as having a ‘<code>p-name</code>’.

As a result, specific vocabularies are evolved to drop their specific form of name (e.g. fn, summary, entry-title) and simplified to use a common 'name' property instead.

Note: while the overwhelming majority of real world publishing/consuming uses of microformats do so with proper nouns which have names (and thus this parser-level incorporation of an implied 'name'), there are some formats that do not have a 'name' semantic. For example, [[geo]], [[adr]], and possibly if/when developed, units of measure, length, cost. The current thinking is that the benefits to the far greater proper-noun use-case of microformats outweigh the technical inelegance of having an extra/ignored 'name' property on formats that lack such a semantic.

Some formats also may appear in theory to better imply some other property, e.g. a review might be thought to imply its ''content'', not its name, and an Atom entry its ''content'', not its title, but in practice (actual publishing patterns) this is not the case. Typically, brief unstructured reviews (or mentions thereof) provide a ''summary'' (often hyperlinked to an expanded structured form) of that review, not its content, and similarly, brief unstructured posts (e.g. RSS items) have historically most often been link blog items which include the title of an item and a link. Short status updates as well established by Twitter are newer and would seem to imply purely content with no title, at least semantically, however, even Twitter populates the RSS title and ATOM entry title of their feeds with the content. It's not clear what went into that decision, however, that's likely irrelevant, as the outcome turns out to be emergent consistency among publishing behaviors.

To avoid overloading or undermining the semantics of a vocabulary, I propose that we handle this at the extractor level in a simpler fashion: Define a new property for literal data, that an extractor will provide if no other information was available. All ''interpreters'' may then be instructed that in the event that an object has no properties, it can attempt to interpret the literal value from the page instead.

* This was one of the design iterations I went through which led me to the current implied 'name' design. Another iteration was the ability for a vocabulary to specify a single required property which was implied if there were no properties provided. However, the combination of the fact that in most cases such single required properties were quite name-like, and that a vocabulary-specific rule like that would then bind parsers to specific vocabularies (even so slightly) led me to collapse them into implying a 'name'. It's not perfect, but it's the best alternative so far that balances practical convenience of publishing/consuming, avoids vocabulary-specific knowledge in the parser, and technical (in)elegance. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

In existing microformats, the closest existing example we have for this is the <code>label</code> property in hCard, which is used to represent the literal address label for a place. It is a corresponding piece of <code>fn</code>, <code>org</code> and <code>adr</code> in combination, but has no structure in and of itself. Possibly, every microformat could have a <code>label</code> form where structured data is unavailable.

However in practice, the hCard <code>label</code> property is both little understood and little used. It's not even clear that it ought to be kept for microformats 2 (no known consumers, very few (if any?) real-world non-test publishers). This disuse is likely a good indicator that we should avoid basing anything on its design.

Alternatively, <code>value</code> is used throughout microformats to target a generic value (e.g. in combination with <code>price</code> in hListing.) It has been proposed that when parsing properties that are also themselves microformats, we create native objects of the form:

{
'value': '1900 12th Street, San Francisco, CA 94'
, 'type': ['h-adr']
, 'properties': {
'street-address': '1900 12th Street'
, 'etc': 'etc'
}
}

We could apply this same pattern to the root level:

{
type: [h-card]
, properties: {}
, value: 'Ben Ward'
}

In this case, an interpreter or implementation is responsible for using <code>value</code> in place of <code>fn</code>, or restructuring the object. It would be the responsibility of each vocabulary to define its root property. The parsing layer of microformats 2.0 would not impose semantics or naming onto that.

For another example, h-geo would end up like this:

{
type: [h-geo]
, properties: {}
, value: '1.3232;-0.543'
}

* This is an alternative I've been considering as well: [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)
** 'value' is more generic than 'name' (applies to more vocabularies) with the trade-off that it naturally has less (weaker) semantics.
*** +1 I think that having naturally weaker semantics would be appropriate for this parsing functionality. —[[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC)
** The interesting thing that this analysis has revealed is that there appear to be two distinct clusters of microformats, the much more commonly used/understood/useful proper-noun microformats which markup things with names (people, events, reviews, recipes), and the less used compound-data microformats which are often used ''inside'' other microformats and just have some sort of semi-structured value (adr, geo, measure, and perhaps even things like tel). Perhaps this is implying the possibility and some degree of utility for ''two'' microformats root class name prefixes, 'h-' for existing proper-noun microformats, and something else ('m-' for microformat/molecule?, 's-' for structured-value?, 'v-' for value (though historically "v-"/"v." has meant "vendor-specific")?) for unnamed structured data microformats.
*** This more and more feels like a good idea, and I'm leaning toward "s-" for struct / structure / structured value. "s-" works just like "h-" except that it doesn't imply any properties at parse time. We can try it and see what happens. There's also no harm if publishers just use "h-" structures, they just (possibly) get a few extra properties if they happen to omit properties.
** Parallels the same JSON when a property has both a string value ''and'' is a structure itself.
*** Changed my mind on this. The parallel is not quite there. 'name'/'url'/'photo' are only implied if there are NO properties, where as the JSON string value + structure convention *always* provides a 'value'. [[User:Tantek|Tantek]] 22:39, 4 October 2011 (UTC)
*** And due to this difference in behavior ('value' is there when nested properties are present, whereas 'name' is only implied when there are no properties specified), I think it's correct to keep them separate, i.e. stick with implied 'name'. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
** However, I'm still currently leaning towards the practical convenience of providing a 'name' for the vast majority of microformats uses, rather than diluting this feature for the sake of avoiding implying inapplicable semantics to the few plain structured data microformats, and even then, only when no properties are explicitly specified! I'd rather introduce a new root prefix for those than lose the simplicity and utility of implied 'name'. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

== resolved ==
=== When to collapse whitespace in properties ===

The spec doesn’t explicitly require whitespace to be collapsed or not. The official mf2 test suite requires it to be collapsed.

Reasons why whitespace ''shouldn’t'' be collapsed:
* Plaintext property representations of syntax-highlighted code, poetry and song lyrics require whitespace to be present
* Whether or not whitespace is an important part of the content being parsed is determined by css white-space and CANNOT be inferred from HTML markup alone

Resolution 2013-11-12: Agreed, whitespace should not be collapsed (other than normal HTML5 parsing rules). The spec now refers to "textContent" rather than "innertext" to make this explicit.

=== How to interpret mf2 classnames on form inputs ===
E.G. how to parse:

<source lang=html4strict>
<input class="u-url" value="https://brennannovak.com/notes/338" />
</source>

Examples in the wild: https://brennannovak.com/notes/338

See proposal:
* [[hcard-parsing-brainstorming#input_element_handling]]

Resolution 2013-11-12: Per that proposal, p- u- dt- properties on input[value] elements now use the value attribute.

=== mixture of microformats2 and classic microformats classnames on different elements ===
Some sites in the wild have mistakenly combined classic mf and mf2 markup in ways which misrepresent the content if parsed in BC mode.

Typically this is caused by putting classic and mf2 classnames for the same vocabulary on different elements, e.g:

<source lang="html4strict">
<body class="hentry">
<article class="h-entry">
<h1 class="p-name"></h1>
</article>
</body>
</source>

Sites where this has been observed:
* http://acegiak.machinespirit.net/2013/10/17/barnaby-walters-notes-another-thing-i-love-about-the-web-users-have-the-power-to-take-control-of-their-uis-and-improve-their-own-experiences-aside-drm-for-html-would-prevent-this-from-being-possibl/
* http://shawfactor.com/2013/08/06/thoughts-on-extending-webmentions/ (fixed)
* http://notizblog.org/2013/06/18/the-rise-of-the-indieweb/ (fixed)

Discussion:

* As far as I can tell, the problems in all of these examples were caused by mf2 markup being injected by a wordpress plugin, but classic mf classnames being present further up the DOM in the themes. When parsed in compatibility mode, the classic mf classnames are transformed into mf2 classnames, making the original mf2 classnames look like children of empty items.
* Turns out this isn’t theme-specific, WordPress injects hentry via PHP [http://indiewebcamp.com/irc/2013-10-22/line/1382448759]. The bug with the wordpress mf2 plugin is resolved as of [http://indiewebcamp.com/irc/2013-10-22/line/1382449035 2013-10-22] --[[User:Barnabywalters|bw]] 13:38, 22 October 2013 (UTC)

=== e- and p- escaping levels ===
<div class="discussion">
* The fact that the parsed value of any element with .e-* is at a different level of escaping to the parsed values of p-*, dt-* etc. without any indication of how the property was parsed in the output is a security problem. For example:

<table style="width: 100%">
<tr>
<th>input</th>
<th>output</th>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="p-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="e-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
</table>

* As a parser developer, the most straightforward way I can think of solving this is to add an option (enabled by default) which encodes HTML special characters on all non e-* properties, so the developer knows that all property values are going to be at the same level of escaping. --[[User:Barnabywalters|bw]] 20:00, 15 June 2013 (UTC)
** Your suggestion of auto-HTML-encoding p-*/u-*/dt-* property values is the most sensible I think. I would NOT make it an option, as it makes sense write consistent microformats2 consumers. - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
** Can you think of any existing apps/consumers of microformats2 via the parser that would break? What would indieweb comments parsers do? - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
*** The only breakage which might occur would be over-encoding of non e-* properties, but I’ll release this update as v0.2.0 and warn people about the changes. The worst thing which could happen is that some comments look a bit weird, as opposed to the current worst possible scenario of easy XSS attacks --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** We should also decide exactly which characters get encoded — just angle brackets, or quotes/ampersands as well? --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** I am not sure about this, it seems more like a helper function rather than a core feature of the parser. Personally I would like to store data as text and encode only when I am going to use and I known the format it is going to be use in. --[[User:GlennJones|Glenn Jones]] 9:54, 14 July 2013 (UTC)
***After the discussion on the indiewebcamp IRC with Barnaby Walters I now understand the XSS issue that this change is trying to address. A rogue author could include HTML with scripts to execute a XSS attack. These could be masked by switch prefixes i.e. p-* to e-* on a well use property. As the consumer does not see the prefix in the JSON output they have no idea if a property will content HTML or text. I will update my two parsers and the test suite --[[User:GlennJones|Glenn Jones]] 8:02, 17 July 2013 (UTC)
**So what about an author setting a property to e-* when it would normal be p-*, dt-* or u-* i.e.
<source lang=html4strict>
<div class="h-card"><p class="e-name"><script> alert('xss test') </script></p></div>
</source>
** per [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]], parsers should never automatically attempt to HTML-special-characters encode - as that would provide the client of the parser a false sense of security. It's *always* up to client code to escape any text being output to HTML *at the moment it is output to HTML* and never before, because they can never trust that any text from storage/elsewhere has for sure been escaped or not. - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** Should we not encode e-* as well and the consumer can decode at their own risk --[[User:GlennJones|Glenn Jones]] 18:42, 21 July 2013 (UTC)
*** No, never, per above point from [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** See [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] etherpad: https://etherpad.mozilla.org/microformats2parsing for more details on the resolution to this issue - and incorporate here (then move to resolved section below). - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
* Resolved by changes to the parsing spec: all properties are plaintext (non-HTML escaped), e-* properties result in a dictionary with <code>value</code> = plaintext version, <code>html</code> = raw HTML version
----

</div>

=== br hr empty string ===
<div class="discussion">
* The parsing rule 'else if br.p-x or hr.p-x, then return "" (empty string)' for p-* can cause any code consuming the API to become quite bloated. It means that you have test every array value to see if its an empty string. It is also unclear to me what the purpose of this mark-up pattern is for [[User:GlennJones|Glenn Jones]]
** Upon reconsidering this, I agree with you, this is an unlikely use case. If a publisher wants to explicitly set an empty property "p-foo" they can simply write <code><span class="p-foo"></span></code> which looks explicit. Whereas BR and HR tags are often just presentational, so we should both not encourage usage of them for semantics, and anyone that did use them would be subject to likely loss of semantics upon a redesign (that got rid of those particular BR and HR tags). I'm going to remove them from the parsing spec. - [[User:Tantek|Tantek]] 15:29, 10 February 2013 (UTC)
</div>

=== datetime examples without T delimiter ===
<div class="discussion">
* The examples in the wiki microformats-2 pages such h-entry and h-entry had datetime without the 'T' delimiter between date and time. ie
<source lang="html4strict">
<time class="dt-published" datetime="2013-06-13 12:00:00">13<sup>th</sup> June 2013</time>
</source>
I have updated the pages. As far as I known this is a new pattern for dates. Was it a mistake in the examples or is it a new datetime pattern.
** The [[HTML5]] "time" element, and "datetime" attribute allow for space <span style="white-space:nowrap">" "</span> as a separator between date and time as well as "T", thus we allow it for microformats as well. The <span style="white-space:nowrap">" "</span> separator is preferred as the date and time are more readable when separated by a space. The examples noted in those specs deliberately use this. - [[User:Tantek|Tantek]] 18:48, 15 July 2013 (UTC)
</div>

=== rel-alternate absent optional attributes ===
<div class="discussion">
* What should rel-alternate parsing do when one of the optional attributes specified (<kbd>hreflang</kbd> or <kbd>media</kbd> or both) is not there? The options seem to be:
*# leave the corresponding key out of the alternate JSON object
*#* This one. Leave the corresponding key out.
*# include the corresponding key in the alternate JSON object, but set the value to the JSON null object
*# include the corresponding key in the alternate JSON object, but set the value to a blank string
*# something I haven't thought of

I haven't checked the existing implementations, but Barnaby said he's not sure what the appropriate way to deal with it is either. —[[User:TomMorris|Tom Morris]] 15:41, 9 August 2013 (UTC)
</div>

=== rel-alternate and type attribute ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Should rel-alternate parsing also pick up the <code>type</code> attribute? It’s fairly widely used, e.g. for ATOM feeds.
** Numerous existing sites/pages have various [[rel-alternate]] uses with a type attribute for feeds/APIs so that's good enough to add this for help with discovery in general. Rel parsing updated. - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
</div>

=== Extraction vs Interpretation ===
Issue raised by: [[User:BenWard|Ben Ward]]

A microformats ‘1.0’ parser performs the following function:

* Given a piece of HTML content, discover a known microformat, extract it, apply various extraction patterns based upon the HTML mark-up used (e.g. include pattern, <code>abbr</code> patterns, date-time patterns, value-title pattern), apply various content optimisations where applicable, and return the result in an object native to the programming language.

This is performing two types of function: Extraction of data from an HTML document or fragment, ''and'' interpretation and optimisation of that content to match the rules set out by a vocabulary specification.

It is only possible to write a generic parser that covers the first half of this task: Extraction, and application of global rules based on HTML elements and patterns common to all formats.

The purpose of a generic parser (as supported by use cases such as search engines, and other crawlers) is:

To provide a way for tools to extract rich data from a page for native storage, such that the data may be interpreted later by applications. This allows microformats to be crawled, and indexed, and removes the need to include complex HTML parsing within every implementation of microformat data.

Microformats will continue to define various vocabulary-specific optimisations. as part of the design to be optimised for authors. For example: The <code>fn</code> pattern in [[hcard]], or the <code>lat;long</code> pattern in [[geo]], as well as default values for properties, such as the maximum rating in an [[hreview]].
* Actually, no, as it is defined currently, microformats 2 ''drops'' vocabulary-specific optimizations. Such optimizations have often been too inapplicable, error prone or i18n-unsafe (e.g. fn to given-name + family-name fails for both numerous cases where middlenames/initials are used, and in general in numerous Asian languages where given/family name order is the reverse of Western English conventions, or languages with multiple family-names, e.g. Spanish - see [[hcard-issues-resolved]] for more). This is a deliberate cutting of a "feature" from microformats 1, it is a deliberate model simplification design decision. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

==== Extraction resolution ====
Proposed resolution:

Microformats2 should refer only to ''extraction'' of microformats. Vocabularies should in turn document their appropriate optimisations, which will need to be applied by implementations, or a companion to an extractor, which I'll refer to here as an ‘interpreter’.
* Vocabularies will no longer have optimizations, this is again deliberately, as they've been shown to be more error prone than helpful. Thus there should be no need for any vocabulary-specific 'interpreters'. However, due to design quirks in various legacy/interchange formats, ''export conversions algorithms'' to those legacy/interchange formats will require some additional legacy-format-specific rules (e.g. odd "required" rules in [[Atom]] or [[vCard]] will require specific synthesis rules, limitations in said formats will require filtering of some values, e.g. [[vcard3]] BDAY disallows vague birthdays like year-month and --month-day - subsequently allowed in [[vcard4]]). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

A microformats2 ‘extractor’, in combination with the functionality of a domain and format-aware ‘interpreter’ (either another shared component, or part of the implementation itself) would be equivalent to a microformats 1.0 ‘parser.’
* A microformats2 parser is both generic (no knowledge of specific vocabularies), and lacks any/all such vocabulary-specific rules as compared to a microformats 1.0 [[hcard-parsing|parser]] with the exception of a 1) a limited list of well-established/interoperable backward compat root class names (of current [[microformats]] that are or can be soon shown to be specifications/standards per the [[process]]), 2) flat sets of backward compat property names (some with prefix/name specific conversion) for each of those backward compat root class names. This is a deliberate design decision that makes microformats 2 more "micro", and yes this means that even with such backward compat support, this simple form of backward compat may mean that some existing microformats 1 content breaks. We'll assess those and iterate on a documented case-by-case basis rather than attempt to maintain theoretical 100% backward compatibility (since many current microformats format-specific-features are either unused, or may have caused more problems than solutions). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

N.B. I'll rewrite some of these as [[microformats2-parsing-faq]] to help better clarify. The reasoning that led to most of these design decisions is documented in the [[microformats-2#About_This_Brainstorm|microformats 2: About This Brainstorm]] section and following sections. I'll recheck those sections to see if/where reasoning for some of the above noted design decisions may have been missed, and back-fill accordingly. This is necessary because [[microformats2]] is a evolutionary result of simultaneously addressing both numerous generic [[issues]] as well as various common [[hcard-issues-resolved|format]]-[[hcalendar-issues-resolved|specific]] [[mfo|problems]] in microformats1 syntax and vocabularies. The very number of changes may make it more challenging (from a microformats1 perspective) to see why any particular design change has been made. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

This issue can be moved from resolved to closed once the above-mentioned write-ups have occurred.

===Parsing properties from rel attributes===
tl;dr resolution: As of 2013, [[microformats2-parsing]] handles parsing all link and a href rel values at document scope level, and producing canonical JSON accordingly. - [[User:Tantek|Tantek]]

Issue raised by [[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC):

* Currently, hAtom parses `bookmark` as a permalink
* Various microformats parse `rel=tag` as tags
* The current proposal for parsing does not allow parsing properties from rel attributes.

Microformats parsers could instead extract ''all'' link relationships from rel attributes within an microformat object, parsing them as if a u- prefixed property.
* Minor nit: Rather than same as a u- prefixed property, I think such "rel" properties should be parsed purely from the <code>href</code> attribute on <code><a></code> and <code><area></code> elements and nothing more. I would strongly disagree to extending rel to apply to other elements with URLs like img src, object data, or to apply to elements in general like div. That's the path that RDFa has taken and caused much confusion as a result. [[User:Tantek|Tantek]] 07:39, 5 October 2011 (UTC)
** Agree: That seems like a perfectly reasonable restriction. --[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)

This results in:

* Continuing use of the <code>rel</code> attribute in HTML, thereby building on HTML semantics rather than bypassing them or ignoring them in favour of something less meaningful.
* Parsing hAtom objects contain a property named <code>bookmark</code>, in place of <code>permalink</code>.
* All microformats that use <code>rel-tag</code> would contain a property named… <code>tag</code>. Perfect.

Since <code>rel</code> attributes are not overloaded for other functionality like class is, and other uses of <code>rel</code> within content are low (and non-semantic uses are nil, to the best of my knowledge) the risk of property pollution would be extremely low.

Note, with regard to this last point, that a generic microformats parser ''will'' parse false-positive properties, and ''will'' parse objects in combined chunks, rather than individually by format. Extracted objects will often not represent a vocabulary without further processing.

<div class="discussion">
* This sounds like it might be workable. Let's try it and see how well authors "get it". - [[User:Tantek|Tantek]]
* Possible issue: do we have any collisions between class property names and rel names? (I don't think so offhand, but useful to ask the question). - [[User:Tantek|Tantek]]
** None that I can think of in microformats. There is the case of Google's <code>rel=author</code> and <code>p-author</code> in hAtom. However, the next point, about mfo scoping, would cover it in most situations (rel-author on a hyperlink within an hcard wouldn't be applied to the hentry.) The one situation in a parse tree where it's ambiguous would be this:
<source lang=html4strict>
<a href="p-author h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
** I can think of two quite reasonable solutions:
*** 1. Declare that class properties take precedence over rel properties of the same name, discarding rel values if a class is also found, or
*** 2. Since all properties are now multi-value anyway, the hAtom object could be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
** —[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)
*** Option 2 makes sense and is consistent with the rest of the multi-value parsing/handling. - [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
*** What about without the 'p-author'?
<source lang=html4strict>
<a href="h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
Should that be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
Or
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': 'http://benward.me' /* from the rel="author" */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},

],
…
}
}
</source>
*** And if the former, then we're presumably saying that the value parsed due to the presence of a rel is always its own value, and does not combine with any other structures. I am fine with this, but I wanted to make sure we are ok with that explicitly. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
**** +1 I think that since the rel attribute is specifically concerned with the relation to an href attribute, it should not be combined with other structures that are rightly declared uses classes.
***** The more I've thought about this and how consuming applications may want to treat rel semantics, the more it seems correct to keep rel semantics distinct from class semantics. Class semantics are quite general/flexible, whereas rel is quite specific, naming something else in terms of a relationship from the current page/microformat's perspective. I think we should consider putting rel values in their own 'rel' collection, separate from the 'properties' collection. E.g. the original rel-author p-author h-card markup example would be parsed into this:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
}
],
…
}
'rel': {
'author': ['http://benward.me'] /* from the rel="author" */
}
}
</source>
***** and if a post had multiple authors:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from p-author */
'type': ['h-card'], /* from h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
{
'value': ['Tantek Çelik'], /* from 2nd p-author */
'type': ['h-card'], /* from 2nd h-card ... */
'properties': {
'name': ['Tantek Çelik'],
'url': ['http://tantek.com']
},
],
…
}
'rel': {
'author': [
'http://benward.me', /* from rel="author" */
'http://tantek.com' /* from 2nd rel="author" */
]
}
}
</source>
***** This preserves the semantic distinction between rel and properties in general, and leaves it up to a higher-level application to implement any logic around showing "more info" about a rel-author, e.g. by correlating the rel-author URL with the 'url' of an hCard it found in the same entry. However, note that even in the earlier JSON data model, the rel-author value just shows up as another property value, and any higher level application would still have to do some correlation logic. At least with this JSON data model, applications that may be looking for a rel value in particular, or a property value in particular can do so without having one unintentionally pollute the other. [[User:Tantek|Tantek]] 17:33, 6 October 2011 (UTC)

* Presumably we'd apply all the same property scoping rules to rel scoping as well. E.g. a rel hyperlink inside a microformat won't be seen by any containing microformat. - [[User:Tantek|Tantek]]
** Correct, it should be parsed in the same scope as all other class properties in the object.
*** Update: all rel microformats are now parsed at page-scope. Per-microformat scoping of rel has been found to be too confusing in practice (and against the general semantic of rel expressed in the HTML/HTML5 specs) [[User:Tantek|Tantek]] 01:00, 10 July 2014 (UTC)

This issue can be moved from resolved to closed once we've verified that all the above-mentioned and implied needs to write things up have occurred.
</div>

=== deduping of rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-02 by [[User:Kevin Marks|Kevin Marks]]
* 2015-06-05 resolved by consensus and one real world implementation proof of implementability and verification of expected results. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

Many sites have multiple duplicate rel links to the same url - a very common case is WordPress home pages eg [http://ma.tt ma.tt]

Each post on the page has a block like
<code><pre>
<div class="entry-meta">
<span class="date">
<a href="http://ma.tt/2015/05/beethoven-mozart-bach/"
title="Permalink to Beethoven, Mozart, Bach" rel="bookmark">
<time class="entry-date" datetime="2015-05-31T22:42:00+00:00">May 31, 2015</time></a></span>
<span class="categories-links">
<a href="http://ma.tt/category/asides/" rel="category tag">Asides</a></span>
<span class="author vcard">
<a class="url fn n" href="http://ma.tt/author/saxmatt/"
title="View all posts by Matt" rel="author">Matt</a></span>
</div></pre></code>

As currently defined, the parser will create duplicate entries in <code>rels</code> for each post:
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/",
"https://ma.tt/"
],
}
</pre></code>

and in the <code>rel-urls</code> we will also see:
<code><pre>
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author",
"author",
"author",
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home",
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag",
"category",
"tag",
"category",
"tag",
"category",
"tag"
],
"text": "Asides"
}
</pre></code>
These duplicates are unhelpful for parser consumers. We should:
* make them both sets - only listing distinct values. This will remove ordering information, but order is irrelevant for rel in html.
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/"
],
}
…
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag"
],
"text": "Asides"
}
</pre></code>

* possibly we could also make <code>title</code> <code>text</code> <code>type</code> sets too. That would solve the information loss issue with the current parsers
** Resolution: in the case of duplicate other attributes, first one set wins. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

<div class="discussion">
* +1 as the proposer. A version of mf2py that does this is running at unmung,com. see [http://www.unmung.com/mf2?url=https%3A%2F%2Fma.tt&html=&pretty=on fro ma.tt] or [http://www.unmung.com/?html=%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E&pretty=on a simple test] [[User:Kevin Marks|Kevin Marks]] 23:49, 2 June 2015 (UTC)
* +1 makes sense to me, and not having them be sets in the current spec is likely an oversight on my part. Thanks for noting this issue. [[User:Tantek|Tantek]] 05:28, 3 June 2015 (UTC)
</div>

=== include alternates in rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 resolved per consensus and one real world implementation proof of implementability. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* add "alternate" rels to the "rels" collection to make them easier to look-up in "rel-urls" - that is, all rel values end up in "rels" collections. No exceptions.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls".
* +1 This makes sense to me, as the <code>rels</code> and <code>rel-urls</code> should match so you can lookup in rels first, then get details about urls from rel-urls. We can drop "alternates" independently from this change. [[User:Kevin Marks|Kevin Marks]] 00:23, 2 June 2015 (UTC)
** +1 drop "alternates" independently now made a separate issue. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
* +1 Makes sense. And I agree with Kevin; I think parsers should deprecate "alternates" for now and drop it after a version cycle or two. [[User:Kylewm|Kylewm]] 00:30, 2 June 2015 (UTC)
* implemented in [https://github.com/kevinmarks/mf2py/commit/4dba45200eef11da811f64817d02044ab9e98b77 my fork of mf2py] and running on [http://www.unmung.com/?html=%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fa%22%3Eauthor+a%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fb%22%3Eauthor+b%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F1%22%3Epost+1%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F2%22%3Epost+2%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22alternate+home%22%0D%0A+++href%3D%22http%3A%2F%2Fexample.com%2Ffr%22%0D%0A+++media%3D%22handheld%22%0D%0A+++hreflang%3D%22fr%22%3EFrench+mobile+homepage%3C%2Fa%3E&pretty=on unmung] [[User:Kevin Marks|Kevin Marks]] 01:29, 2 June 2015 (UTC)
</div>

=== Empty properties overridden by implied rules against user expectation ===
Status: resolved, existing behavior correct, no changes to parsing spec.

2015-07-03: raised by [[User:Glenn Jones|Glenn Jones]]

Emma Kuo brought up an issue (https://github.com/glennjones/microformat-node/issues/22) based on following the indieweb note pattern, where the content of a note is given both the e-content and p-name classes. If the element containing the notes only has none text content like image the p-name can have unexpected value. Here is the example she gave:

<code><pre>
<div class="h-entry">
<a href="http://this.site/photo" class="u-url"></a>
<div class="e-content p-name"><img src="photo.jpg" class="u-photo"/></div>
Some extraneous text
<div class="h-cite">
<a href="http://someother.site/like" class="u-url"></a>
<a href="http://this.site/photo" class="u-like-of"></a>
<div class="e-content p-name">liked this</div>
</div>
</div>
</pre></code>

At the moment I parser this as follows: - if a property (p-name) is empty do not add it to the output. In this case "empty" is classed as not containing any non-whitespace text. As far as I known there is no guidance on how to handle "empty" properties in microformats paring rules, so I followed the conventions of JSON API's not to return "empty" properties.

The side effect of the above is that p-name also has a number of "implied rules". The "implied rules" try to automatically fill properties like p-name if there is no defined value. In the example above it uses the textContent of the parent h-entry, so value of the h-entry>p-name is the text content of the h-cite i.e. "likes this".

Options:

1. We should not allow the "implied name rule" to get textContent from within a child h-*
<div class="discussion">
* <strike>+1 I believe this is inline with how we parse properties and will meet user/author expectations [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* -1 A nested h-* is still part of the content of the parent h-*, I don't quite understand the rationale for excluding it. For example, I may include lots of h-cards in the body of a post that references people and wouldn't want them to be excluded from the implied name generation. [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* -1 I'm not sure this would solve the problem because auto-filled text could come from the parent h-* ("some extraneous text" in the example above) [[User:emmak|Emma Kuo]] 20:50, 4 July 2015 (UTC)
* -1 I agree with the other -1s. This would break some of the simplicity of the model. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
</div>
2. We should not execute the "implied rules" where there is an author defined "empty" property.
<div class="discussion">
* <strike>-1 Although the output would meet author expectations it is complex for parsers as they will have to keep state for each property through the whole series of parsing rules. [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* +1 An explicit, empty, p-name property should prevent an implicit p-name from being generated. For example tantek.com includes <span class="p-name"></span> at the start of the h-feed to prevent a giant name from being auto-generated. From my reading of the parsing spec, I don't see any reason that blank strings should be excluded from parsing. (mf2py and php-mf2 will both happily include empty strings in their output) [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* +1 We already have interop on this between mf2py and phpmf2, as well as people depending on it to explicitly set empty property values. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
* +1 As we already have interop with two parsers and solid user issue from Emma we should take this approach. [[User:GlennJones|Glenn Jones]] 11:51, 29 July 2015 (UTC)</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== uf2 children inside a classic microformats root class name ===
Status: incorporated into [[microformats2-parsing]]

2015-020: (raised by kylewm) What should microformats2 children inside a classic microformats root class name do?

Options:

1. Nothing. Any unattached uf2 children inside a classic microformats root are ignored. Problems:
<div class="discussion">
* However then there's a possible surprise if/when the author upgrades the classic microformats root to uf2, then all of a sudden all the new uf2 children show-up.
* Another downside: author adds uf2 markup, can't figure out why nothing is happening (because somewhere up the tree in code they didn't touch is classic microformats that are hiding these unattached uf2 children.
</div>
2. Show up in the children collection of the classic microformats root
<div class="discussion">
* Feels most predictable. When you add uf2 root class names anywhere, they will show up in the JSON output hierarchy.
* When you convert ancestor class microformats root class names to uf2 root class names, no surprise in terms of which microformats show up. Same children collection.
* +1 Thus I'm leaning towards this one, despite the fact that classic microformats never had a concept of generic unattached children. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)
* +1 I think this is the best option I will implement it and update the wiki once its in the JavaScript parser. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>
3. Show up as peers to the classic microformats root. Issue(s)
<div class="discussion">
* Has ths surprise aspect of if/when you convert the classic root class name to a uf2 root class name, the former peers become unattached children.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== any h- root class name overrides and stops backcompat root ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: The presence of any h-* root class name overrides and stop any backcompat parsing of classic microformats root class names on that same element. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for restricting backcompat root class name to only seeing backcompat property class names
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
* I don't think I understand this rule. If I was stop all parsing of of classic microformats in the presence of any h-* root in a document then some of the other rules such as "uf2 children inside a classic microformats root class name" do not make sense. Could this item be expanded and explained a bit more? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** added "on that same element" as that was what we were discussing/implying in this issue. [[User:Tantek|Tantek]] 22:49, 18 September 2015 (UTC)
</div>

=== backcompat classic microformats should only see backcompat properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats vocabulary that indicates a backcompat root class name (and thus an absence of the microformats2 equivalent on the same element), parsers must only look for the backcompat properties that are specified explicitly for that backcompat root class.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such behaviour was never expected by authors, and crossing a classic microformats root class name with microformats2 property names were never explicitly expected nor specified to work.

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== microformats2 root class names should only see microformats2 properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats2 root class name, only explicit microformats2 properties should be parsed. Any backcompat property names must be ignored.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such microformats2 authors should be expected to do all their microformats markup with microformats2 class names - this is a deliberate expectation so that their microformats aren't polluted with other (classic microformats) coincidentally named generic class names.

Thoughts?
<div class="discussion">
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== implied properties on backcompat parsing unlikely to be intended ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
Since classic microformats had no notion of implied properties, when implied property parsing occurs on backward compat classic microformats root class names, it is unlikely that any implied property (p-name u-url u-photo) was ever intended by the author of the classic microformat. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
Examples:
* see https://indiewebcamp.com/h-entry#bad_hentry_properties for a growing list

'''Proposed resolution:'''

* Be explicit in implied property parsing that it must only be done for explicit 'h-*' root class name microformats, not for any (back)compat parsing of microformats. Please comment on this proposal with "** comment" on new lines below. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
** +1 This makes a lot of sense to me. We should strive to parse mf1 as it was intended by the author, and I think you're right that implied rules are unlikely to be what was intended [[User:Kylewm|Kylewm]] 03:22, 30 December 2014 (UTC)
** +1 I think this will help backcompat parsing, but there are two major things to consider. It may well break some consumer code as the output for a microformats currently always has the name property, there may not be the defences code to check this is true when we remove the implied name rule for classic microformats. The test suite will also need major updating as all the test output for classic microformats will have. I will look into implementing this and report back to the wiki. [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** Also it should be made clear that we are only removing the implied rules from classic microformats parsing and not the value property? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
*** The "parsing for implied properties" section only references name, photo, url properties. Where (in the spec) is the confusion about "value" coming from? [[User:Tantek|Tantek]]
** RESOLVED at [[2015-01-20]] meetup. [[User:Tantek|Tantek]] 04:09, 21 January 2015 (UTC)
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Set implied properties by microformat version"

=== link elements and u- parsing ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Raised by tantek on 2014-07-08 on [http://logs.glob.uno/?c=freenode%23microformats&s=8+Jul+2014&e=9+Jul+2014#c72916 irc]: should the parsing specification for handling u- properties be modified to include the <code>link</code> element? The potential downside is that [[invisible-metadata-is-considered-harmful]], however all known real world examples of <code>link</code> are <em>semi-</em>visible data (not fully hidden).

There are potential cases for wanting to use link as an alternative to <code>a</code> (and <code>area</code>), such as a whole page where the root <code>html</code> element is an <code>h-card</code> and the properties are included across the page: some in visible data in the <code>body</code> while others are in the <code>head</code> as <code>link</code> elements. Example:

One specific use-case is the semi-visible <code>link rel="shortcut icon" href="..."</code> - which is visible sometimes in browser UI, and also when a user chooses "Add to Home Screen" on a mobile device. Such page level icons may be used as a <code>u-photo</code> or <code>u-logo</code> of the containing <code>h-*</code> object on the <code>html</code> element.
* http://adactio.com/about/myself/ on 2014-190
** <em>could</em> use <code><html class=h-card></code> - page is all about Jeremy Keith the person
** <em>icon / logo is only</em> on <code><link></code> tag which <em>could</em> use <code>class=u-logo</code>: <br/><code><link rel="shortcut icon apple-touch-icon" type="image/png" href="/icon.png" /></code>

Another specific use-case is a post permalink page, e.g. with <code><html class=h-entry></code>
* http://waterpigs.co.uk/notes/4WjHpC/
** <em>has</em> <code><html class="no-js h-entry hentry h-as-note" lang="en"></code>

Another use-case is publishing links to PGP/GPG keys linked from the head which is currently handled by <code><link rel=pgpkey></code> which is already supported in existing [[microformats2-parsing#parse_a_hyperlink_element_for_rel_microformats|microformats2 rel parsing]] of <code>link rel</code> elements. Thus there is a (admittedly weak) argument for consistently parsing <em>both</em> <code><link rel></code> <em>and</em> <code><link class="u-*"></code>.

E.g. inside that aforementioned real world <code><html class=h-entry></code> post permalink page example,
* why should <code><link rel="in-reply-to"></code> work
* but not <code><link class="u-in-reply-to"></code> ?
The slightly stronger argument for consistency of link handling is that it <strong>[[simpler|simplifies]]</strong> the publisher (and parser) model:
* <code><a></code> and <code><area></code> work for both <code>rel</code> and <code>class</code>
* why does <code><link></code> only work for <code>rel</code> ?
* it would be <em>simpler</em> if all three tags just worked (in the same way) for both <code>rel</code> and <code>class</code>

'''Should the parsing spec be modified to handle these cases?''' —[[User:TomMorris|Tom Morris]] 09:25, 9 July 2014 (UTC)

** I'm generally in favour. It'd be good to see what other parser developers think. —[[User:TomMorris|Tom Morris]] 10:16, 9 July 2014 (UTC)
** adding this to the parsers won't be an issue. <del datetime="2014-07-09T18:45">The question is should the door be opened to hidden mf data?</del> <ins datetime="2014-07-09T18:45">Up on further reflection, there seems to be no need to distinguish between <code>rel=property</code> and <code>class=u-property</code> on link elements. So I am in favour for consistency.</ins> [[User:KP|Kartik]] 18:30, 2014-07-09 (EST)
** RESOLVED at [[2015-01-20]] meetup. Make link consistent with a.
</div>

=== drop alternates collection ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 split into separate issue from include alternates in rels per implementation feedback from Kevin Marks. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* drop "alternates" as its no longer needed, and all current consuming code clients like rel-urls better anyway.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls" in original issue now "include alternates in rels", we no longer need "alternates", and those with client consuming code have universally indicated that they would rather use rel-urls anyway. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
</div>

== see also ==
* [[microformats2-parsing]]
* [[microformats2]]

microformats2-parsing-issues

2016-03-13T20:42:16Z

Barnabywalters: /* ignore u-camelCase properties */

This page is for documenting issues with the [[microformats2-parsing]] specification.

== issues ==
Open issues in various states of partial resolution from none to nearly resolved.

=== ignore u-camelCase properties ===
Due to Suit CSS (and others? citations?) recent (2015-?) use of "u-*" class names for so-called "[http://davidtheclark.com/on-utility-classes/ utility classes]", we are seeing some false positives in a few very rare instances, e.g.: http://www.unmung.com/mf2?url=http%3A%2F%2Fwww.kevinmarks.com%2Ftwitterutils.html&html=&pretty=on

(Nearly) all these "utility classes" use camelCase for the class name suffixes, thus we can filter them out by looking for camelCase (since microformats class name conventions are always all lowercase and hyphenated), or even just looking for (and rejecting) *any* capital letters.

Proposal:
* microformats2 parsers MUST IGNORE u-* classnames where the * has any uppercase letter(s).

<div class="discussion">
* +1 [[User:Tantek|Tantek]] Let's get this fix rolling quickly to avoid further pollution.
* +1 [[User:Barnabywalters|Barnaby]] php-mf2 already ignores classnames with capitalised prefixes, ignoring any classnames with capital letters seems totally reasonable
* ...
</div>

=== exclude style elements before parsing ===
[http://logs.glob.uno/?c=freenode%23microformats#c85457 2016-01-25 raised in #microformats]

Ran into an issue of a <style> element being parsed as plain text in a p-name. Should [[microformats2-parsing]] be updated to indicate <style> should be excluded when parsing? Appears to implicitly fall under [[microformats2-parsing#note_HTML_parsing_rules]]

Sample link: http://veganstraightedge.com/notes/2016/01/16/tonight-s-dinner-tacocleanse-beverly-hills-c

The <script> tag can be similarly problematic.

Proposal: Drop both <script> and <style> elements completely when parsing any property (including e-* HTML values). [[User:Tantek|Tantek]] 01:01, 29 February 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Aaronpk|aaronpk]] as a consumer of HTML from an e-* property, I will always be sanitizing the HTML and removing <script> and <style> anyway
* +1 [[User:Kylewm|kylewm]]
* 0 [[User:Barnabywalters|Barnaby]] +1 to removing the contents of <script> and <style> from all plaintext properties (and 'value' property in HTML dicts), -1 to removing <script> and <style> from HTML. That’s a job for a sanitization stage. As aaronpk points out, sanitization will have to be done anyway if the content is to be reposted, so doing so in the parser doesn’t actually save anyone any work, but removes information which could be useful to people (example use cases: publishing posts with embedded per-post styling, publishing interactive HTML documents with embedded javascript)
** +1 this seems like reasonable feedback to make a new refined proposal. [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)
</div>

Proposal 2: Drop both <script> and <style> elements completely when parsing any property (except for e-* HTML values, which preserve all markup). [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Barnabywalters|Barnaby]
* ...
</div>

=== use poster if no src on video for u props ===
[https://indiewebcamp.com/irc/2015-12-13#t1450035721661 2015-12-13 raised in #indiewebcamp]

There is a use-case of marking up the "poster" of a video element as the u-featured of an [[h-entry]], to do that, we need to change [[microformats2-parsing#parsing_a_u-_property|u- property parsing]] to look at the poster attribute of the video element, after it's looked for the src attribute.
<blockquote>" else if video.u-x[poster], then get the poster attribute "</blockquote>

Real-world example of markup in the wild:
* http://veganstraightedge.com/videos/2013/5/31/1/backyard-squirrel-buddy
** and likely all other videos posted there.

Background discussion that led to this proposal:
* https://indiewebcamp.com/irc/2015-12-13#t1450035721661

This seems very straightforward so I've added it as PROPOSED directly in the parsing spec. This issue is for tracking the discussion.

Feedback from parser implementers please!
<div class="discussion">
* ...
</div>

=== uf2 children on backcompat properties ===
[http://logs.glob.uno/?c=freenode%23microformats&s=today#c84632 2015-11-24 raised by Calli] in #microformats

Related but different from [[#uf2_children_inside_a_classic_microformats_root_class_name]], when there is a uf2 child directly on a backcompat property, what should happen? E.g.

<source lang=html4strict>
<div class="vcard">
<div class="adr h-adr">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

What is the expected behavior and parser output?

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-adr"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

<div class="discussion">
* Proposal: the nested "adr h-adr" child is treated as an mf2 object, not backcompat, and thus the resulting parsed "locality" property has a single value of "MF2". Proposed by Calli, noting that Glenn Jones's microformatshiv gets that result currently, and it would be easier for him (Calli) to implement this way.
** +1 Tantek, seems reasonable and the reasoning provided is good (we have one implementation this way already)
** +1 Kyle, this is consistent with the resolution to the related issue
** +1 Calli, yes, this is easier for me to implement (than taking both MF1 and MF2 properties) because it is consistent - for me, consistency is the controlling factor in favor rather than ease of parser implementation
** ...
</div>

Another example:

<source lang=html4strict>
<div class="vcard">
<div class="adr h-custom">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-custom"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

Per the [[#any_h-_root_class_name_overrides_and_stops_backcompat_root]] resolution, the class name "h-custom" overrides the use of "adr" as a backcompat root.

=== default generated HTML ===
2015-09-08 raised by Tantek in #indiewebcamp

Should there be a default (perhaps not quite "canonical") way to map/generate HTML+microformats2 from a parsed mf2 JSON output?

E.g. straw proposal:
* JSON/mf2 -> [[XOXO]]+mf2

Existing work / mappings:
* https://github.com/snarfed/granary/blob/master/granary/microformats2.py#L295

Related to:
* https://github.com/snarfed/granary/issues/31

Use-cases:
* default webview / presentation for a site that stores mf2 JSON output
* possibly a way to implement a distributed HTTP webcache retrieval protocol

Thoughts?
<div class="discussion">
* +1 [[User:Tantek|Tantek]] I think we should have this, but am open to proposals on specifics!
* +1 [[User:GlennJones|Glenn]] Also think this is worth looking at, but I am not sure it should be part of the parser spec. Feels like it should be built as a separate library and have it own spec on the microformats wiki.
* ...
</div>

=== Noscript skip/parse ===
2015-07-28

Should mf parsers skip <code><noscript></code> tag in the HTML, like the <code><template></code> tag mentioned in http://microformats.org/wiki/microformats2-parsing#note_HTML_parsing_rules ?

mf2py skips <code><noscript></code> when using the html5lib DOM parser but no when using lxml parser. Example use of <code><noscript></code> https://kartikprabhu.com/ featured images have a no javascript fallback image inside <code><noscript></code> with <code>class='u-featured'</code> markup.
* html5lib actually HTML-escapes the contents of <code><noscript></code>, so to mf2py it just looks like plain text with no tags. In Woodwind, I've resorted to using regex to strip out <code><noscript></code> tags before parsing (very hacky). [[User:Kylewm|Kylewm]] 15:52, 25 August 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] skip noscript (and inside) because in today's typical browsing contexts, nothing in noscript is displayed, thus we should discourage marking up effectively invisible content.
** Proposed change to [[microformats2-parsing#parse_a_document_for_microformats]]:
*** from: "follow the HTML parsing rules"
*** to: "follow the HTML parsing rules (including skipping/omitting <code><noscript></code> elements, e.g. like the html5lib DOM parser)
* -1 [[User:GlennJones|Glenn]] This subject does need to be address, but differently to proposed change. My personal view is that e-* html should be passed through raw and then the consumer can process it in a way they feel fit. Its a case for helper libraries. I am about to build a helper library to do this based on the Readability code to post process e-* html. Other people may want to take different approaches, defining this in the spec feels like move into a whole area of new functionally.

As a separate new point we need to consider "exclude tags" lists for parsed text from html. We should consider <code><noscript></code>, <code><noframe></code> and <code><template></code> there maybe other I have not gone through all the tags in current HTML spec. Also we should consider what to do about the more common pattern of fallback text within media tags <code><video></code>, <code><audio></code> etc. This should be explicitly discussed in the parsing rules. At the moment my experimental text normalisation does exclude tags, but the default text parse does not. Currently the fallback content in media tags like <code><video></code> is added to the parse text. 12:56, 25 Septemeber 2015 (UTC)
* ...
</div>

=== Standard datetime format ===
2015-07-28

http://microformats.org/wiki/microformats2-parsing#parsing_a_dt-_property does not specify any standard format to use for datetimes. e.g. <pre>2015-07-28T12:55:33</pre> vs <pre>2015-07-28 12:55:33</pre>
Would be good to standardize this to compare various parser outputs.

2015-07-29: This subject is (somewhat) covered in http://microformats.org/wiki/iso-8601 As it stands the JavaScript parsers support output in the 3 main profiles, 'W3C Note', 'RFC 3339' and 'HTML5' plus 'auto' which keeps authors format. The default date output for the JavaScript parsers is the same format as the date was originally authored in. This can be changes by setting the options.dateFormat switch to any of the other profiles mentioned. It would be good if other parser also had a switch to force output to a common profiles so we could compare various parser outputs, but I think the default should be how a date was authored. All output whatever profile should also keeps the authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string. This is important if you want to compare parser outputs.

The only exception to this where date and times are combined such as the implied h-event rule for dt-start and dt-end where I output in the HTML5 style 2015-07-29 12:55:33 as there is no predefined author preference and HTML5 profile is more human readable. [[User:GlennJones|Glenn Jones]] 11:02, 29 July 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] output more human readable <code>2015-07-28 12:55:33</code> canonically, with authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string.
** Let's update any test cases as needed for this. - [[User:Tantek|Tantek]]
* ...
</div>

=== implied date for dt properties both mf2 and backcompat ===
The [[value-class-pattern#microformats2_parsers|value class pattern dt-* date proposal]] should apply to both mf2 dt-* properties, and backcompat classic microformats, to preserve the hAtom / hCalendar optimizations noted on that page, but in a generic way.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] 16:12, 18 August 2015 (UTC)
* +1 [[User:Glenn Jones|Glenn Jones]] 20 August 2015
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== implied properties when an explicit class is provided ===
<div class="discussion">
Should "u-url" still be implied if another explicit class is already provided, as below. This is a contrived example, but it is taken from Bridgy's unit tests.

<code><pre>
<article class="h-entry">
<a class="u-like-of" href="http://orig.domain/baz">liked this</a>
</article>
</pre></code>

In this case, http://orig.domain/baz is almost certainly not the u-url, so IMO it would be better to leave it out —[[User:Kylewm|Kylewm]] 15:10, 7 October 2014 (UTC)

'''2015-01-20 consensus'''
* Changed my mind. Simpler to do nothing. Example provided is artificially constructed, does not reflect likely real world confusion of if we make implied properties more complicated. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
* ++ Consensus on do nothing for this case. At [[2015-01-20]]

'''Proposed resolution:'''
* Changed again. Due to indiewebcamp.com/edit use-case, this now makes sense for all implied properties. That is:
** If an element has any explicit property class name(s) on it, then it must not be used to imply any properties. [[User:Tantek|Tantek]] 20:50, 27 May 2015 (UTC)
*** +1 this seems reasonable, if a publisher is going to add an mf2 class, it is unlikely they want other classes automatically implied from the same value [[User:Aaronpk|Aaronpk]] 23:19, 29 November 2015 (UTC)
*** -1 for now. To my knowledge, this has only been observed in artificially constructed unit tests and examples, and it adds some weird edge cases that are hard to reason about. [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** ... provide input on this proposal here
** Refined: Or should this be refined by per parsing prefix? [[User:Tantek|Tantek]] 22:59, 18 September 2015 (UTC)
*** Any explicit "p-*" property means no implied "p-name" from that element
*** Any explicit "u-*" property means no implied "u-url" nor "u-photo" from that element.
*** ... provide input on this refined proposal here
** Suggestion: split this issue up per property. I think it makes sense for u-url and can be easily added to the spec as e.g. ".h-x>a[href]:only-of-type:not[.h-*<strong>,.u-*</strong>]". [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** Obviously wrong to assume a link explicitly pointing elsewhere is our "url"
*** More difficult to make a case for photo and especially for name.
*** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
*** ... provide input on this refined proposal here
</div>

=== whitespace collapsing revisited ===
2015-05-27: (raised by [[User:Kevin Marks|Kevin Marks]] per Glenn Jones)

Revising the microformats tests to conform to the "don't collapse whitespace" rule below reveals some non-intuitive cases.
preserving whitespace in addresses is somewhat defensible, but in an implied name it is often unhelpful, as it preserves non-user visible space there for authoring reasons.

For example:
[https://github.com/microformats/tests/commit/a325e0e9bc2089507e69b1883f7065a3316e07c2#diff-d577012c1438978a571c4049179607f0 this test] shows how extraneous whitespace ends up in the <code>name</code>

<code><pre>
<div class="h-review-aggregate">
<div class="p-item h-event">
<h3 class="p-name">Fullfrontal</h3>
<p class="p-description">A one day JavaScript Conference held in Brighton</p>
<p><time class="dt-start" datetime="2012-11-09">9th November 2012</time></p>
</div>

<p class="p-rating">
<span class="p-average value">9.9</span> out of
<span class="p-best">10</span>
based on <span class="p-count">62</span> reviews
</p>
</div>
</pre></code>

give a parsed result of:

<code><pre>
{
"items": [{
"type": ["h-review-aggregate"],
"properties": {
"item": [{
"value": "Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012",
"type": ["h-event"],
"properties": {
"name": ["Fullfrontal"],
"description": ["A one day JavaScript Conference held in Brighton"],
"start": ["2012-11-09"]
}
}],
"rating": ["9.9"],
"average": ["9.9"],
"best": ["10"],
"count": ["62"],
"name": ["Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012\n\n\n9.9 out of \n 10 \n based on 62 reviews"]
}
}],
"rels": {}
}
</pre></code>

The <code>value</code> is a reasonable textual representation of the event, but the implied <code>name</code> is full of spurious whitespace that any consumer would have to strip.

[https://github.com/microformats/tests/commit/4c9690b53b0a2f40440abac8e609c51ac7dd6d56 h-review] has similar issues

2015-05-28: (Addition by [[User:GlennJones|Glenn Jones]])

The example below shows the type of markup most effected by the "implied name" and "don't collapse whitespace" rule working together to produce output that is hard to use without further processing.

<code><pre>
<a class="h-card" href="http://glennjones.net">
<span class="p-given-name">Glenn</span>
<span class="p-family-name">Jones</span>
</a>
</pre></code>

The output for the name property from the above HTML would be <code>Glenn\r\n Jones</code> using the (trim lead/trailing) suggested in the parsing spec. I could of course move the spans onto one line, but it feels fragile to consider whitespace sensitivity in HTML like this. Added to the fact that HTML templating environments often take away that level of whitespace control from authors anyway.

There are issues with both: keeping whitespace, returns and tabs from parsed HTML or collapse that whitespace. If we return the whitespace it becomes mal-formatted for humans because it was only added to make the HTML code understandable and in most cases was not meant to be used/read outside of that context. If we collapse the whitespace we can have issues of whitespace sensitive text from <code><pre></code> etc. being incorrectly formatted.

Providing a CSS aware innerText feature would produce the most useable output, but this is too complex/time consuming to build for most parser developers. In the face of no perfect solution I have taken the 80:20 view, whereby errant whitespace, causes me considerably more problems than mal-formatted <code><pre></code> content so I collapse whitespace on all text returned.

This feature is a non-CSS aware version of innerText. It does not cover all rendering edge cases, but enough to produce practical output.

For now, I have started changing the node parser to flag "white-space collapsing" as an experimental feature which is off by default i.e. http://glennjones.net/tools/microformats/ but personally I will parse everything with this on as I find it the most practical solution.

Not sure where that leaves me on the options below.

Options:

Choose from:
# keep as is and every parser client has to post process for common cases.
# '''keep as is but have mf2 parser trim leading/trailing whitespace (likely to provide desired result and be reasonably backcompat)'''
#* +1 my preference of the two options. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
#* +1 though this doesn't solve any of the problems discussed above, it's still worth doing [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
#* +1 will help parsers be more consistent with each other, and I haven't ever encountered a case where preserving leading/trailing whitespace was desirable [[User:Kylewm|Kylewm]] 20:45, 8 June 2015 (UTC)

2015-06-08 option 2 resolved by consensus and implementation in mf2py.

Somewhat orthogonal:
* make <code>value</code> on properties with children normalise whitespace
** -1 Seems like a bad idea as this "value" is supposed to be the same as if there was no embedded child microformat. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
* make implied <code>name</code> normalise whitespace.
** +0 This is reasonable and already done somewhat in the parsing spec (trim lead/trailing). [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** +1 Given the universality of name, this would fix most of the issues we see. [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
* Put \n in textual forms if there is a <code><p></code> tag in the original.
** -1 that's a long path to go down with whitespace equivalents for HTML markup. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** would only preserving whitespace if in <pre> be an 80:20 compromise? [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)

Because there are both code markup and specific vocabulary (label) needs for preserving whitespace, we are compelled to preserve in general, perhaps except for very specific limited generic cases (e.g. trim leading/trailing, "value" parsing, implied name). [[User:Tantek|Tantek]]

=== u- parsing iframe src ===
Currently if I put u-* on an iframe it gets the value of the fallback text. This seems a shame. Getting the URL seems a sensible answer.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== i- parsing iframe src ===

More controversially, what about using an iframe for transclusion? A use case here is comments on a static site. Currently, on eg http://www.kevinmarks.com/microformatschema.html the comments are injected via JS, making them opaque to parsers and thus precluding further parsing such as salmentions.

If instead they were an iframe embedding them, a parser could optionally fetch its contents, parse them, and include them in the parsed mf2 output at that point. Overloading u-* for this seems wrong; e-* as below for srcdoc would have a different effect; this implies a new prefix directive would be needed. A strawman i-* (for include) may work.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== e- parsing iframe srcdoc ===
<div class="discussion">
* Proposal: addition of a new e-* parsing rule for iframe elements with srcdoc attributes. E.G.

<source lang="html4strict">
<div class="h-entry">
<iframe class="e-content" srcdoc="<p>A paragraph of HTML with "quoted quotes" &amp; doubly quoted ampersands</p>" />
</div>
</source>
<source lang="javascript">
{
"items": [{
"type": ["h-entry"],
"properties": {
"content": ["<p>A paragraph of HTML with "quoted quotes" & doubly quoted ampersands</p>"]
}
}]
}
</source>

This would allow, for example, HTML comments to be sandboxed inside iframes but still parsable as microformats.

I believe the correct processing would be to leave " entities as they are but to unescape any doubly-escaped ampersands.

** Is there any use case for that? —[[User:TomMorris|Tom Morris]] 12:32, 14 September 2013 (UTC)
** +1 we need documentation of use case and existing sites publishing iframe srcdoc like this - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
** Rejected by consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 properties on select ===
How should select elements with properties be treated any differently?

Awaiting real world examples / stronger use-cases, until then no special treatment of select elements with properties:
<div class="discussion">
* Are there any real world examples of select elements with microformats properties?
* What would the use-case be for putting a microformats property class name on a select element?
* Nothing special. By consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 root name on form ===
See what to do about <em>root class names</em> on <code><form></code> elements in particular:
* [[hcard-input]]

Awaiting real world examples / stronger use-cases, until then, no special treatment of root class names on <code><form></code> elements:
<div class="discussion">
* Are there any real world examples of a <code><form></code> element with a microformats root class name?
* [[hcard-input]] is one possible use-case, is anyone attempting to use forms for hCard input, e.g. with scripts to help make it work?
* Are there other use-cases for putting a microformats root class name on a <code><form></code> element?
* As of [[2015-01-20]] - no consensus - need more input as to when/why this is useful to do anything special.
</div>

===Parsing Literal Values===
Issue raised by: [[User:BenWard|Ben Ward]]

It is proposed for microformats2 that all microformats be parsable from just their root element, e.g. <code><p class="h-card">Ben Ward</p></code> would create an hCard with the following properties after parsing:

<source lang=javascript>
{
'type': ['h-card'],
'properties': {
'name': ['Ben Ward']
}
}
</source>

This is a four-fold change from the current [[hCard]]:
# type is generically identifiable as a microformat root, even in parsed form. The use of the 'h-' prefix persists into the type of the object. This is deliberately so, as a result of re-using the JSON data model of microdata which itself is re-using a common JSON convention, such that microformatted data is clearly distinguishable (as opposed to any other random schema that may be using a similar data model).
# root-class-only support. Per [[microformats-2-implied-properties]], the ''name'' property is implied by the entirety of the root class name element.
# 'name' instead of 'fn'. As also documented in [[microformats-2-implied-properties]], the continuous challenges/problems and need to repeatedly re-explain 'fn' over the years combined with the real-world market response of nearly every other party doing a person vocabulary renaming 'fn' to 'name', microformats 2 makes this change as well.
# There is no automatic parse-time inferring of <code>'given-name': ['Ben']</code> and <code>'family-name': ['Ward']</code>. Any such inferring *might* be made by a vCard converter, but is left up to that specific application (not all applications) built on that vocabulary, though even in that case it may not be necessary, as an empty "N:;;;" [[vCard]] property is sufficient to satisfy the N property requirement of [[vCard]], and also causes no problems when imported into various [[vcard-implementations]].

It is required of the extractor to understand that when a microformats object specifies no explicit child properties, that it must treat <code>h-card</code> as having a <code>p-name</code>. But, the parser is generic, so it also treats <code>h-review</code>, <code>h-entry</code>, <code>h-recipe</code>, <code>h-geo</code> as having a ‘<code>p-name</code>’.

As a result, specific vocabularies are evolved to drop their specific form of name (e.g. fn, summary, entry-title) and simplified to use a common 'name' property instead.

Note: while the overwhelming majority of real world publishing/consuming uses of microformats do so with proper nouns which have names (and thus this parser-level incorporation of an implied 'name'), there are some formats that do not have a 'name' semantic. For example, [[geo]], [[adr]], and possibly if/when developed, units of measure, length, cost. The current thinking is that the benefits to the far greater proper-noun use-case of microformats outweigh the technical inelegance of having an extra/ignored 'name' property on formats that lack such a semantic.

Some formats also may appear in theory to better imply some other property, e.g. a review might be thought to imply its ''content'', not its name, and an Atom entry its ''content'', not its title, but in practice (actual publishing patterns) this is not the case. Typically, brief unstructured reviews (or mentions thereof) provide a ''summary'' (often hyperlinked to an expanded structured form) of that review, not its content, and similarly, brief unstructured posts (e.g. RSS items) have historically most often been link blog items which include the title of an item and a link. Short status updates as well established by Twitter are newer and would seem to imply purely content with no title, at least semantically, however, even Twitter populates the RSS title and ATOM entry title of their feeds with the content. It's not clear what went into that decision, however, that's likely irrelevant, as the outcome turns out to be emergent consistency among publishing behaviors.

To avoid overloading or undermining the semantics of a vocabulary, I propose that we handle this at the extractor level in a simpler fashion: Define a new property for literal data, that an extractor will provide if no other information was available. All ''interpreters'' may then be instructed that in the event that an object has no properties, it can attempt to interpret the literal value from the page instead.

* This was one of the design iterations I went through which led me to the current implied 'name' design. Another iteration was the ability for a vocabulary to specify a single required property which was implied if there were no properties provided. However, the combination of the fact that in most cases such single required properties were quite name-like, and that a vocabulary-specific rule like that would then bind parsers to specific vocabularies (even so slightly) led me to collapse them into implying a 'name'. It's not perfect, but it's the best alternative so far that balances practical convenience of publishing/consuming, avoids vocabulary-specific knowledge in the parser, and technical (in)elegance. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

In existing microformats, the closest existing example we have for this is the <code>label</code> property in hCard, which is used to represent the literal address label for a place. It is a corresponding piece of <code>fn</code>, <code>org</code> and <code>adr</code> in combination, but has no structure in and of itself. Possibly, every microformat could have a <code>label</code> form where structured data is unavailable.

However in practice, the hCard <code>label</code> property is both little understood and little used. It's not even clear that it ought to be kept for microformats 2 (no known consumers, very few (if any?) real-world non-test publishers). This disuse is likely a good indicator that we should avoid basing anything on its design.

Alternatively, <code>value</code> is used throughout microformats to target a generic value (e.g. in combination with <code>price</code> in hListing.) It has been proposed that when parsing properties that are also themselves microformats, we create native objects of the form:

{
'value': '1900 12th Street, San Francisco, CA 94'
, 'type': ['h-adr']
, 'properties': {
'street-address': '1900 12th Street'
, 'etc': 'etc'
}
}

We could apply this same pattern to the root level:

{
type: [h-card]
, properties: {}
, value: 'Ben Ward'
}

In this case, an interpreter or implementation is responsible for using <code>value</code> in place of <code>fn</code>, or restructuring the object. It would be the responsibility of each vocabulary to define its root property. The parsing layer of microformats 2.0 would not impose semantics or naming onto that.

For another example, h-geo would end up like this:

{
type: [h-geo]
, properties: {}
, value: '1.3232;-0.543'
}

* This is an alternative I've been considering as well: [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)
** 'value' is more generic than 'name' (applies to more vocabularies) with the trade-off that it naturally has less (weaker) semantics.
*** +1 I think that having naturally weaker semantics would be appropriate for this parsing functionality. —[[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC)
** The interesting thing that this analysis has revealed is that there appear to be two distinct clusters of microformats, the much more commonly used/understood/useful proper-noun microformats which markup things with names (people, events, reviews, recipes), and the less used compound-data microformats which are often used ''inside'' other microformats and just have some sort of semi-structured value (adr, geo, measure, and perhaps even things like tel). Perhaps this is implying the possibility and some degree of utility for ''two'' microformats root class name prefixes, 'h-' for existing proper-noun microformats, and something else ('m-' for microformat/molecule?, 's-' for structured-value?, 'v-' for value (though historically "v-"/"v." has meant "vendor-specific")?) for unnamed structured data microformats.
*** This more and more feels like a good idea, and I'm leaning toward "s-" for struct / structure / structured value. "s-" works just like "h-" except that it doesn't imply any properties at parse time. We can try it and see what happens. There's also no harm if publishers just use "h-" structures, they just (possibly) get a few extra properties if they happen to omit properties.
** Parallels the same JSON when a property has both a string value ''and'' is a structure itself.
*** Changed my mind on this. The parallel is not quite there. 'name'/'url'/'photo' are only implied if there are NO properties, where as the JSON string value + structure convention *always* provides a 'value'. [[User:Tantek|Tantek]] 22:39, 4 October 2011 (UTC)
*** And due to this difference in behavior ('value' is there when nested properties are present, whereas 'name' is only implied when there are no properties specified), I think it's correct to keep them separate, i.e. stick with implied 'name'. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
** However, I'm still currently leaning towards the practical convenience of providing a 'name' for the vast majority of microformats uses, rather than diluting this feature for the sake of avoiding implying inapplicable semantics to the few plain structured data microformats, and even then, only when no properties are explicitly specified! I'd rather introduce a new root prefix for those than lose the simplicity and utility of implied 'name'. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

== resolved ==
=== When to collapse whitespace in properties ===

The spec doesn’t explicitly require whitespace to be collapsed or not. The official mf2 test suite requires it to be collapsed.

Reasons why whitespace ''shouldn’t'' be collapsed:
* Plaintext property representations of syntax-highlighted code, poetry and song lyrics require whitespace to be present
* Whether or not whitespace is an important part of the content being parsed is determined by css white-space and CANNOT be inferred from HTML markup alone

Resolution 2013-11-12: Agreed, whitespace should not be collapsed (other than normal HTML5 parsing rules). The spec now refers to "textContent" rather than "innertext" to make this explicit.

=== How to interpret mf2 classnames on form inputs ===
E.G. how to parse:

<source lang=html4strict>
<input class="u-url" value="https://brennannovak.com/notes/338" />
</source>

Examples in the wild: https://brennannovak.com/notes/338

See proposal:
* [[hcard-parsing-brainstorming#input_element_handling]]

Resolution 2013-11-12: Per that proposal, p- u- dt- properties on input[value] elements now use the value attribute.

=== mixture of microformats2 and classic microformats classnames on different elements ===
Some sites in the wild have mistakenly combined classic mf and mf2 markup in ways which misrepresent the content if parsed in BC mode.

Typically this is caused by putting classic and mf2 classnames for the same vocabulary on different elements, e.g:

<source lang="html4strict">
<body class="hentry">
<article class="h-entry">
<h1 class="p-name"></h1>
</article>
</body>
</source>

Sites where this has been observed:
* http://acegiak.machinespirit.net/2013/10/17/barnaby-walters-notes-another-thing-i-love-about-the-web-users-have-the-power-to-take-control-of-their-uis-and-improve-their-own-experiences-aside-drm-for-html-would-prevent-this-from-being-possibl/
* http://shawfactor.com/2013/08/06/thoughts-on-extending-webmentions/ (fixed)
* http://notizblog.org/2013/06/18/the-rise-of-the-indieweb/ (fixed)

Discussion:

* As far as I can tell, the problems in all of these examples were caused by mf2 markup being injected by a wordpress plugin, but classic mf classnames being present further up the DOM in the themes. When parsed in compatibility mode, the classic mf classnames are transformed into mf2 classnames, making the original mf2 classnames look like children of empty items.
* Turns out this isn’t theme-specific, WordPress injects hentry via PHP [http://indiewebcamp.com/irc/2013-10-22/line/1382448759]. The bug with the wordpress mf2 plugin is resolved as of [http://indiewebcamp.com/irc/2013-10-22/line/1382449035 2013-10-22] --[[User:Barnabywalters|bw]] 13:38, 22 October 2013 (UTC)

=== e- and p- escaping levels ===
<div class="discussion">
* The fact that the parsed value of any element with .e-* is at a different level of escaping to the parsed values of p-*, dt-* etc. without any indication of how the property was parsed in the output is a security problem. For example:

<table style="width: 100%">
<tr>
<th>input</th>
<th>output</th>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="p-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="e-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
</table>

* As a parser developer, the most straightforward way I can think of solving this is to add an option (enabled by default) which encodes HTML special characters on all non e-* properties, so the developer knows that all property values are going to be at the same level of escaping. --[[User:Barnabywalters|bw]] 20:00, 15 June 2013 (UTC)
** Your suggestion of auto-HTML-encoding p-*/u-*/dt-* property values is the most sensible I think. I would NOT make it an option, as it makes sense write consistent microformats2 consumers. - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
** Can you think of any existing apps/consumers of microformats2 via the parser that would break? What would indieweb comments parsers do? - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
*** The only breakage which might occur would be over-encoding of non e-* properties, but I’ll release this update as v0.2.0 and warn people about the changes. The worst thing which could happen is that some comments look a bit weird, as opposed to the current worst possible scenario of easy XSS attacks --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** We should also decide exactly which characters get encoded — just angle brackets, or quotes/ampersands as well? --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** I am not sure about this, it seems more like a helper function rather than a core feature of the parser. Personally I would like to store data as text and encode only when I am going to use and I known the format it is going to be use in. --[[User:GlennJones|Glenn Jones]] 9:54, 14 July 2013 (UTC)
***After the discussion on the indiewebcamp IRC with Barnaby Walters I now understand the XSS issue that this change is trying to address. A rogue author could include HTML with scripts to execute a XSS attack. These could be masked by switch prefixes i.e. p-* to e-* on a well use property. As the consumer does not see the prefix in the JSON output they have no idea if a property will content HTML or text. I will update my two parsers and the test suite --[[User:GlennJones|Glenn Jones]] 8:02, 17 July 2013 (UTC)
**So what about an author setting a property to e-* when it would normal be p-*, dt-* or u-* i.e.
<source lang=html4strict>
<div class="h-card"><p class="e-name"><script> alert('xss test') </script></p></div>
</source>
** per [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]], parsers should never automatically attempt to HTML-special-characters encode - as that would provide the client of the parser a false sense of security. It's *always* up to client code to escape any text being output to HTML *at the moment it is output to HTML* and never before, because they can never trust that any text from storage/elsewhere has for sure been escaped or not. - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** Should we not encode e-* as well and the consumer can decode at their own risk --[[User:GlennJones|Glenn Jones]] 18:42, 21 July 2013 (UTC)
*** No, never, per above point from [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** See [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] etherpad: https://etherpad.mozilla.org/microformats2parsing for more details on the resolution to this issue - and incorporate here (then move to resolved section below). - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
* Resolved by changes to the parsing spec: all properties are plaintext (non-HTML escaped), e-* properties result in a dictionary with <code>value</code> = plaintext version, <code>html</code> = raw HTML version
----

</div>

=== br hr empty string ===
<div class="discussion">
* The parsing rule 'else if br.p-x or hr.p-x, then return "" (empty string)' for p-* can cause any code consuming the API to become quite bloated. It means that you have test every array value to see if its an empty string. It is also unclear to me what the purpose of this mark-up pattern is for [[User:GlennJones|Glenn Jones]]
** Upon reconsidering this, I agree with you, this is an unlikely use case. If a publisher wants to explicitly set an empty property "p-foo" they can simply write <code><span class="p-foo"></span></code> which looks explicit. Whereas BR and HR tags are often just presentational, so we should both not encourage usage of them for semantics, and anyone that did use them would be subject to likely loss of semantics upon a redesign (that got rid of those particular BR and HR tags). I'm going to remove them from the parsing spec. - [[User:Tantek|Tantek]] 15:29, 10 February 2013 (UTC)
</div>

=== datetime examples without T delimiter ===
<div class="discussion">
* The examples in the wiki microformats-2 pages such h-entry and h-entry had datetime without the 'T' delimiter between date and time. ie
<source lang="html4strict">
<time class="dt-published" datetime="2013-06-13 12:00:00">13<sup>th</sup> June 2013</time>
</source>
I have updated the pages. As far as I known this is a new pattern for dates. Was it a mistake in the examples or is it a new datetime pattern.
** The [[HTML5]] "time" element, and "datetime" attribute allow for space <span style="white-space:nowrap">" "</span> as a separator between date and time as well as "T", thus we allow it for microformats as well. The <span style="white-space:nowrap">" "</span> separator is preferred as the date and time are more readable when separated by a space. The examples noted in those specs deliberately use this. - [[User:Tantek|Tantek]] 18:48, 15 July 2013 (UTC)
</div>

=== rel-alternate absent optional attributes ===
<div class="discussion">
* What should rel-alternate parsing do when one of the optional attributes specified (<kbd>hreflang</kbd> or <kbd>media</kbd> or both) is not there? The options seem to be:
*# leave the corresponding key out of the alternate JSON object
*#* This one. Leave the corresponding key out.
*# include the corresponding key in the alternate JSON object, but set the value to the JSON null object
*# include the corresponding key in the alternate JSON object, but set the value to a blank string
*# something I haven't thought of

I haven't checked the existing implementations, but Barnaby said he's not sure what the appropriate way to deal with it is either. —[[User:TomMorris|Tom Morris]] 15:41, 9 August 2013 (UTC)
</div>

=== rel-alternate and type attribute ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Should rel-alternate parsing also pick up the <code>type</code> attribute? It’s fairly widely used, e.g. for ATOM feeds.
** Numerous existing sites/pages have various [[rel-alternate]] uses with a type attribute for feeds/APIs so that's good enough to add this for help with discovery in general. Rel parsing updated. - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
</div>

=== Extraction vs Interpretation ===
Issue raised by: [[User:BenWard|Ben Ward]]

A microformats ‘1.0’ parser performs the following function:

* Given a piece of HTML content, discover a known microformat, extract it, apply various extraction patterns based upon the HTML mark-up used (e.g. include pattern, <code>abbr</code> patterns, date-time patterns, value-title pattern), apply various content optimisations where applicable, and return the result in an object native to the programming language.

This is performing two types of function: Extraction of data from an HTML document or fragment, ''and'' interpretation and optimisation of that content to match the rules set out by a vocabulary specification.

It is only possible to write a generic parser that covers the first half of this task: Extraction, and application of global rules based on HTML elements and patterns common to all formats.

The purpose of a generic parser (as supported by use cases such as search engines, and other crawlers) is:

To provide a way for tools to extract rich data from a page for native storage, such that the data may be interpreted later by applications. This allows microformats to be crawled, and indexed, and removes the need to include complex HTML parsing within every implementation of microformat data.

Microformats will continue to define various vocabulary-specific optimisations. as part of the design to be optimised for authors. For example: The <code>fn</code> pattern in [[hcard]], or the <code>lat;long</code> pattern in [[geo]], as well as default values for properties, such as the maximum rating in an [[hreview]].
* Actually, no, as it is defined currently, microformats 2 ''drops'' vocabulary-specific optimizations. Such optimizations have often been too inapplicable, error prone or i18n-unsafe (e.g. fn to given-name + family-name fails for both numerous cases where middlenames/initials are used, and in general in numerous Asian languages where given/family name order is the reverse of Western English conventions, or languages with multiple family-names, e.g. Spanish - see [[hcard-issues-resolved]] for more). This is a deliberate cutting of a "feature" from microformats 1, it is a deliberate model simplification design decision. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

==== Extraction resolution ====
Proposed resolution:

Microformats2 should refer only to ''extraction'' of microformats. Vocabularies should in turn document their appropriate optimisations, which will need to be applied by implementations, or a companion to an extractor, which I'll refer to here as an ‘interpreter’.
* Vocabularies will no longer have optimizations, this is again deliberately, as they've been shown to be more error prone than helpful. Thus there should be no need for any vocabulary-specific 'interpreters'. However, due to design quirks in various legacy/interchange formats, ''export conversions algorithms'' to those legacy/interchange formats will require some additional legacy-format-specific rules (e.g. odd "required" rules in [[Atom]] or [[vCard]] will require specific synthesis rules, limitations in said formats will require filtering of some values, e.g. [[vcard3]] BDAY disallows vague birthdays like year-month and --month-day - subsequently allowed in [[vcard4]]). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

A microformats2 ‘extractor’, in combination with the functionality of a domain and format-aware ‘interpreter’ (either another shared component, or part of the implementation itself) would be equivalent to a microformats 1.0 ‘parser.’
* A microformats2 parser is both generic (no knowledge of specific vocabularies), and lacks any/all such vocabulary-specific rules as compared to a microformats 1.0 [[hcard-parsing|parser]] with the exception of a 1) a limited list of well-established/interoperable backward compat root class names (of current [[microformats]] that are or can be soon shown to be specifications/standards per the [[process]]), 2) flat sets of backward compat property names (some with prefix/name specific conversion) for each of those backward compat root class names. This is a deliberate design decision that makes microformats 2 more "micro", and yes this means that even with such backward compat support, this simple form of backward compat may mean that some existing microformats 1 content breaks. We'll assess those and iterate on a documented case-by-case basis rather than attempt to maintain theoretical 100% backward compatibility (since many current microformats format-specific-features are either unused, or may have caused more problems than solutions). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

N.B. I'll rewrite some of these as [[microformats2-parsing-faq]] to help better clarify. The reasoning that led to most of these design decisions is documented in the [[microformats-2#About_This_Brainstorm|microformats 2: About This Brainstorm]] section and following sections. I'll recheck those sections to see if/where reasoning for some of the above noted design decisions may have been missed, and back-fill accordingly. This is necessary because [[microformats2]] is a evolutionary result of simultaneously addressing both numerous generic [[issues]] as well as various common [[hcard-issues-resolved|format]]-[[hcalendar-issues-resolved|specific]] [[mfo|problems]] in microformats1 syntax and vocabularies. The very number of changes may make it more challenging (from a microformats1 perspective) to see why any particular design change has been made. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

This issue can be moved from resolved to closed once the above-mentioned write-ups have occurred.

===Parsing properties from rel attributes===
tl;dr resolution: As of 2013, [[microformats2-parsing]] handles parsing all link and a href rel values at document scope level, and producing canonical JSON accordingly. - [[User:Tantek|Tantek]]

Issue raised by [[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC):

* Currently, hAtom parses `bookmark` as a permalink
* Various microformats parse `rel=tag` as tags
* The current proposal for parsing does not allow parsing properties from rel attributes.

Microformats parsers could instead extract ''all'' link relationships from rel attributes within an microformat object, parsing them as if a u- prefixed property.
* Minor nit: Rather than same as a u- prefixed property, I think such "rel" properties should be parsed purely from the <code>href</code> attribute on <code><a></code> and <code><area></code> elements and nothing more. I would strongly disagree to extending rel to apply to other elements with URLs like img src, object data, or to apply to elements in general like div. That's the path that RDFa has taken and caused much confusion as a result. [[User:Tantek|Tantek]] 07:39, 5 October 2011 (UTC)
** Agree: That seems like a perfectly reasonable restriction. --[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)

This results in:

* Continuing use of the <code>rel</code> attribute in HTML, thereby building on HTML semantics rather than bypassing them or ignoring them in favour of something less meaningful.
* Parsing hAtom objects contain a property named <code>bookmark</code>, in place of <code>permalink</code>.
* All microformats that use <code>rel-tag</code> would contain a property named… <code>tag</code>. Perfect.

Since <code>rel</code> attributes are not overloaded for other functionality like class is, and other uses of <code>rel</code> within content are low (and non-semantic uses are nil, to the best of my knowledge) the risk of property pollution would be extremely low.

Note, with regard to this last point, that a generic microformats parser ''will'' parse false-positive properties, and ''will'' parse objects in combined chunks, rather than individually by format. Extracted objects will often not represent a vocabulary without further processing.

<div class="discussion">
* This sounds like it might be workable. Let's try it and see how well authors "get it". - [[User:Tantek|Tantek]]
* Possible issue: do we have any collisions between class property names and rel names? (I don't think so offhand, but useful to ask the question). - [[User:Tantek|Tantek]]
** None that I can think of in microformats. There is the case of Google's <code>rel=author</code> and <code>p-author</code> in hAtom. However, the next point, about mfo scoping, would cover it in most situations (rel-author on a hyperlink within an hcard wouldn't be applied to the hentry.) The one situation in a parse tree where it's ambiguous would be this:
<source lang=html4strict>
<a href="p-author h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
** I can think of two quite reasonable solutions:
*** 1. Declare that class properties take precedence over rel properties of the same name, discarding rel values if a class is also found, or
*** 2. Since all properties are now multi-value anyway, the hAtom object could be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
** —[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)
*** Option 2 makes sense and is consistent with the rest of the multi-value parsing/handling. - [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
*** What about without the 'p-author'?
<source lang=html4strict>
<a href="h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
Should that be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
Or
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': 'http://benward.me' /* from the rel="author" */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},

],
…
}
}
</source>
*** And if the former, then we're presumably saying that the value parsed due to the presence of a rel is always its own value, and does not combine with any other structures. I am fine with this, but I wanted to make sure we are ok with that explicitly. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
**** +1 I think that since the rel attribute is specifically concerned with the relation to an href attribute, it should not be combined with other structures that are rightly declared uses classes.
***** The more I've thought about this and how consuming applications may want to treat rel semantics, the more it seems correct to keep rel semantics distinct from class semantics. Class semantics are quite general/flexible, whereas rel is quite specific, naming something else in terms of a relationship from the current page/microformat's perspective. I think we should consider putting rel values in their own 'rel' collection, separate from the 'properties' collection. E.g. the original rel-author p-author h-card markup example would be parsed into this:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
}
],
…
}
'rel': {
'author': ['http://benward.me'] /* from the rel="author" */
}
}
</source>
***** and if a post had multiple authors:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from p-author */
'type': ['h-card'], /* from h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
{
'value': ['Tantek Çelik'], /* from 2nd p-author */
'type': ['h-card'], /* from 2nd h-card ... */
'properties': {
'name': ['Tantek Çelik'],
'url': ['http://tantek.com']
},
],
…
}
'rel': {
'author': [
'http://benward.me', /* from rel="author" */
'http://tantek.com' /* from 2nd rel="author" */
]
}
}
</source>
***** This preserves the semantic distinction between rel and properties in general, and leaves it up to a higher-level application to implement any logic around showing "more info" about a rel-author, e.g. by correlating the rel-author URL with the 'url' of an hCard it found in the same entry. However, note that even in the earlier JSON data model, the rel-author value just shows up as another property value, and any higher level application would still have to do some correlation logic. At least with this JSON data model, applications that may be looking for a rel value in particular, or a property value in particular can do so without having one unintentionally pollute the other. [[User:Tantek|Tantek]] 17:33, 6 October 2011 (UTC)

* Presumably we'd apply all the same property scoping rules to rel scoping as well. E.g. a rel hyperlink inside a microformat won't be seen by any containing microformat. - [[User:Tantek|Tantek]]
** Correct, it should be parsed in the same scope as all other class properties in the object.
*** Update: all rel microformats are now parsed at page-scope. Per-microformat scoping of rel has been found to be too confusing in practice (and against the general semantic of rel expressed in the HTML/HTML5 specs) [[User:Tantek|Tantek]] 01:00, 10 July 2014 (UTC)

This issue can be moved from resolved to closed once we've verified that all the above-mentioned and implied needs to write things up have occurred.
</div>

=== deduping of rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-02 by [[User:Kevin Marks|Kevin Marks]]
* 2015-06-05 resolved by consensus and one real world implementation proof of implementability and verification of expected results. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

Many sites have multiple duplicate rel links to the same url - a very common case is WordPress home pages eg [http://ma.tt ma.tt]

Each post on the page has a block like
<code><pre>
<div class="entry-meta">
<span class="date">
<a href="http://ma.tt/2015/05/beethoven-mozart-bach/"
title="Permalink to Beethoven, Mozart, Bach" rel="bookmark">
<time class="entry-date" datetime="2015-05-31T22:42:00+00:00">May 31, 2015</time></a></span>
<span class="categories-links">
<a href="http://ma.tt/category/asides/" rel="category tag">Asides</a></span>
<span class="author vcard">
<a class="url fn n" href="http://ma.tt/author/saxmatt/"
title="View all posts by Matt" rel="author">Matt</a></span>
</div></pre></code>

As currently defined, the parser will create duplicate entries in <code>rels</code> for each post:
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/",
"https://ma.tt/"
],
}
</pre></code>

and in the <code>rel-urls</code> we will also see:
<code><pre>
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author",
"author",
"author",
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home",
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag",
"category",
"tag",
"category",
"tag",
"category",
"tag"
],
"text": "Asides"
}
</pre></code>
These duplicates are unhelpful for parser consumers. We should:
* make them both sets - only listing distinct values. This will remove ordering information, but order is irrelevant for rel in html.
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/"
],
}
…
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag"
],
"text": "Asides"
}
</pre></code>

* possibly we could also make <code>title</code> <code>text</code> <code>type</code> sets too. That would solve the information loss issue with the current parsers
** Resolution: in the case of duplicate other attributes, first one set wins. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

<div class="discussion">
* +1 as the proposer. A version of mf2py that does this is running at unmung,com. see [http://www.unmung.com/mf2?url=https%3A%2F%2Fma.tt&html=&pretty=on fro ma.tt] or [http://www.unmung.com/?html=%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E&pretty=on a simple test] [[User:Kevin Marks|Kevin Marks]] 23:49, 2 June 2015 (UTC)
* +1 makes sense to me, and not having them be sets in the current spec is likely an oversight on my part. Thanks for noting this issue. [[User:Tantek|Tantek]] 05:28, 3 June 2015 (UTC)
</div>

=== include alternates in rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 resolved per consensus and one real world implementation proof of implementability. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* add "alternate" rels to the "rels" collection to make them easier to look-up in "rel-urls" - that is, all rel values end up in "rels" collections. No exceptions.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls".
* +1 This makes sense to me, as the <code>rels</code> and <code>rel-urls</code> should match so you can lookup in rels first, then get details about urls from rel-urls. We can drop "alternates" independently from this change. [[User:Kevin Marks|Kevin Marks]] 00:23, 2 June 2015 (UTC)
** +1 drop "alternates" independently now made a separate issue. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
* +1 Makes sense. And I agree with Kevin; I think parsers should deprecate "alternates" for now and drop it after a version cycle or two. [[User:Kylewm|Kylewm]] 00:30, 2 June 2015 (UTC)
* implemented in [https://github.com/kevinmarks/mf2py/commit/4dba45200eef11da811f64817d02044ab9e98b77 my fork of mf2py] and running on [http://www.unmung.com/?html=%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fa%22%3Eauthor+a%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fb%22%3Eauthor+b%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F1%22%3Epost+1%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F2%22%3Epost+2%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22alternate+home%22%0D%0A+++href%3D%22http%3A%2F%2Fexample.com%2Ffr%22%0D%0A+++media%3D%22handheld%22%0D%0A+++hreflang%3D%22fr%22%3EFrench+mobile+homepage%3C%2Fa%3E&pretty=on unmung] [[User:Kevin Marks|Kevin Marks]] 01:29, 2 June 2015 (UTC)
</div>

=== Empty properties overridden by implied rules against user expectation ===
Status: resolved, existing behavior correct, no changes to parsing spec.

2015-07-03: raised by [[User:Glenn Jones|Glenn Jones]]

Emma Kuo brought up an issue (https://github.com/glennjones/microformat-node/issues/22) based on following the indieweb note pattern, where the content of a note is given both the e-content and p-name classes. If the element containing the notes only has none text content like image the p-name can have unexpected value. Here is the example she gave:

<code><pre>
<div class="h-entry">
<a href="http://this.site/photo" class="u-url"></a>
<div class="e-content p-name"><img src="photo.jpg" class="u-photo"/></div>
Some extraneous text
<div class="h-cite">
<a href="http://someother.site/like" class="u-url"></a>
<a href="http://this.site/photo" class="u-like-of"></a>
<div class="e-content p-name">liked this</div>
</div>
</div>
</pre></code>

At the moment I parser this as follows: - if a property (p-name) is empty do not add it to the output. In this case "empty" is classed as not containing any non-whitespace text. As far as I known there is no guidance on how to handle "empty" properties in microformats paring rules, so I followed the conventions of JSON API's not to return "empty" properties.

The side effect of the above is that p-name also has a number of "implied rules". The "implied rules" try to automatically fill properties like p-name if there is no defined value. In the example above it uses the textContent of the parent h-entry, so value of the h-entry>p-name is the text content of the h-cite i.e. "likes this".

Options:

1. We should not allow the "implied name rule" to get textContent from within a child h-*
<div class="discussion">
* <strike>+1 I believe this is inline with how we parse properties and will meet user/author expectations [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* -1 A nested h-* is still part of the content of the parent h-*, I don't quite understand the rationale for excluding it. For example, I may include lots of h-cards in the body of a post that references people and wouldn't want them to be excluded from the implied name generation. [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* -1 I'm not sure this would solve the problem because auto-filled text could come from the parent h-* ("some extraneous text" in the example above) [[User:emmak|Emma Kuo]] 20:50, 4 July 2015 (UTC)
* -1 I agree with the other -1s. This would break some of the simplicity of the model. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
</div>
2. We should not execute the "implied rules" where there is an author defined "empty" property.
<div class="discussion">
* <strike>-1 Although the output would meet author expectations it is complex for parsers as they will have to keep state for each property through the whole series of parsing rules. [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* +1 An explicit, empty, p-name property should prevent an implicit p-name from being generated. For example tantek.com includes <span class="p-name"></span> at the start of the h-feed to prevent a giant name from being auto-generated. From my reading of the parsing spec, I don't see any reason that blank strings should be excluded from parsing. (mf2py and php-mf2 will both happily include empty strings in their output) [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* +1 We already have interop on this between mf2py and phpmf2, as well as people depending on it to explicitly set empty property values. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
* +1 As we already have interop with two parsers and solid user issue from Emma we should take this approach. [[User:GlennJones|Glenn Jones]] 11:51, 29 July 2015 (UTC)</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== uf2 children inside a classic microformats root class name ===
Status: incorporated into [[microformats2-parsing]]

2015-020: (raised by kylewm) What should microformats2 children inside a classic microformats root class name do?

Options:

1. Nothing. Any unattached uf2 children inside a classic microformats root are ignored. Problems:
<div class="discussion">
* However then there's a possible surprise if/when the author upgrades the classic microformats root to uf2, then all of a sudden all the new uf2 children show-up.
* Another downside: author adds uf2 markup, can't figure out why nothing is happening (because somewhere up the tree in code they didn't touch is classic microformats that are hiding these unattached uf2 children.
</div>
2. Show up in the children collection of the classic microformats root
<div class="discussion">
* Feels most predictable. When you add uf2 root class names anywhere, they will show up in the JSON output hierarchy.
* When you convert ancestor class microformats root class names to uf2 root class names, no surprise in terms of which microformats show up. Same children collection.
* +1 Thus I'm leaning towards this one, despite the fact that classic microformats never had a concept of generic unattached children. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)
* +1 I think this is the best option I will implement it and update the wiki once its in the JavaScript parser. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>
3. Show up as peers to the classic microformats root. Issue(s)
<div class="discussion">
* Has ths surprise aspect of if/when you convert the classic root class name to a uf2 root class name, the former peers become unattached children.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== any h- root class name overrides and stops backcompat root ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: The presence of any h-* root class name overrides and stop any backcompat parsing of classic microformats root class names on that same element. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for restricting backcompat root class name to only seeing backcompat property class names
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
* I don't think I understand this rule. If I was stop all parsing of of classic microformats in the presence of any h-* root in a document then some of the other rules such as "uf2 children inside a classic microformats root class name" do not make sense. Could this item be expanded and explained a bit more? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** added "on that same element" as that was what we were discussing/implying in this issue. [[User:Tantek|Tantek]] 22:49, 18 September 2015 (UTC)
</div>

=== backcompat classic microformats should only see backcompat properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats vocabulary that indicates a backcompat root class name (and thus an absence of the microformats2 equivalent on the same element), parsers must only look for the backcompat properties that are specified explicitly for that backcompat root class.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such behaviour was never expected by authors, and crossing a classic microformats root class name with microformats2 property names were never explicitly expected nor specified to work.

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== microformats2 root class names should only see microformats2 properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats2 root class name, only explicit microformats2 properties should be parsed. Any backcompat property names must be ignored.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such microformats2 authors should be expected to do all their microformats markup with microformats2 class names - this is a deliberate expectation so that their microformats aren't polluted with other (classic microformats) coincidentally named generic class names.

Thoughts?
<div class="discussion">
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== implied properties on backcompat parsing unlikely to be intended ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
Since classic microformats had no notion of implied properties, when implied property parsing occurs on backward compat classic microformats root class names, it is unlikely that any implied property (p-name u-url u-photo) was ever intended by the author of the classic microformat. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
Examples:
* see https://indiewebcamp.com/h-entry#bad_hentry_properties for a growing list

'''Proposed resolution:'''

* Be explicit in implied property parsing that it must only be done for explicit 'h-*' root class name microformats, not for any (back)compat parsing of microformats. Please comment on this proposal with "** comment" on new lines below. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
** +1 This makes a lot of sense to me. We should strive to parse mf1 as it was intended by the author, and I think you're right that implied rules are unlikely to be what was intended [[User:Kylewm|Kylewm]] 03:22, 30 December 2014 (UTC)
** +1 I think this will help backcompat parsing, but there are two major things to consider. It may well break some consumer code as the output for a microformats currently always has the name property, there may not be the defences code to check this is true when we remove the implied name rule for classic microformats. The test suite will also need major updating as all the test output for classic microformats will have. I will look into implementing this and report back to the wiki. [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** Also it should be made clear that we are only removing the implied rules from classic microformats parsing and not the value property? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
*** The "parsing for implied properties" section only references name, photo, url properties. Where (in the spec) is the confusion about "value" coming from? [[User:Tantek|Tantek]]
** RESOLVED at [[2015-01-20]] meetup. [[User:Tantek|Tantek]] 04:09, 21 January 2015 (UTC)
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Set implied properties by microformat version"

=== link elements and u- parsing ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Raised by tantek on 2014-07-08 on [http://logs.glob.uno/?c=freenode%23microformats&s=8+Jul+2014&e=9+Jul+2014#c72916 irc]: should the parsing specification for handling u- properties be modified to include the <code>link</code> element? The potential downside is that [[invisible-metadata-is-considered-harmful]], however all known real world examples of <code>link</code> are <em>semi-</em>visible data (not fully hidden).

There are potential cases for wanting to use link as an alternative to <code>a</code> (and <code>area</code>), such as a whole page where the root <code>html</code> element is an <code>h-card</code> and the properties are included across the page: some in visible data in the <code>body</code> while others are in the <code>head</code> as <code>link</code> elements. Example:

One specific use-case is the semi-visible <code>link rel="shortcut icon" href="..."</code> - which is visible sometimes in browser UI, and also when a user chooses "Add to Home Screen" on a mobile device. Such page level icons may be used as a <code>u-photo</code> or <code>u-logo</code> of the containing <code>h-*</code> object on the <code>html</code> element.
* http://adactio.com/about/myself/ on 2014-190
** <em>could</em> use <code><html class=h-card></code> - page is all about Jeremy Keith the person
** <em>icon / logo is only</em> on <code><link></code> tag which <em>could</em> use <code>class=u-logo</code>: <br/><code><link rel="shortcut icon apple-touch-icon" type="image/png" href="/icon.png" /></code>

Another specific use-case is a post permalink page, e.g. with <code><html class=h-entry></code>
* http://waterpigs.co.uk/notes/4WjHpC/
** <em>has</em> <code><html class="no-js h-entry hentry h-as-note" lang="en"></code>

Another use-case is publishing links to PGP/GPG keys linked from the head which is currently handled by <code><link rel=pgpkey></code> which is already supported in existing [[microformats2-parsing#parse_a_hyperlink_element_for_rel_microformats|microformats2 rel parsing]] of <code>link rel</code> elements. Thus there is a (admittedly weak) argument for consistently parsing <em>both</em> <code><link rel></code> <em>and</em> <code><link class="u-*"></code>.

E.g. inside that aforementioned real world <code><html class=h-entry></code> post permalink page example,
* why should <code><link rel="in-reply-to"></code> work
* but not <code><link class="u-in-reply-to"></code> ?
The slightly stronger argument for consistency of link handling is that it <strong>[[simpler|simplifies]]</strong> the publisher (and parser) model:
* <code><a></code> and <code><area></code> work for both <code>rel</code> and <code>class</code>
* why does <code><link></code> only work for <code>rel</code> ?
* it would be <em>simpler</em> if all three tags just worked (in the same way) for both <code>rel</code> and <code>class</code>

'''Should the parsing spec be modified to handle these cases?''' —[[User:TomMorris|Tom Morris]] 09:25, 9 July 2014 (UTC)

** I'm generally in favour. It'd be good to see what other parser developers think. —[[User:TomMorris|Tom Morris]] 10:16, 9 July 2014 (UTC)
** adding this to the parsers won't be an issue. <del datetime="2014-07-09T18:45">The question is should the door be opened to hidden mf data?</del> <ins datetime="2014-07-09T18:45">Up on further reflection, there seems to be no need to distinguish between <code>rel=property</code> and <code>class=u-property</code> on link elements. So I am in favour for consistency.</ins> [[User:KP|Kartik]] 18:30, 2014-07-09 (EST)
** RESOLVED at [[2015-01-20]] meetup. Make link consistent with a.
</div>

=== drop alternates collection ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 split into separate issue from include alternates in rels per implementation feedback from Kevin Marks. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* drop "alternates" as its no longer needed, and all current consuming code clients like rel-urls better anyway.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls" in original issue now "include alternates in rels", we no longer need "alternates", and those with client consuming code have universally indicated that they would rather use rel-urls anyway. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
</div>

== see also ==
* [[microformats2-parsing]]
* [[microformats2]]

microformats2-parsing-issues

2016-03-13T20:39:50Z

Barnabywalters: /* exclude style elements before parsing */

This page is for documenting issues with the [[microformats2-parsing]] specification.

== issues ==
Open issues in various states of partial resolution from none to nearly resolved.

=== ignore u-camelCase properties ===
Due to Suit CSS (and others? citations?) recent (2015-?) use of "u-*" class names for so-called "[http://davidtheclark.com/on-utility-classes/ utility classes]", we are seeing some false positives in a few very rare instances, e.g.: http://www.unmung.com/mf2?url=http%3A%2F%2Fwww.kevinmarks.com%2Ftwitterutils.html&html=&pretty=on

(Nearly) all these "utility classes" use camelCase for the class name suffixes, thus we can filter them out by looking for camelCase (since microformats class name conventions are always all lowercase and hyphenated), or even just looking for (and rejecting) *any* capital letters.

Proposal:
* microformats2 parsers MUST IGNORE u-* classnames where the * has any uppercase letter(s).

<div class="discussion">
* +1 [[User:Tantek|Tantek]] Let's get this fix rolling quickly to avoid further pollution.
* ...
</div>

=== exclude style elements before parsing ===
[http://logs.glob.uno/?c=freenode%23microformats#c85457 2016-01-25 raised in #microformats]

Ran into an issue of a <style> element being parsed as plain text in a p-name. Should [[microformats2-parsing]] be updated to indicate <style> should be excluded when parsing? Appears to implicitly fall under [[microformats2-parsing#note_HTML_parsing_rules]]

Sample link: http://veganstraightedge.com/notes/2016/01/16/tonight-s-dinner-tacocleanse-beverly-hills-c

The <script> tag can be similarly problematic.

Proposal: Drop both <script> and <style> elements completely when parsing any property (including e-* HTML values). [[User:Tantek|Tantek]] 01:01, 29 February 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Aaronpk|aaronpk]] as a consumer of HTML from an e-* property, I will always be sanitizing the HTML and removing <script> and <style> anyway
* +1 [[User:Kylewm|kylewm]]
* 0 [[User:Barnabywalters|Barnaby]] +1 to removing the contents of <script> and <style> from all plaintext properties (and 'value' property in HTML dicts), -1 to removing <script> and <style> from HTML. That’s a job for a sanitization stage. As aaronpk points out, sanitization will have to be done anyway if the content is to be reposted, so doing so in the parser doesn’t actually save anyone any work, but removes information which could be useful to people (example use cases: publishing posts with embedded per-post styling, publishing interactive HTML documents with embedded javascript)
** +1 this seems like reasonable feedback to make a new refined proposal. [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)
</div>

Proposal 2: Drop both <script> and <style> elements completely when parsing any property (except for e-* HTML values, which preserve all markup). [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Barnabywalters|Barnaby]
* ...
</div>

=== use poster if no src on video for u props ===
[https://indiewebcamp.com/irc/2015-12-13#t1450035721661 2015-12-13 raised in #indiewebcamp]

There is a use-case of marking up the "poster" of a video element as the u-featured of an [[h-entry]], to do that, we need to change [[microformats2-parsing#parsing_a_u-_property|u- property parsing]] to look at the poster attribute of the video element, after it's looked for the src attribute.
<blockquote>" else if video.u-x[poster], then get the poster attribute "</blockquote>

Real-world example of markup in the wild:
* http://veganstraightedge.com/videos/2013/5/31/1/backyard-squirrel-buddy
** and likely all other videos posted there.

Background discussion that led to this proposal:
* https://indiewebcamp.com/irc/2015-12-13#t1450035721661

This seems very straightforward so I've added it as PROPOSED directly in the parsing spec. This issue is for tracking the discussion.

Feedback from parser implementers please!
<div class="discussion">
* ...
</div>

=== uf2 children on backcompat properties ===
[http://logs.glob.uno/?c=freenode%23microformats&s=today#c84632 2015-11-24 raised by Calli] in #microformats

Related but different from [[#uf2_children_inside_a_classic_microformats_root_class_name]], when there is a uf2 child directly on a backcompat property, what should happen? E.g.

<source lang=html4strict>
<div class="vcard">
<div class="adr h-adr">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

What is the expected behavior and parser output?

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-adr"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

<div class="discussion">
* Proposal: the nested "adr h-adr" child is treated as an mf2 object, not backcompat, and thus the resulting parsed "locality" property has a single value of "MF2". Proposed by Calli, noting that Glenn Jones's microformatshiv gets that result currently, and it would be easier for him (Calli) to implement this way.
** +1 Tantek, seems reasonable and the reasoning provided is good (we have one implementation this way already)
** +1 Kyle, this is consistent with the resolution to the related issue
** +1 Calli, yes, this is easier for me to implement (than taking both MF1 and MF2 properties) because it is consistent - for me, consistency is the controlling factor in favor rather than ease of parser implementation
** ...
</div>

Another example:

<source lang=html4strict>
<div class="vcard">
<div class="adr h-custom">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-custom"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

Per the [[#any_h-_root_class_name_overrides_and_stops_backcompat_root]] resolution, the class name "h-custom" overrides the use of "adr" as a backcompat root.

=== default generated HTML ===
2015-09-08 raised by Tantek in #indiewebcamp

Should there be a default (perhaps not quite "canonical") way to map/generate HTML+microformats2 from a parsed mf2 JSON output?

E.g. straw proposal:
* JSON/mf2 -> [[XOXO]]+mf2

Existing work / mappings:
* https://github.com/snarfed/granary/blob/master/granary/microformats2.py#L295

Related to:
* https://github.com/snarfed/granary/issues/31

Use-cases:
* default webview / presentation for a site that stores mf2 JSON output
* possibly a way to implement a distributed HTTP webcache retrieval protocol

Thoughts?
<div class="discussion">
* +1 [[User:Tantek|Tantek]] I think we should have this, but am open to proposals on specifics!
* +1 [[User:GlennJones|Glenn]] Also think this is worth looking at, but I am not sure it should be part of the parser spec. Feels like it should be built as a separate library and have it own spec on the microformats wiki.
* ...
</div>

=== Noscript skip/parse ===
2015-07-28

Should mf parsers skip <code><noscript></code> tag in the HTML, like the <code><template></code> tag mentioned in http://microformats.org/wiki/microformats2-parsing#note_HTML_parsing_rules ?

mf2py skips <code><noscript></code> when using the html5lib DOM parser but no when using lxml parser. Example use of <code><noscript></code> https://kartikprabhu.com/ featured images have a no javascript fallback image inside <code><noscript></code> with <code>class='u-featured'</code> markup.
* html5lib actually HTML-escapes the contents of <code><noscript></code>, so to mf2py it just looks like plain text with no tags. In Woodwind, I've resorted to using regex to strip out <code><noscript></code> tags before parsing (very hacky). [[User:Kylewm|Kylewm]] 15:52, 25 August 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] skip noscript (and inside) because in today's typical browsing contexts, nothing in noscript is displayed, thus we should discourage marking up effectively invisible content.
** Proposed change to [[microformats2-parsing#parse_a_document_for_microformats]]:
*** from: "follow the HTML parsing rules"
*** to: "follow the HTML parsing rules (including skipping/omitting <code><noscript></code> elements, e.g. like the html5lib DOM parser)
* -1 [[User:GlennJones|Glenn]] This subject does need to be address, but differently to proposed change. My personal view is that e-* html should be passed through raw and then the consumer can process it in a way they feel fit. Its a case for helper libraries. I am about to build a helper library to do this based on the Readability code to post process e-* html. Other people may want to take different approaches, defining this in the spec feels like move into a whole area of new functionally.

As a separate new point we need to consider "exclude tags" lists for parsed text from html. We should consider <code><noscript></code>, <code><noframe></code> and <code><template></code> there maybe other I have not gone through all the tags in current HTML spec. Also we should consider what to do about the more common pattern of fallback text within media tags <code><video></code>, <code><audio></code> etc. This should be explicitly discussed in the parsing rules. At the moment my experimental text normalisation does exclude tags, but the default text parse does not. Currently the fallback content in media tags like <code><video></code> is added to the parse text. 12:56, 25 Septemeber 2015 (UTC)
* ...
</div>

=== Standard datetime format ===
2015-07-28

http://microformats.org/wiki/microformats2-parsing#parsing_a_dt-_property does not specify any standard format to use for datetimes. e.g. <pre>2015-07-28T12:55:33</pre> vs <pre>2015-07-28 12:55:33</pre>
Would be good to standardize this to compare various parser outputs.

2015-07-29: This subject is (somewhat) covered in http://microformats.org/wiki/iso-8601 As it stands the JavaScript parsers support output in the 3 main profiles, 'W3C Note', 'RFC 3339' and 'HTML5' plus 'auto' which keeps authors format. The default date output for the JavaScript parsers is the same format as the date was originally authored in. This can be changes by setting the options.dateFormat switch to any of the other profiles mentioned. It would be good if other parser also had a switch to force output to a common profiles so we could compare various parser outputs, but I think the default should be how a date was authored. All output whatever profile should also keeps the authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string. This is important if you want to compare parser outputs.

The only exception to this where date and times are combined such as the implied h-event rule for dt-start and dt-end where I output in the HTML5 style 2015-07-29 12:55:33 as there is no predefined author preference and HTML5 profile is more human readable. [[User:GlennJones|Glenn Jones]] 11:02, 29 July 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] output more human readable <code>2015-07-28 12:55:33</code> canonically, with authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string.
** Let's update any test cases as needed for this. - [[User:Tantek|Tantek]]
* ...
</div>

=== implied date for dt properties both mf2 and backcompat ===
The [[value-class-pattern#microformats2_parsers|value class pattern dt-* date proposal]] should apply to both mf2 dt-* properties, and backcompat classic microformats, to preserve the hAtom / hCalendar optimizations noted on that page, but in a generic way.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] 16:12, 18 August 2015 (UTC)
* +1 [[User:Glenn Jones|Glenn Jones]] 20 August 2015
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== implied properties when an explicit class is provided ===
<div class="discussion">
Should "u-url" still be implied if another explicit class is already provided, as below. This is a contrived example, but it is taken from Bridgy's unit tests.

<code><pre>
<article class="h-entry">
<a class="u-like-of" href="http://orig.domain/baz">liked this</a>
</article>
</pre></code>

In this case, http://orig.domain/baz is almost certainly not the u-url, so IMO it would be better to leave it out —[[User:Kylewm|Kylewm]] 15:10, 7 October 2014 (UTC)

'''2015-01-20 consensus'''
* Changed my mind. Simpler to do nothing. Example provided is artificially constructed, does not reflect likely real world confusion of if we make implied properties more complicated. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
* ++ Consensus on do nothing for this case. At [[2015-01-20]]

'''Proposed resolution:'''
* Changed again. Due to indiewebcamp.com/edit use-case, this now makes sense for all implied properties. That is:
** If an element has any explicit property class name(s) on it, then it must not be used to imply any properties. [[User:Tantek|Tantek]] 20:50, 27 May 2015 (UTC)
*** +1 this seems reasonable, if a publisher is going to add an mf2 class, it is unlikely they want other classes automatically implied from the same value [[User:Aaronpk|Aaronpk]] 23:19, 29 November 2015 (UTC)
*** -1 for now. To my knowledge, this has only been observed in artificially constructed unit tests and examples, and it adds some weird edge cases that are hard to reason about. [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** ... provide input on this proposal here
** Refined: Or should this be refined by per parsing prefix? [[User:Tantek|Tantek]] 22:59, 18 September 2015 (UTC)
*** Any explicit "p-*" property means no implied "p-name" from that element
*** Any explicit "u-*" property means no implied "u-url" nor "u-photo" from that element.
*** ... provide input on this refined proposal here
** Suggestion: split this issue up per property. I think it makes sense for u-url and can be easily added to the spec as e.g. ".h-x>a[href]:only-of-type:not[.h-*<strong>,.u-*</strong>]". [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** Obviously wrong to assume a link explicitly pointing elsewhere is our "url"
*** More difficult to make a case for photo and especially for name.
*** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
*** ... provide input on this refined proposal here
</div>

=== whitespace collapsing revisited ===
2015-05-27: (raised by [[User:Kevin Marks|Kevin Marks]] per Glenn Jones)

Revising the microformats tests to conform to the "don't collapse whitespace" rule below reveals some non-intuitive cases.
preserving whitespace in addresses is somewhat defensible, but in an implied name it is often unhelpful, as it preserves non-user visible space there for authoring reasons.

For example:
[https://github.com/microformats/tests/commit/a325e0e9bc2089507e69b1883f7065a3316e07c2#diff-d577012c1438978a571c4049179607f0 this test] shows how extraneous whitespace ends up in the <code>name</code>

<code><pre>
<div class="h-review-aggregate">
<div class="p-item h-event">
<h3 class="p-name">Fullfrontal</h3>
<p class="p-description">A one day JavaScript Conference held in Brighton</p>
<p><time class="dt-start" datetime="2012-11-09">9th November 2012</time></p>
</div>

<p class="p-rating">
<span class="p-average value">9.9</span> out of
<span class="p-best">10</span>
based on <span class="p-count">62</span> reviews
</p>
</div>
</pre></code>

give a parsed result of:

<code><pre>
{
"items": [{
"type": ["h-review-aggregate"],
"properties": {
"item": [{
"value": "Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012",
"type": ["h-event"],
"properties": {
"name": ["Fullfrontal"],
"description": ["A one day JavaScript Conference held in Brighton"],
"start": ["2012-11-09"]
}
}],
"rating": ["9.9"],
"average": ["9.9"],
"best": ["10"],
"count": ["62"],
"name": ["Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012\n\n\n9.9 out of \n 10 \n based on 62 reviews"]
}
}],
"rels": {}
}
</pre></code>

The <code>value</code> is a reasonable textual representation of the event, but the implied <code>name</code> is full of spurious whitespace that any consumer would have to strip.

[https://github.com/microformats/tests/commit/4c9690b53b0a2f40440abac8e609c51ac7dd6d56 h-review] has similar issues

2015-05-28: (Addition by [[User:GlennJones|Glenn Jones]])

The example below shows the type of markup most effected by the "implied name" and "don't collapse whitespace" rule working together to produce output that is hard to use without further processing.

<code><pre>
<a class="h-card" href="http://glennjones.net">
<span class="p-given-name">Glenn</span>
<span class="p-family-name">Jones</span>
</a>
</pre></code>

The output for the name property from the above HTML would be <code>Glenn\r\n Jones</code> using the (trim lead/trailing) suggested in the parsing spec. I could of course move the spans onto one line, but it feels fragile to consider whitespace sensitivity in HTML like this. Added to the fact that HTML templating environments often take away that level of whitespace control from authors anyway.

There are issues with both: keeping whitespace, returns and tabs from parsed HTML or collapse that whitespace. If we return the whitespace it becomes mal-formatted for humans because it was only added to make the HTML code understandable and in most cases was not meant to be used/read outside of that context. If we collapse the whitespace we can have issues of whitespace sensitive text from <code><pre></code> etc. being incorrectly formatted.

Providing a CSS aware innerText feature would produce the most useable output, but this is too complex/time consuming to build for most parser developers. In the face of no perfect solution I have taken the 80:20 view, whereby errant whitespace, causes me considerably more problems than mal-formatted <code><pre></code> content so I collapse whitespace on all text returned.

This feature is a non-CSS aware version of innerText. It does not cover all rendering edge cases, but enough to produce practical output.

For now, I have started changing the node parser to flag "white-space collapsing" as an experimental feature which is off by default i.e. http://glennjones.net/tools/microformats/ but personally I will parse everything with this on as I find it the most practical solution.

Not sure where that leaves me on the options below.

Options:

Choose from:
# keep as is and every parser client has to post process for common cases.
# '''keep as is but have mf2 parser trim leading/trailing whitespace (likely to provide desired result and be reasonably backcompat)'''
#* +1 my preference of the two options. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
#* +1 though this doesn't solve any of the problems discussed above, it's still worth doing [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
#* +1 will help parsers be more consistent with each other, and I haven't ever encountered a case where preserving leading/trailing whitespace was desirable [[User:Kylewm|Kylewm]] 20:45, 8 June 2015 (UTC)

2015-06-08 option 2 resolved by consensus and implementation in mf2py.

Somewhat orthogonal:
* make <code>value</code> on properties with children normalise whitespace
** -1 Seems like a bad idea as this "value" is supposed to be the same as if there was no embedded child microformat. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
* make implied <code>name</code> normalise whitespace.
** +0 This is reasonable and already done somewhat in the parsing spec (trim lead/trailing). [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** +1 Given the universality of name, this would fix most of the issues we see. [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
* Put \n in textual forms if there is a <code><p></code> tag in the original.
** -1 that's a long path to go down with whitespace equivalents for HTML markup. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** would only preserving whitespace if in <pre> be an 80:20 compromise? [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)

Because there are both code markup and specific vocabulary (label) needs for preserving whitespace, we are compelled to preserve in general, perhaps except for very specific limited generic cases (e.g. trim leading/trailing, "value" parsing, implied name). [[User:Tantek|Tantek]]

=== u- parsing iframe src ===
Currently if I put u-* on an iframe it gets the value of the fallback text. This seems a shame. Getting the URL seems a sensible answer.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== i- parsing iframe src ===

More controversially, what about using an iframe for transclusion? A use case here is comments on a static site. Currently, on eg http://www.kevinmarks.com/microformatschema.html the comments are injected via JS, making them opaque to parsers and thus precluding further parsing such as salmentions.

If instead they were an iframe embedding them, a parser could optionally fetch its contents, parse them, and include them in the parsed mf2 output at that point. Overloading u-* for this seems wrong; e-* as below for srcdoc would have a different effect; this implies a new prefix directive would be needed. A strawman i-* (for include) may work.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== e- parsing iframe srcdoc ===
<div class="discussion">
* Proposal: addition of a new e-* parsing rule for iframe elements with srcdoc attributes. E.G.

<source lang="html4strict">
<div class="h-entry">
<iframe class="e-content" srcdoc="<p>A paragraph of HTML with "quoted quotes" &amp; doubly quoted ampersands</p>" />
</div>
</source>
<source lang="javascript">
{
"items": [{
"type": ["h-entry"],
"properties": {
"content": ["<p>A paragraph of HTML with "quoted quotes" & doubly quoted ampersands</p>"]
}
}]
}
</source>

This would allow, for example, HTML comments to be sandboxed inside iframes but still parsable as microformats.

I believe the correct processing would be to leave " entities as they are but to unescape any doubly-escaped ampersands.

** Is there any use case for that? —[[User:TomMorris|Tom Morris]] 12:32, 14 September 2013 (UTC)
** +1 we need documentation of use case and existing sites publishing iframe srcdoc like this - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
** Rejected by consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 properties on select ===
How should select elements with properties be treated any differently?

Awaiting real world examples / stronger use-cases, until then no special treatment of select elements with properties:
<div class="discussion">
* Are there any real world examples of select elements with microformats properties?
* What would the use-case be for putting a microformats property class name on a select element?
* Nothing special. By consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 root name on form ===
See what to do about <em>root class names</em> on <code><form></code> elements in particular:
* [[hcard-input]]

Awaiting real world examples / stronger use-cases, until then, no special treatment of root class names on <code><form></code> elements:
<div class="discussion">
* Are there any real world examples of a <code><form></code> element with a microformats root class name?
* [[hcard-input]] is one possible use-case, is anyone attempting to use forms for hCard input, e.g. with scripts to help make it work?
* Are there other use-cases for putting a microformats root class name on a <code><form></code> element?
* As of [[2015-01-20]] - no consensus - need more input as to when/why this is useful to do anything special.
</div>

===Parsing Literal Values===
Issue raised by: [[User:BenWard|Ben Ward]]

It is proposed for microformats2 that all microformats be parsable from just their root element, e.g. <code><p class="h-card">Ben Ward</p></code> would create an hCard with the following properties after parsing:

<source lang=javascript>
{
'type': ['h-card'],
'properties': {
'name': ['Ben Ward']
}
}
</source>

This is a four-fold change from the current [[hCard]]:
# type is generically identifiable as a microformat root, even in parsed form. The use of the 'h-' prefix persists into the type of the object. This is deliberately so, as a result of re-using the JSON data model of microdata which itself is re-using a common JSON convention, such that microformatted data is clearly distinguishable (as opposed to any other random schema that may be using a similar data model).
# root-class-only support. Per [[microformats-2-implied-properties]], the ''name'' property is implied by the entirety of the root class name element.
# 'name' instead of 'fn'. As also documented in [[microformats-2-implied-properties]], the continuous challenges/problems and need to repeatedly re-explain 'fn' over the years combined with the real-world market response of nearly every other party doing a person vocabulary renaming 'fn' to 'name', microformats 2 makes this change as well.
# There is no automatic parse-time inferring of <code>'given-name': ['Ben']</code> and <code>'family-name': ['Ward']</code>. Any such inferring *might* be made by a vCard converter, but is left up to that specific application (not all applications) built on that vocabulary, though even in that case it may not be necessary, as an empty "N:;;;" [[vCard]] property is sufficient to satisfy the N property requirement of [[vCard]], and also causes no problems when imported into various [[vcard-implementations]].

It is required of the extractor to understand that when a microformats object specifies no explicit child properties, that it must treat <code>h-card</code> as having a <code>p-name</code>. But, the parser is generic, so it also treats <code>h-review</code>, <code>h-entry</code>, <code>h-recipe</code>, <code>h-geo</code> as having a ‘<code>p-name</code>’.

As a result, specific vocabularies are evolved to drop their specific form of name (e.g. fn, summary, entry-title) and simplified to use a common 'name' property instead.

Note: while the overwhelming majority of real world publishing/consuming uses of microformats do so with proper nouns which have names (and thus this parser-level incorporation of an implied 'name'), there are some formats that do not have a 'name' semantic. For example, [[geo]], [[adr]], and possibly if/when developed, units of measure, length, cost. The current thinking is that the benefits to the far greater proper-noun use-case of microformats outweigh the technical inelegance of having an extra/ignored 'name' property on formats that lack such a semantic.

Some formats also may appear in theory to better imply some other property, e.g. a review might be thought to imply its ''content'', not its name, and an Atom entry its ''content'', not its title, but in practice (actual publishing patterns) this is not the case. Typically, brief unstructured reviews (or mentions thereof) provide a ''summary'' (often hyperlinked to an expanded structured form) of that review, not its content, and similarly, brief unstructured posts (e.g. RSS items) have historically most often been link blog items which include the title of an item and a link. Short status updates as well established by Twitter are newer and would seem to imply purely content with no title, at least semantically, however, even Twitter populates the RSS title and ATOM entry title of their feeds with the content. It's not clear what went into that decision, however, that's likely irrelevant, as the outcome turns out to be emergent consistency among publishing behaviors.

To avoid overloading or undermining the semantics of a vocabulary, I propose that we handle this at the extractor level in a simpler fashion: Define a new property for literal data, that an extractor will provide if no other information was available. All ''interpreters'' may then be instructed that in the event that an object has no properties, it can attempt to interpret the literal value from the page instead.

* This was one of the design iterations I went through which led me to the current implied 'name' design. Another iteration was the ability for a vocabulary to specify a single required property which was implied if there were no properties provided. However, the combination of the fact that in most cases such single required properties were quite name-like, and that a vocabulary-specific rule like that would then bind parsers to specific vocabularies (even so slightly) led me to collapse them into implying a 'name'. It's not perfect, but it's the best alternative so far that balances practical convenience of publishing/consuming, avoids vocabulary-specific knowledge in the parser, and technical (in)elegance. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

In existing microformats, the closest existing example we have for this is the <code>label</code> property in hCard, which is used to represent the literal address label for a place. It is a corresponding piece of <code>fn</code>, <code>org</code> and <code>adr</code> in combination, but has no structure in and of itself. Possibly, every microformat could have a <code>label</code> form where structured data is unavailable.

However in practice, the hCard <code>label</code> property is both little understood and little used. It's not even clear that it ought to be kept for microformats 2 (no known consumers, very few (if any?) real-world non-test publishers). This disuse is likely a good indicator that we should avoid basing anything on its design.

Alternatively, <code>value</code> is used throughout microformats to target a generic value (e.g. in combination with <code>price</code> in hListing.) It has been proposed that when parsing properties that are also themselves microformats, we create native objects of the form:

{
'value': '1900 12th Street, San Francisco, CA 94'
, 'type': ['h-adr']
, 'properties': {
'street-address': '1900 12th Street'
, 'etc': 'etc'
}
}

We could apply this same pattern to the root level:

{
type: [h-card]
, properties: {}
, value: 'Ben Ward'
}

In this case, an interpreter or implementation is responsible for using <code>value</code> in place of <code>fn</code>, or restructuring the object. It would be the responsibility of each vocabulary to define its root property. The parsing layer of microformats 2.0 would not impose semantics or naming onto that.

For another example, h-geo would end up like this:

{
type: [h-geo]
, properties: {}
, value: '1.3232;-0.543'
}

* This is an alternative I've been considering as well: [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)
** 'value' is more generic than 'name' (applies to more vocabularies) with the trade-off that it naturally has less (weaker) semantics.
*** +1 I think that having naturally weaker semantics would be appropriate for this parsing functionality. —[[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC)
** The interesting thing that this analysis has revealed is that there appear to be two distinct clusters of microformats, the much more commonly used/understood/useful proper-noun microformats which markup things with names (people, events, reviews, recipes), and the less used compound-data microformats which are often used ''inside'' other microformats and just have some sort of semi-structured value (adr, geo, measure, and perhaps even things like tel). Perhaps this is implying the possibility and some degree of utility for ''two'' microformats root class name prefixes, 'h-' for existing proper-noun microformats, and something else ('m-' for microformat/molecule?, 's-' for structured-value?, 'v-' for value (though historically "v-"/"v." has meant "vendor-specific")?) for unnamed structured data microformats.
*** This more and more feels like a good idea, and I'm leaning toward "s-" for struct / structure / structured value. "s-" works just like "h-" except that it doesn't imply any properties at parse time. We can try it and see what happens. There's also no harm if publishers just use "h-" structures, they just (possibly) get a few extra properties if they happen to omit properties.
** Parallels the same JSON when a property has both a string value ''and'' is a structure itself.
*** Changed my mind on this. The parallel is not quite there. 'name'/'url'/'photo' are only implied if there are NO properties, where as the JSON string value + structure convention *always* provides a 'value'. [[User:Tantek|Tantek]] 22:39, 4 October 2011 (UTC)
*** And due to this difference in behavior ('value' is there when nested properties are present, whereas 'name' is only implied when there are no properties specified), I think it's correct to keep them separate, i.e. stick with implied 'name'. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
** However, I'm still currently leaning towards the practical convenience of providing a 'name' for the vast majority of microformats uses, rather than diluting this feature for the sake of avoiding implying inapplicable semantics to the few plain structured data microformats, and even then, only when no properties are explicitly specified! I'd rather introduce a new root prefix for those than lose the simplicity and utility of implied 'name'. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

== resolved ==
=== When to collapse whitespace in properties ===

The spec doesn’t explicitly require whitespace to be collapsed or not. The official mf2 test suite requires it to be collapsed.

Reasons why whitespace ''shouldn’t'' be collapsed:
* Plaintext property representations of syntax-highlighted code, poetry and song lyrics require whitespace to be present
* Whether or not whitespace is an important part of the content being parsed is determined by css white-space and CANNOT be inferred from HTML markup alone

Resolution 2013-11-12: Agreed, whitespace should not be collapsed (other than normal HTML5 parsing rules). The spec now refers to "textContent" rather than "innertext" to make this explicit.

=== How to interpret mf2 classnames on form inputs ===
E.G. how to parse:

<source lang=html4strict>
<input class="u-url" value="https://brennannovak.com/notes/338" />
</source>

Examples in the wild: https://brennannovak.com/notes/338

See proposal:
* [[hcard-parsing-brainstorming#input_element_handling]]

Resolution 2013-11-12: Per that proposal, p- u- dt- properties on input[value] elements now use the value attribute.

=== mixture of microformats2 and classic microformats classnames on different elements ===
Some sites in the wild have mistakenly combined classic mf and mf2 markup in ways which misrepresent the content if parsed in BC mode.

Typically this is caused by putting classic and mf2 classnames for the same vocabulary on different elements, e.g:

<source lang="html4strict">
<body class="hentry">
<article class="h-entry">
<h1 class="p-name"></h1>
</article>
</body>
</source>

Sites where this has been observed:
* http://acegiak.machinespirit.net/2013/10/17/barnaby-walters-notes-another-thing-i-love-about-the-web-users-have-the-power-to-take-control-of-their-uis-and-improve-their-own-experiences-aside-drm-for-html-would-prevent-this-from-being-possibl/
* http://shawfactor.com/2013/08/06/thoughts-on-extending-webmentions/ (fixed)
* http://notizblog.org/2013/06/18/the-rise-of-the-indieweb/ (fixed)

Discussion:

* As far as I can tell, the problems in all of these examples were caused by mf2 markup being injected by a wordpress plugin, but classic mf classnames being present further up the DOM in the themes. When parsed in compatibility mode, the classic mf classnames are transformed into mf2 classnames, making the original mf2 classnames look like children of empty items.
* Turns out this isn’t theme-specific, WordPress injects hentry via PHP [http://indiewebcamp.com/irc/2013-10-22/line/1382448759]. The bug with the wordpress mf2 plugin is resolved as of [http://indiewebcamp.com/irc/2013-10-22/line/1382449035 2013-10-22] --[[User:Barnabywalters|bw]] 13:38, 22 October 2013 (UTC)

=== e- and p- escaping levels ===
<div class="discussion">
* The fact that the parsed value of any element with .e-* is at a different level of escaping to the parsed values of p-*, dt-* etc. without any indication of how the property was parsed in the output is a security problem. For example:

<table style="width: 100%">
<tr>
<th>input</th>
<th>output</th>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="p-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="e-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
</table>

* As a parser developer, the most straightforward way I can think of solving this is to add an option (enabled by default) which encodes HTML special characters on all non e-* properties, so the developer knows that all property values are going to be at the same level of escaping. --[[User:Barnabywalters|bw]] 20:00, 15 June 2013 (UTC)
** Your suggestion of auto-HTML-encoding p-*/u-*/dt-* property values is the most sensible I think. I would NOT make it an option, as it makes sense write consistent microformats2 consumers. - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
** Can you think of any existing apps/consumers of microformats2 via the parser that would break? What would indieweb comments parsers do? - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
*** The only breakage which might occur would be over-encoding of non e-* properties, but I’ll release this update as v0.2.0 and warn people about the changes. The worst thing which could happen is that some comments look a bit weird, as opposed to the current worst possible scenario of easy XSS attacks --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** We should also decide exactly which characters get encoded — just angle brackets, or quotes/ampersands as well? --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** I am not sure about this, it seems more like a helper function rather than a core feature of the parser. Personally I would like to store data as text and encode only when I am going to use and I known the format it is going to be use in. --[[User:GlennJones|Glenn Jones]] 9:54, 14 July 2013 (UTC)
***After the discussion on the indiewebcamp IRC with Barnaby Walters I now understand the XSS issue that this change is trying to address. A rogue author could include HTML with scripts to execute a XSS attack. These could be masked by switch prefixes i.e. p-* to e-* on a well use property. As the consumer does not see the prefix in the JSON output they have no idea if a property will content HTML or text. I will update my two parsers and the test suite --[[User:GlennJones|Glenn Jones]] 8:02, 17 July 2013 (UTC)
**So what about an author setting a property to e-* when it would normal be p-*, dt-* or u-* i.e.
<source lang=html4strict>
<div class="h-card"><p class="e-name"><script> alert('xss test') </script></p></div>
</source>
** per [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]], parsers should never automatically attempt to HTML-special-characters encode - as that would provide the client of the parser a false sense of security. It's *always* up to client code to escape any text being output to HTML *at the moment it is output to HTML* and never before, because they can never trust that any text from storage/elsewhere has for sure been escaped or not. - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** Should we not encode e-* as well and the consumer can decode at their own risk --[[User:GlennJones|Glenn Jones]] 18:42, 21 July 2013 (UTC)
*** No, never, per above point from [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** See [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] etherpad: https://etherpad.mozilla.org/microformats2parsing for more details on the resolution to this issue - and incorporate here (then move to resolved section below). - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
* Resolved by changes to the parsing spec: all properties are plaintext (non-HTML escaped), e-* properties result in a dictionary with <code>value</code> = plaintext version, <code>html</code> = raw HTML version
----

</div>

=== br hr empty string ===
<div class="discussion">
* The parsing rule 'else if br.p-x or hr.p-x, then return "" (empty string)' for p-* can cause any code consuming the API to become quite bloated. It means that you have test every array value to see if its an empty string. It is also unclear to me what the purpose of this mark-up pattern is for [[User:GlennJones|Glenn Jones]]
** Upon reconsidering this, I agree with you, this is an unlikely use case. If a publisher wants to explicitly set an empty property "p-foo" they can simply write <code><span class="p-foo"></span></code> which looks explicit. Whereas BR and HR tags are often just presentational, so we should both not encourage usage of them for semantics, and anyone that did use them would be subject to likely loss of semantics upon a redesign (that got rid of those particular BR and HR tags). I'm going to remove them from the parsing spec. - [[User:Tantek|Tantek]] 15:29, 10 February 2013 (UTC)
</div>

=== datetime examples without T delimiter ===
<div class="discussion">
* The examples in the wiki microformats-2 pages such h-entry and h-entry had datetime without the 'T' delimiter between date and time. ie
<source lang="html4strict">
<time class="dt-published" datetime="2013-06-13 12:00:00">13<sup>th</sup> June 2013</time>
</source>
I have updated the pages. As far as I known this is a new pattern for dates. Was it a mistake in the examples or is it a new datetime pattern.
** The [[HTML5]] "time" element, and "datetime" attribute allow for space <span style="white-space:nowrap">" "</span> as a separator between date and time as well as "T", thus we allow it for microformats as well. The <span style="white-space:nowrap">" "</span> separator is preferred as the date and time are more readable when separated by a space. The examples noted in those specs deliberately use this. - [[User:Tantek|Tantek]] 18:48, 15 July 2013 (UTC)
</div>

=== rel-alternate absent optional attributes ===
<div class="discussion">
* What should rel-alternate parsing do when one of the optional attributes specified (<kbd>hreflang</kbd> or <kbd>media</kbd> or both) is not there? The options seem to be:
*# leave the corresponding key out of the alternate JSON object
*#* This one. Leave the corresponding key out.
*# include the corresponding key in the alternate JSON object, but set the value to the JSON null object
*# include the corresponding key in the alternate JSON object, but set the value to a blank string
*# something I haven't thought of

I haven't checked the existing implementations, but Barnaby said he's not sure what the appropriate way to deal with it is either. —[[User:TomMorris|Tom Morris]] 15:41, 9 August 2013 (UTC)
</div>

=== rel-alternate and type attribute ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Should rel-alternate parsing also pick up the <code>type</code> attribute? It’s fairly widely used, e.g. for ATOM feeds.
** Numerous existing sites/pages have various [[rel-alternate]] uses with a type attribute for feeds/APIs so that's good enough to add this for help with discovery in general. Rel parsing updated. - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
</div>

=== Extraction vs Interpretation ===
Issue raised by: [[User:BenWard|Ben Ward]]

A microformats ‘1.0’ parser performs the following function:

* Given a piece of HTML content, discover a known microformat, extract it, apply various extraction patterns based upon the HTML mark-up used (e.g. include pattern, <code>abbr</code> patterns, date-time patterns, value-title pattern), apply various content optimisations where applicable, and return the result in an object native to the programming language.

This is performing two types of function: Extraction of data from an HTML document or fragment, ''and'' interpretation and optimisation of that content to match the rules set out by a vocabulary specification.

It is only possible to write a generic parser that covers the first half of this task: Extraction, and application of global rules based on HTML elements and patterns common to all formats.

The purpose of a generic parser (as supported by use cases such as search engines, and other crawlers) is:

To provide a way for tools to extract rich data from a page for native storage, such that the data may be interpreted later by applications. This allows microformats to be crawled, and indexed, and removes the need to include complex HTML parsing within every implementation of microformat data.

Microformats will continue to define various vocabulary-specific optimisations. as part of the design to be optimised for authors. For example: The <code>fn</code> pattern in [[hcard]], or the <code>lat;long</code> pattern in [[geo]], as well as default values for properties, such as the maximum rating in an [[hreview]].
* Actually, no, as it is defined currently, microformats 2 ''drops'' vocabulary-specific optimizations. Such optimizations have often been too inapplicable, error prone or i18n-unsafe (e.g. fn to given-name + family-name fails for both numerous cases where middlenames/initials are used, and in general in numerous Asian languages where given/family name order is the reverse of Western English conventions, or languages with multiple family-names, e.g. Spanish - see [[hcard-issues-resolved]] for more). This is a deliberate cutting of a "feature" from microformats 1, it is a deliberate model simplification design decision. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

==== Extraction resolution ====
Proposed resolution:

Microformats2 should refer only to ''extraction'' of microformats. Vocabularies should in turn document their appropriate optimisations, which will need to be applied by implementations, or a companion to an extractor, which I'll refer to here as an ‘interpreter’.
* Vocabularies will no longer have optimizations, this is again deliberately, as they've been shown to be more error prone than helpful. Thus there should be no need for any vocabulary-specific 'interpreters'. However, due to design quirks in various legacy/interchange formats, ''export conversions algorithms'' to those legacy/interchange formats will require some additional legacy-format-specific rules (e.g. odd "required" rules in [[Atom]] or [[vCard]] will require specific synthesis rules, limitations in said formats will require filtering of some values, e.g. [[vcard3]] BDAY disallows vague birthdays like year-month and --month-day - subsequently allowed in [[vcard4]]). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

A microformats2 ‘extractor’, in combination with the functionality of a domain and format-aware ‘interpreter’ (either another shared component, or part of the implementation itself) would be equivalent to a microformats 1.0 ‘parser.’
* A microformats2 parser is both generic (no knowledge of specific vocabularies), and lacks any/all such vocabulary-specific rules as compared to a microformats 1.0 [[hcard-parsing|parser]] with the exception of a 1) a limited list of well-established/interoperable backward compat root class names (of current [[microformats]] that are or can be soon shown to be specifications/standards per the [[process]]), 2) flat sets of backward compat property names (some with prefix/name specific conversion) for each of those backward compat root class names. This is a deliberate design decision that makes microformats 2 more "micro", and yes this means that even with such backward compat support, this simple form of backward compat may mean that some existing microformats 1 content breaks. We'll assess those and iterate on a documented case-by-case basis rather than attempt to maintain theoretical 100% backward compatibility (since many current microformats format-specific-features are either unused, or may have caused more problems than solutions). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

N.B. I'll rewrite some of these as [[microformats2-parsing-faq]] to help better clarify. The reasoning that led to most of these design decisions is documented in the [[microformats-2#About_This_Brainstorm|microformats 2: About This Brainstorm]] section and following sections. I'll recheck those sections to see if/where reasoning for some of the above noted design decisions may have been missed, and back-fill accordingly. This is necessary because [[microformats2]] is a evolutionary result of simultaneously addressing both numerous generic [[issues]] as well as various common [[hcard-issues-resolved|format]]-[[hcalendar-issues-resolved|specific]] [[mfo|problems]] in microformats1 syntax and vocabularies. The very number of changes may make it more challenging (from a microformats1 perspective) to see why any particular design change has been made. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

This issue can be moved from resolved to closed once the above-mentioned write-ups have occurred.

===Parsing properties from rel attributes===
tl;dr resolution: As of 2013, [[microformats2-parsing]] handles parsing all link and a href rel values at document scope level, and producing canonical JSON accordingly. - [[User:Tantek|Tantek]]

Issue raised by [[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC):

* Currently, hAtom parses `bookmark` as a permalink
* Various microformats parse `rel=tag` as tags
* The current proposal for parsing does not allow parsing properties from rel attributes.

Microformats parsers could instead extract ''all'' link relationships from rel attributes within an microformat object, parsing them as if a u- prefixed property.
* Minor nit: Rather than same as a u- prefixed property, I think such "rel" properties should be parsed purely from the <code>href</code> attribute on <code><a></code> and <code><area></code> elements and nothing more. I would strongly disagree to extending rel to apply to other elements with URLs like img src, object data, or to apply to elements in general like div. That's the path that RDFa has taken and caused much confusion as a result. [[User:Tantek|Tantek]] 07:39, 5 October 2011 (UTC)
** Agree: That seems like a perfectly reasonable restriction. --[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)

This results in:

* Continuing use of the <code>rel</code> attribute in HTML, thereby building on HTML semantics rather than bypassing them or ignoring them in favour of something less meaningful.
* Parsing hAtom objects contain a property named <code>bookmark</code>, in place of <code>permalink</code>.
* All microformats that use <code>rel-tag</code> would contain a property named… <code>tag</code>. Perfect.

Since <code>rel</code> attributes are not overloaded for other functionality like class is, and other uses of <code>rel</code> within content are low (and non-semantic uses are nil, to the best of my knowledge) the risk of property pollution would be extremely low.

Note, with regard to this last point, that a generic microformats parser ''will'' parse false-positive properties, and ''will'' parse objects in combined chunks, rather than individually by format. Extracted objects will often not represent a vocabulary without further processing.

<div class="discussion">
* This sounds like it might be workable. Let's try it and see how well authors "get it". - [[User:Tantek|Tantek]]
* Possible issue: do we have any collisions between class property names and rel names? (I don't think so offhand, but useful to ask the question). - [[User:Tantek|Tantek]]
** None that I can think of in microformats. There is the case of Google's <code>rel=author</code> and <code>p-author</code> in hAtom. However, the next point, about mfo scoping, would cover it in most situations (rel-author on a hyperlink within an hcard wouldn't be applied to the hentry.) The one situation in a parse tree where it's ambiguous would be this:
<source lang=html4strict>
<a href="p-author h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
** I can think of two quite reasonable solutions:
*** 1. Declare that class properties take precedence over rel properties of the same name, discarding rel values if a class is also found, or
*** 2. Since all properties are now multi-value anyway, the hAtom object could be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
** —[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)
*** Option 2 makes sense and is consistent with the rest of the multi-value parsing/handling. - [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
*** What about without the 'p-author'?
<source lang=html4strict>
<a href="h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
Should that be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
Or
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': 'http://benward.me' /* from the rel="author" */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},

],
…
}
}
</source>
*** And if the former, then we're presumably saying that the value parsed due to the presence of a rel is always its own value, and does not combine with any other structures. I am fine with this, but I wanted to make sure we are ok with that explicitly. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
**** +1 I think that since the rel attribute is specifically concerned with the relation to an href attribute, it should not be combined with other structures that are rightly declared uses classes.
***** The more I've thought about this and how consuming applications may want to treat rel semantics, the more it seems correct to keep rel semantics distinct from class semantics. Class semantics are quite general/flexible, whereas rel is quite specific, naming something else in terms of a relationship from the current page/microformat's perspective. I think we should consider putting rel values in their own 'rel' collection, separate from the 'properties' collection. E.g. the original rel-author p-author h-card markup example would be parsed into this:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
}
],
…
}
'rel': {
'author': ['http://benward.me'] /* from the rel="author" */
}
}
</source>
***** and if a post had multiple authors:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from p-author */
'type': ['h-card'], /* from h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
{
'value': ['Tantek Çelik'], /* from 2nd p-author */
'type': ['h-card'], /* from 2nd h-card ... */
'properties': {
'name': ['Tantek Çelik'],
'url': ['http://tantek.com']
},
],
…
}
'rel': {
'author': [
'http://benward.me', /* from rel="author" */
'http://tantek.com' /* from 2nd rel="author" */
]
}
}
</source>
***** This preserves the semantic distinction between rel and properties in general, and leaves it up to a higher-level application to implement any logic around showing "more info" about a rel-author, e.g. by correlating the rel-author URL with the 'url' of an hCard it found in the same entry. However, note that even in the earlier JSON data model, the rel-author value just shows up as another property value, and any higher level application would still have to do some correlation logic. At least with this JSON data model, applications that may be looking for a rel value in particular, or a property value in particular can do so without having one unintentionally pollute the other. [[User:Tantek|Tantek]] 17:33, 6 October 2011 (UTC)

* Presumably we'd apply all the same property scoping rules to rel scoping as well. E.g. a rel hyperlink inside a microformat won't be seen by any containing microformat. - [[User:Tantek|Tantek]]
** Correct, it should be parsed in the same scope as all other class properties in the object.
*** Update: all rel microformats are now parsed at page-scope. Per-microformat scoping of rel has been found to be too confusing in practice (and against the general semantic of rel expressed in the HTML/HTML5 specs) [[User:Tantek|Tantek]] 01:00, 10 July 2014 (UTC)

This issue can be moved from resolved to closed once we've verified that all the above-mentioned and implied needs to write things up have occurred.
</div>

=== deduping of rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-02 by [[User:Kevin Marks|Kevin Marks]]
* 2015-06-05 resolved by consensus and one real world implementation proof of implementability and verification of expected results. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

Many sites have multiple duplicate rel links to the same url - a very common case is WordPress home pages eg [http://ma.tt ma.tt]

Each post on the page has a block like
<code><pre>
<div class="entry-meta">
<span class="date">
<a href="http://ma.tt/2015/05/beethoven-mozart-bach/"
title="Permalink to Beethoven, Mozart, Bach" rel="bookmark">
<time class="entry-date" datetime="2015-05-31T22:42:00+00:00">May 31, 2015</time></a></span>
<span class="categories-links">
<a href="http://ma.tt/category/asides/" rel="category tag">Asides</a></span>
<span class="author vcard">
<a class="url fn n" href="http://ma.tt/author/saxmatt/"
title="View all posts by Matt" rel="author">Matt</a></span>
</div></pre></code>

As currently defined, the parser will create duplicate entries in <code>rels</code> for each post:
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/",
"https://ma.tt/"
],
}
</pre></code>

and in the <code>rel-urls</code> we will also see:
<code><pre>
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author",
"author",
"author",
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home",
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag",
"category",
"tag",
"category",
"tag",
"category",
"tag"
],
"text": "Asides"
}
</pre></code>
These duplicates are unhelpful for parser consumers. We should:
* make them both sets - only listing distinct values. This will remove ordering information, but order is irrelevant for rel in html.
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/"
],
}
…
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag"
],
"text": "Asides"
}
</pre></code>

* possibly we could also make <code>title</code> <code>text</code> <code>type</code> sets too. That would solve the information loss issue with the current parsers
** Resolution: in the case of duplicate other attributes, first one set wins. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

<div class="discussion">
* +1 as the proposer. A version of mf2py that does this is running at unmung,com. see [http://www.unmung.com/mf2?url=https%3A%2F%2Fma.tt&html=&pretty=on fro ma.tt] or [http://www.unmung.com/?html=%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E&pretty=on a simple test] [[User:Kevin Marks|Kevin Marks]] 23:49, 2 June 2015 (UTC)
* +1 makes sense to me, and not having them be sets in the current spec is likely an oversight on my part. Thanks for noting this issue. [[User:Tantek|Tantek]] 05:28, 3 June 2015 (UTC)
</div>

=== include alternates in rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 resolved per consensus and one real world implementation proof of implementability. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* add "alternate" rels to the "rels" collection to make them easier to look-up in "rel-urls" - that is, all rel values end up in "rels" collections. No exceptions.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls".
* +1 This makes sense to me, as the <code>rels</code> and <code>rel-urls</code> should match so you can lookup in rels first, then get details about urls from rel-urls. We can drop "alternates" independently from this change. [[User:Kevin Marks|Kevin Marks]] 00:23, 2 June 2015 (UTC)
** +1 drop "alternates" independently now made a separate issue. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
* +1 Makes sense. And I agree with Kevin; I think parsers should deprecate "alternates" for now and drop it after a version cycle or two. [[User:Kylewm|Kylewm]] 00:30, 2 June 2015 (UTC)
* implemented in [https://github.com/kevinmarks/mf2py/commit/4dba45200eef11da811f64817d02044ab9e98b77 my fork of mf2py] and running on [http://www.unmung.com/?html=%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fa%22%3Eauthor+a%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fb%22%3Eauthor+b%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F1%22%3Epost+1%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F2%22%3Epost+2%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22alternate+home%22%0D%0A+++href%3D%22http%3A%2F%2Fexample.com%2Ffr%22%0D%0A+++media%3D%22handheld%22%0D%0A+++hreflang%3D%22fr%22%3EFrench+mobile+homepage%3C%2Fa%3E&pretty=on unmung] [[User:Kevin Marks|Kevin Marks]] 01:29, 2 June 2015 (UTC)
</div>

=== Empty properties overridden by implied rules against user expectation ===
Status: resolved, existing behavior correct, no changes to parsing spec.

2015-07-03: raised by [[User:Glenn Jones|Glenn Jones]]

Emma Kuo brought up an issue (https://github.com/glennjones/microformat-node/issues/22) based on following the indieweb note pattern, where the content of a note is given both the e-content and p-name classes. If the element containing the notes only has none text content like image the p-name can have unexpected value. Here is the example she gave:

<code><pre>
<div class="h-entry">
<a href="http://this.site/photo" class="u-url"></a>
<div class="e-content p-name"><img src="photo.jpg" class="u-photo"/></div>
Some extraneous text
<div class="h-cite">
<a href="http://someother.site/like" class="u-url"></a>
<a href="http://this.site/photo" class="u-like-of"></a>
<div class="e-content p-name">liked this</div>
</div>
</div>
</pre></code>

At the moment I parser this as follows: - if a property (p-name) is empty do not add it to the output. In this case "empty" is classed as not containing any non-whitespace text. As far as I known there is no guidance on how to handle "empty" properties in microformats paring rules, so I followed the conventions of JSON API's not to return "empty" properties.

The side effect of the above is that p-name also has a number of "implied rules". The "implied rules" try to automatically fill properties like p-name if there is no defined value. In the example above it uses the textContent of the parent h-entry, so value of the h-entry>p-name is the text content of the h-cite i.e. "likes this".

Options:

1. We should not allow the "implied name rule" to get textContent from within a child h-*
<div class="discussion">
* <strike>+1 I believe this is inline with how we parse properties and will meet user/author expectations [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* -1 A nested h-* is still part of the content of the parent h-*, I don't quite understand the rationale for excluding it. For example, I may include lots of h-cards in the body of a post that references people and wouldn't want them to be excluded from the implied name generation. [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* -1 I'm not sure this would solve the problem because auto-filled text could come from the parent h-* ("some extraneous text" in the example above) [[User:emmak|Emma Kuo]] 20:50, 4 July 2015 (UTC)
* -1 I agree with the other -1s. This would break some of the simplicity of the model. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
</div>
2. We should not execute the "implied rules" where there is an author defined "empty" property.
<div class="discussion">
* <strike>-1 Although the output would meet author expectations it is complex for parsers as they will have to keep state for each property through the whole series of parsing rules. [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* +1 An explicit, empty, p-name property should prevent an implicit p-name from being generated. For example tantek.com includes <span class="p-name"></span> at the start of the h-feed to prevent a giant name from being auto-generated. From my reading of the parsing spec, I don't see any reason that blank strings should be excluded from parsing. (mf2py and php-mf2 will both happily include empty strings in their output) [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* +1 We already have interop on this between mf2py and phpmf2, as well as people depending on it to explicitly set empty property values. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
* +1 As we already have interop with two parsers and solid user issue from Emma we should take this approach. [[User:GlennJones|Glenn Jones]] 11:51, 29 July 2015 (UTC)</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== uf2 children inside a classic microformats root class name ===
Status: incorporated into [[microformats2-parsing]]

2015-020: (raised by kylewm) What should microformats2 children inside a classic microformats root class name do?

Options:

1. Nothing. Any unattached uf2 children inside a classic microformats root are ignored. Problems:
<div class="discussion">
* However then there's a possible surprise if/when the author upgrades the classic microformats root to uf2, then all of a sudden all the new uf2 children show-up.
* Another downside: author adds uf2 markup, can't figure out why nothing is happening (because somewhere up the tree in code they didn't touch is classic microformats that are hiding these unattached uf2 children.
</div>
2. Show up in the children collection of the classic microformats root
<div class="discussion">
* Feels most predictable. When you add uf2 root class names anywhere, they will show up in the JSON output hierarchy.
* When you convert ancestor class microformats root class names to uf2 root class names, no surprise in terms of which microformats show up. Same children collection.
* +1 Thus I'm leaning towards this one, despite the fact that classic microformats never had a concept of generic unattached children. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)
* +1 I think this is the best option I will implement it and update the wiki once its in the JavaScript parser. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>
3. Show up as peers to the classic microformats root. Issue(s)
<div class="discussion">
* Has ths surprise aspect of if/when you convert the classic root class name to a uf2 root class name, the former peers become unattached children.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== any h- root class name overrides and stops backcompat root ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: The presence of any h-* root class name overrides and stop any backcompat parsing of classic microformats root class names on that same element. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for restricting backcompat root class name to only seeing backcompat property class names
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
* I don't think I understand this rule. If I was stop all parsing of of classic microformats in the presence of any h-* root in a document then some of the other rules such as "uf2 children inside a classic microformats root class name" do not make sense. Could this item be expanded and explained a bit more? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** added "on that same element" as that was what we were discussing/implying in this issue. [[User:Tantek|Tantek]] 22:49, 18 September 2015 (UTC)
</div>

=== backcompat classic microformats should only see backcompat properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats vocabulary that indicates a backcompat root class name (and thus an absence of the microformats2 equivalent on the same element), parsers must only look for the backcompat properties that are specified explicitly for that backcompat root class.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such behaviour was never expected by authors, and crossing a classic microformats root class name with microformats2 property names were never explicitly expected nor specified to work.

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== microformats2 root class names should only see microformats2 properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats2 root class name, only explicit microformats2 properties should be parsed. Any backcompat property names must be ignored.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such microformats2 authors should be expected to do all their microformats markup with microformats2 class names - this is a deliberate expectation so that their microformats aren't polluted with other (classic microformats) coincidentally named generic class names.

Thoughts?
<div class="discussion">
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== implied properties on backcompat parsing unlikely to be intended ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
Since classic microformats had no notion of implied properties, when implied property parsing occurs on backward compat classic microformats root class names, it is unlikely that any implied property (p-name u-url u-photo) was ever intended by the author of the classic microformat. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
Examples:
* see https://indiewebcamp.com/h-entry#bad_hentry_properties for a growing list

'''Proposed resolution:'''

* Be explicit in implied property parsing that it must only be done for explicit 'h-*' root class name microformats, not for any (back)compat parsing of microformats. Please comment on this proposal with "** comment" on new lines below. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
** +1 This makes a lot of sense to me. We should strive to parse mf1 as it was intended by the author, and I think you're right that implied rules are unlikely to be what was intended [[User:Kylewm|Kylewm]] 03:22, 30 December 2014 (UTC)
** +1 I think this will help backcompat parsing, but there are two major things to consider. It may well break some consumer code as the output for a microformats currently always has the name property, there may not be the defences code to check this is true when we remove the implied name rule for classic microformats. The test suite will also need major updating as all the test output for classic microformats will have. I will look into implementing this and report back to the wiki. [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** Also it should be made clear that we are only removing the implied rules from classic microformats parsing and not the value property? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
*** The "parsing for implied properties" section only references name, photo, url properties. Where (in the spec) is the confusion about "value" coming from? [[User:Tantek|Tantek]]
** RESOLVED at [[2015-01-20]] meetup. [[User:Tantek|Tantek]] 04:09, 21 January 2015 (UTC)
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Set implied properties by microformat version"

=== link elements and u- parsing ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Raised by tantek on 2014-07-08 on [http://logs.glob.uno/?c=freenode%23microformats&s=8+Jul+2014&e=9+Jul+2014#c72916 irc]: should the parsing specification for handling u- properties be modified to include the <code>link</code> element? The potential downside is that [[invisible-metadata-is-considered-harmful]], however all known real world examples of <code>link</code> are <em>semi-</em>visible data (not fully hidden).

There are potential cases for wanting to use link as an alternative to <code>a</code> (and <code>area</code>), such as a whole page where the root <code>html</code> element is an <code>h-card</code> and the properties are included across the page: some in visible data in the <code>body</code> while others are in the <code>head</code> as <code>link</code> elements. Example:

One specific use-case is the semi-visible <code>link rel="shortcut icon" href="..."</code> - which is visible sometimes in browser UI, and also when a user chooses "Add to Home Screen" on a mobile device. Such page level icons may be used as a <code>u-photo</code> or <code>u-logo</code> of the containing <code>h-*</code> object on the <code>html</code> element.
* http://adactio.com/about/myself/ on 2014-190
** <em>could</em> use <code><html class=h-card></code> - page is all about Jeremy Keith the person
** <em>icon / logo is only</em> on <code><link></code> tag which <em>could</em> use <code>class=u-logo</code>: <br/><code><link rel="shortcut icon apple-touch-icon" type="image/png" href="/icon.png" /></code>

Another specific use-case is a post permalink page, e.g. with <code><html class=h-entry></code>
* http://waterpigs.co.uk/notes/4WjHpC/
** <em>has</em> <code><html class="no-js h-entry hentry h-as-note" lang="en"></code>

Another use-case is publishing links to PGP/GPG keys linked from the head which is currently handled by <code><link rel=pgpkey></code> which is already supported in existing [[microformats2-parsing#parse_a_hyperlink_element_for_rel_microformats|microformats2 rel parsing]] of <code>link rel</code> elements. Thus there is a (admittedly weak) argument for consistently parsing <em>both</em> <code><link rel></code> <em>and</em> <code><link class="u-*"></code>.

E.g. inside that aforementioned real world <code><html class=h-entry></code> post permalink page example,
* why should <code><link rel="in-reply-to"></code> work
* but not <code><link class="u-in-reply-to"></code> ?
The slightly stronger argument for consistency of link handling is that it <strong>[[simpler|simplifies]]</strong> the publisher (and parser) model:
* <code><a></code> and <code><area></code> work for both <code>rel</code> and <code>class</code>
* why does <code><link></code> only work for <code>rel</code> ?
* it would be <em>simpler</em> if all three tags just worked (in the same way) for both <code>rel</code> and <code>class</code>

'''Should the parsing spec be modified to handle these cases?''' —[[User:TomMorris|Tom Morris]] 09:25, 9 July 2014 (UTC)

** I'm generally in favour. It'd be good to see what other parser developers think. —[[User:TomMorris|Tom Morris]] 10:16, 9 July 2014 (UTC)
** adding this to the parsers won't be an issue. <del datetime="2014-07-09T18:45">The question is should the door be opened to hidden mf data?</del> <ins datetime="2014-07-09T18:45">Up on further reflection, there seems to be no need to distinguish between <code>rel=property</code> and <code>class=u-property</code> on link elements. So I am in favour for consistency.</ins> [[User:KP|Kartik]] 18:30, 2014-07-09 (EST)
** RESOLVED at [[2015-01-20]] meetup. Make link consistent with a.
</div>

=== drop alternates collection ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 split into separate issue from include alternates in rels per implementation feedback from Kevin Marks. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* drop "alternates" as its no longer needed, and all current consuming code clients like rel-urls better anyway.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls" in original issue now "include alternates in rels", we no longer need "alternates", and those with client consuming code have universally indicated that they would rather use rel-urls anyway. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
</div>

== see also ==
* [[microformats2-parsing]]
* [[microformats2]]

microformats2-parsing-issues

2016-03-13T18:47:33Z

Barnabywalters: /* exclude style elements before parsing */ added agreement to removing style and script contents from plaintext properties, objection to removing them from HTML properties

This page is for documenting issues with the [[microformats2-parsing]] specification.

== issues ==
Open issues in various states of partial resolution from none to nearly resolved.

=== ignore u-camelCase properties ===
Due to Suit CSS (and others? citations?) recent (2015-?) use of "u-*" class names for so-called "[http://davidtheclark.com/on-utility-classes/ utility classes]", we are seeing some false positives in a few very rare instances, e.g.: http://www.unmung.com/mf2?url=http%3A%2F%2Fwww.kevinmarks.com%2Ftwitterutils.html&html=&pretty=on

(Nearly) all these "utility classes" use camelCase for the class name suffixes, thus we can filter them out by looking for camelCase (since microformats class name conventions are always all lowercase and hyphenated), or even just looking for (and rejecting) *any* capital letters.

Proposal:
* microformats2 parsers MUST IGNORE u-* classnames where the * has any uppercase letter(s).

<div class="discussion">
* +1 [[User:Tantek|Tantek]] Let's get this fix rolling quickly to avoid further pollution.
* ...
</div>

=== exclude style elements before parsing ===
[http://logs.glob.uno/?c=freenode%23microformats#c85457 2016-01-25 raised in #microformats]

Ran into an issue of a <style> element being parsed as plain text in a p-name. Should [[microformats2-parsing]] be updated to indicate <style> should be excluded when parsing? Appears to implicitly fall under [[microformats2-parsing#note_HTML_parsing_rules]]

Sample link: http://veganstraightedge.com/notes/2016/01/16/tonight-s-dinner-tacocleanse-beverly-hills-c

The <script> tag can be similarly problematic.

Proposal: Drop both <script> and <style> elements completely when parsing any property (including e-* HTML values). [[User:Tantek|Tantek]] 01:01, 29 February 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Aaronpk|aaronpk]] as a consumer of HTML from an e-* property, I will always be sanitizing the HTML and removing <script> and <style> anyway
* +1 [[User:Kylewm|kylewm]]
* 0 [[User:Barnabywalters]] +1 to removing the contents of <script> and <style> from all plaintext properties (and 'value' property in HTML dicts), -1 to removing <script> and <style> from HTML. That’s a job for a sanitization stage. As aaronpk points out, sanitization will have to be done anyway if the content is to be reposted, so doing so in the parser doesn’t actually save anyone any work, but removes information which could be useful to people (example use cases: publishing posts with embedded per-post styling, publishing interactive HTML documents with embedded javascript)
</div>

=== use poster if no src on video for u props ===
[https://indiewebcamp.com/irc/2015-12-13#t1450035721661 2015-12-13 raised in #indiewebcamp]

There is a use-case of marking up the "poster" of a video element as the u-featured of an [[h-entry]], to do that, we need to change [[microformats2-parsing#parsing_a_u-_property|u- property parsing]] to look at the poster attribute of the video element, after it's looked for the src attribute.
<blockquote>" else if video.u-x[poster], then get the poster attribute "</blockquote>

Real-world example of markup in the wild:
* http://veganstraightedge.com/videos/2013/5/31/1/backyard-squirrel-buddy
** and likely all other videos posted there.

Background discussion that led to this proposal:
* https://indiewebcamp.com/irc/2015-12-13#t1450035721661

This seems very straightforward so I've added it as PROPOSED directly in the parsing spec. This issue is for tracking the discussion.

Feedback from parser implementers please!
<div class="discussion">
* ...
</div>

=== uf2 children on backcompat properties ===
[http://logs.glob.uno/?c=freenode%23microformats&s=today#c84632 2015-11-24 raised by Calli] in #microformats

Related but different from [[#uf2_children_inside_a_classic_microformats_root_class_name]], when there is a uf2 child directly on a backcompat property, what should happen? E.g.

<source lang=html4strict>
<div class="vcard">
<div class="adr h-adr">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

What is the expected behavior and parser output?

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-adr"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

<div class="discussion">
* Proposal: the nested "adr h-adr" child is treated as an mf2 object, not backcompat, and thus the resulting parsed "locality" property has a single value of "MF2". Proposed by Calli, noting that Glenn Jones's microformatshiv gets that result currently, and it would be easier for him (Calli) to implement this way.
** +1 Tantek, seems reasonable and the reasoning provided is good (we have one implementation this way already)
** +1 Kyle, this is consistent with the resolution to the related issue
** +1 Calli, yes, this is easier for me to implement (than taking both MF1 and MF2 properties) because it is consistent - for me, consistency is the controlling factor in favor rather than ease of parser implementation
** ...
</div>

Another example:

<source lang=html4strict>
<div class="vcard">
<div class="adr h-custom">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-custom"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

Per the [[#any_h-_root_class_name_overrides_and_stops_backcompat_root]] resolution, the class name "h-custom" overrides the use of "adr" as a backcompat root.

=== default generated HTML ===
2015-09-08 raised by Tantek in #indiewebcamp

Should there be a default (perhaps not quite "canonical") way to map/generate HTML+microformats2 from a parsed mf2 JSON output?

E.g. straw proposal:
* JSON/mf2 -> [[XOXO]]+mf2

Existing work / mappings:
* https://github.com/snarfed/granary/blob/master/granary/microformats2.py#L295

Related to:
* https://github.com/snarfed/granary/issues/31

Use-cases:
* default webview / presentation for a site that stores mf2 JSON output
* possibly a way to implement a distributed HTTP webcache retrieval protocol

Thoughts?
<div class="discussion">
* +1 [[User:Tantek|Tantek]] I think we should have this, but am open to proposals on specifics!
* +1 [[User:GlennJones|Glenn]] Also think this is worth looking at, but I am not sure it should be part of the parser spec. Feels like it should be built as a separate library and have it own spec on the microformats wiki.
* ...
</div>

=== Noscript skip/parse ===
2015-07-28

Should mf parsers skip <code><noscript></code> tag in the HTML, like the <code><template></code> tag mentioned in http://microformats.org/wiki/microformats2-parsing#note_HTML_parsing_rules ?

mf2py skips <code><noscript></code> when using the html5lib DOM parser but no when using lxml parser. Example use of <code><noscript></code> https://kartikprabhu.com/ featured images have a no javascript fallback image inside <code><noscript></code> with <code>class='u-featured'</code> markup.
* html5lib actually HTML-escapes the contents of <code><noscript></code>, so to mf2py it just looks like plain text with no tags. In Woodwind, I've resorted to using regex to strip out <code><noscript></code> tags before parsing (very hacky). [[User:Kylewm|Kylewm]] 15:52, 25 August 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] skip noscript (and inside) because in today's typical browsing contexts, nothing in noscript is displayed, thus we should discourage marking up effectively invisible content.
** Proposed change to [[microformats2-parsing#parse_a_document_for_microformats]]:
*** from: "follow the HTML parsing rules"
*** to: "follow the HTML parsing rules (including skipping/omitting <code><noscript></code> elements, e.g. like the html5lib DOM parser)
* -1 [[User:GlennJones|Glenn]] This subject does need to be address, but differently to proposed change. My personal view is that e-* html should be passed through raw and then the consumer can process it in a way they feel fit. Its a case for helper libraries. I am about to build a helper library to do this based on the Readability code to post process e-* html. Other people may want to take different approaches, defining this in the spec feels like move into a whole area of new functionally.

As a separate new point we need to consider "exclude tags" lists for parsed text from html. We should consider <code><noscript></code>, <code><noframe></code> and <code><template></code> there maybe other I have not gone through all the tags in current HTML spec. Also we should consider what to do about the more common pattern of fallback text within media tags <code><video></code>, <code><audio></code> etc. This should be explicitly discussed in the parsing rules. At the moment my experimental text normalisation does exclude tags, but the default text parse does not. Currently the fallback content in media tags like <code><video></code> is added to the parse text. 12:56, 25 Septemeber 2015 (UTC)
* ...
</div>

=== Standard datetime format ===
2015-07-28

http://microformats.org/wiki/microformats2-parsing#parsing_a_dt-_property does not specify any standard format to use for datetimes. e.g. <pre>2015-07-28T12:55:33</pre> vs <pre>2015-07-28 12:55:33</pre>
Would be good to standardize this to compare various parser outputs.

2015-07-29: This subject is (somewhat) covered in http://microformats.org/wiki/iso-8601 As it stands the JavaScript parsers support output in the 3 main profiles, 'W3C Note', 'RFC 3339' and 'HTML5' plus 'auto' which keeps authors format. The default date output for the JavaScript parsers is the same format as the date was originally authored in. This can be changes by setting the options.dateFormat switch to any of the other profiles mentioned. It would be good if other parser also had a switch to force output to a common profiles so we could compare various parser outputs, but I think the default should be how a date was authored. All output whatever profile should also keeps the authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string. This is important if you want to compare parser outputs.

The only exception to this where date and times are combined such as the implied h-event rule for dt-start and dt-end where I output in the HTML5 style 2015-07-29 12:55:33 as there is no predefined author preference and HTML5 profile is more human readable. [[User:GlennJones|Glenn Jones]] 11:02, 29 July 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] output more human readable <code>2015-07-28 12:55:33</code> canonically, with authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string.
** Let's update any test cases as needed for this. - [[User:Tantek|Tantek]]
* ...
</div>

=== implied date for dt properties both mf2 and backcompat ===
The [[value-class-pattern#microformats2_parsers|value class pattern dt-* date proposal]] should apply to both mf2 dt-* properties, and backcompat classic microformats, to preserve the hAtom / hCalendar optimizations noted on that page, but in a generic way.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] 16:12, 18 August 2015 (UTC)
* +1 [[User:Glenn Jones|Glenn Jones]] 20 August 2015
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== implied properties when an explicit class is provided ===
<div class="discussion">
Should "u-url" still be implied if another explicit class is already provided, as below. This is a contrived example, but it is taken from Bridgy's unit tests.

<code><pre>
<article class="h-entry">
<a class="u-like-of" href="http://orig.domain/baz">liked this</a>
</article>
</pre></code>

In this case, http://orig.domain/baz is almost certainly not the u-url, so IMO it would be better to leave it out —[[User:Kylewm|Kylewm]] 15:10, 7 October 2014 (UTC)

'''2015-01-20 consensus'''
* Changed my mind. Simpler to do nothing. Example provided is artificially constructed, does not reflect likely real world confusion of if we make implied properties more complicated. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
* ++ Consensus on do nothing for this case. At [[2015-01-20]]

'''Proposed resolution:'''
* Changed again. Due to indiewebcamp.com/edit use-case, this now makes sense for all implied properties. That is:
** If an element has any explicit property class name(s) on it, then it must not be used to imply any properties. [[User:Tantek|Tantek]] 20:50, 27 May 2015 (UTC)
*** +1 this seems reasonable, if a publisher is going to add an mf2 class, it is unlikely they want other classes automatically implied from the same value [[User:Aaronpk|Aaronpk]] 23:19, 29 November 2015 (UTC)
*** -1 for now. To my knowledge, this has only been observed in artificially constructed unit tests and examples, and it adds some weird edge cases that are hard to reason about. [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** ... provide input on this proposal here
** Refined: Or should this be refined by per parsing prefix? [[User:Tantek|Tantek]] 22:59, 18 September 2015 (UTC)
*** Any explicit "p-*" property means no implied "p-name" from that element
*** Any explicit "u-*" property means no implied "u-url" nor "u-photo" from that element.
*** ... provide input on this refined proposal here
** Suggestion: split this issue up per property. I think it makes sense for u-url and can be easily added to the spec as e.g. ".h-x>a[href]:only-of-type:not[.h-*<strong>,.u-*</strong>]". [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** Obviously wrong to assume a link explicitly pointing elsewhere is our "url"
*** More difficult to make a case for photo and especially for name.
*** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
*** ... provide input on this refined proposal here
</div>

=== whitespace collapsing revisited ===
2015-05-27: (raised by [[User:Kevin Marks|Kevin Marks]] per Glenn Jones)

Revising the microformats tests to conform to the "don't collapse whitespace" rule below reveals some non-intuitive cases.
preserving whitespace in addresses is somewhat defensible, but in an implied name it is often unhelpful, as it preserves non-user visible space there for authoring reasons.

For example:
[https://github.com/microformats/tests/commit/a325e0e9bc2089507e69b1883f7065a3316e07c2#diff-d577012c1438978a571c4049179607f0 this test] shows how extraneous whitespace ends up in the <code>name</code>

<code><pre>
<div class="h-review-aggregate">
<div class="p-item h-event">
<h3 class="p-name">Fullfrontal</h3>
<p class="p-description">A one day JavaScript Conference held in Brighton</p>
<p><time class="dt-start" datetime="2012-11-09">9th November 2012</time></p>
</div>

<p class="p-rating">
<span class="p-average value">9.9</span> out of
<span class="p-best">10</span>
based on <span class="p-count">62</span> reviews
</p>
</div>
</pre></code>

give a parsed result of:

<code><pre>
{
"items": [{
"type": ["h-review-aggregate"],
"properties": {
"item": [{
"value": "Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012",
"type": ["h-event"],
"properties": {
"name": ["Fullfrontal"],
"description": ["A one day JavaScript Conference held in Brighton"],
"start": ["2012-11-09"]
}
}],
"rating": ["9.9"],
"average": ["9.9"],
"best": ["10"],
"count": ["62"],
"name": ["Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012\n\n\n9.9 out of \n 10 \n based on 62 reviews"]
}
}],
"rels": {}
}
</pre></code>

The <code>value</code> is a reasonable textual representation of the event, but the implied <code>name</code> is full of spurious whitespace that any consumer would have to strip.

[https://github.com/microformats/tests/commit/4c9690b53b0a2f40440abac8e609c51ac7dd6d56 h-review] has similar issues

2015-05-28: (Addition by [[User:GlennJones|Glenn Jones]])

The example below shows the type of markup most effected by the "implied name" and "don't collapse whitespace" rule working together to produce output that is hard to use without further processing.

<code><pre>
<a class="h-card" href="http://glennjones.net">
<span class="p-given-name">Glenn</span>
<span class="p-family-name">Jones</span>
</a>
</pre></code>

The output for the name property from the above HTML would be <code>Glenn\r\n Jones</code> using the (trim lead/trailing) suggested in the parsing spec. I could of course move the spans onto one line, but it feels fragile to consider whitespace sensitivity in HTML like this. Added to the fact that HTML templating environments often take away that level of whitespace control from authors anyway.

There are issues with both: keeping whitespace, returns and tabs from parsed HTML or collapse that whitespace. If we return the whitespace it becomes mal-formatted for humans because it was only added to make the HTML code understandable and in most cases was not meant to be used/read outside of that context. If we collapse the whitespace we can have issues of whitespace sensitive text from <code><pre></code> etc. being incorrectly formatted.

Providing a CSS aware innerText feature would produce the most useable output, but this is too complex/time consuming to build for most parser developers. In the face of no perfect solution I have taken the 80:20 view, whereby errant whitespace, causes me considerably more problems than mal-formatted <code><pre></code> content so I collapse whitespace on all text returned.

This feature is a non-CSS aware version of innerText. It does not cover all rendering edge cases, but enough to produce practical output.

For now, I have started changing the node parser to flag "white-space collapsing" as an experimental feature which is off by default i.e. http://glennjones.net/tools/microformats/ but personally I will parse everything with this on as I find it the most practical solution.

Not sure where that leaves me on the options below.

Options:

Choose from:
# keep as is and every parser client has to post process for common cases.
# '''keep as is but have mf2 parser trim leading/trailing whitespace (likely to provide desired result and be reasonably backcompat)'''
#* +1 my preference of the two options. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
#* +1 though this doesn't solve any of the problems discussed above, it's still worth doing [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
#* +1 will help parsers be more consistent with each other, and I haven't ever encountered a case where preserving leading/trailing whitespace was desirable [[User:Kylewm|Kylewm]] 20:45, 8 June 2015 (UTC)

2015-06-08 option 2 resolved by consensus and implementation in mf2py.

Somewhat orthogonal:
* make <code>value</code> on properties with children normalise whitespace
** -1 Seems like a bad idea as this "value" is supposed to be the same as if there was no embedded child microformat. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
* make implied <code>name</code> normalise whitespace.
** +0 This is reasonable and already done somewhat in the parsing spec (trim lead/trailing). [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** +1 Given the universality of name, this would fix most of the issues we see. [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
* Put \n in textual forms if there is a <code><p></code> tag in the original.
** -1 that's a long path to go down with whitespace equivalents for HTML markup. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** would only preserving whitespace if in <pre> be an 80:20 compromise? [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)

Because there are both code markup and specific vocabulary (label) needs for preserving whitespace, we are compelled to preserve in general, perhaps except for very specific limited generic cases (e.g. trim leading/trailing, "value" parsing, implied name). [[User:Tantek|Tantek]]

=== u- parsing iframe src ===
Currently if I put u-* on an iframe it gets the value of the fallback text. This seems a shame. Getting the URL seems a sensible answer.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== i- parsing iframe src ===

More controversially, what about using an iframe for transclusion? A use case here is comments on a static site. Currently, on eg http://www.kevinmarks.com/microformatschema.html the comments are injected via JS, making them opaque to parsers and thus precluding further parsing such as salmentions.

If instead they were an iframe embedding them, a parser could optionally fetch its contents, parse them, and include them in the parsed mf2 output at that point. Overloading u-* for this seems wrong; e-* as below for srcdoc would have a different effect; this implies a new prefix directive would be needed. A strawman i-* (for include) may work.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== e- parsing iframe srcdoc ===
<div class="discussion">
* Proposal: addition of a new e-* parsing rule for iframe elements with srcdoc attributes. E.G.

<source lang="html4strict">
<div class="h-entry">
<iframe class="e-content" srcdoc="<p>A paragraph of HTML with "quoted quotes" &amp; doubly quoted ampersands</p>" />
</div>
</source>
<source lang="javascript">
{
"items": [{
"type": ["h-entry"],
"properties": {
"content": ["<p>A paragraph of HTML with "quoted quotes" & doubly quoted ampersands</p>"]
}
}]
}
</source>

This would allow, for example, HTML comments to be sandboxed inside iframes but still parsable as microformats.

I believe the correct processing would be to leave " entities as they are but to unescape any doubly-escaped ampersands.

** Is there any use case for that? —[[User:TomMorris|Tom Morris]] 12:32, 14 September 2013 (UTC)
** +1 we need documentation of use case and existing sites publishing iframe srcdoc like this - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
** Rejected by consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 properties on select ===
How should select elements with properties be treated any differently?

Awaiting real world examples / stronger use-cases, until then no special treatment of select elements with properties:
<div class="discussion">
* Are there any real world examples of select elements with microformats properties?
* What would the use-case be for putting a microformats property class name on a select element?
* Nothing special. By consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 root name on form ===
See what to do about <em>root class names</em> on <code><form></code> elements in particular:
* [[hcard-input]]

Awaiting real world examples / stronger use-cases, until then, no special treatment of root class names on <code><form></code> elements:
<div class="discussion">
* Are there any real world examples of a <code><form></code> element with a microformats root class name?
* [[hcard-input]] is one possible use-case, is anyone attempting to use forms for hCard input, e.g. with scripts to help make it work?
* Are there other use-cases for putting a microformats root class name on a <code><form></code> element?
* As of [[2015-01-20]] - no consensus - need more input as to when/why this is useful to do anything special.
</div>

===Parsing Literal Values===
Issue raised by: [[User:BenWard|Ben Ward]]

It is proposed for microformats2 that all microformats be parsable from just their root element, e.g. <code><p class="h-card">Ben Ward</p></code> would create an hCard with the following properties after parsing:

<source lang=javascript>
{
'type': ['h-card'],
'properties': {
'name': ['Ben Ward']
}
}
</source>

This is a four-fold change from the current [[hCard]]:
# type is generically identifiable as a microformat root, even in parsed form. The use of the 'h-' prefix persists into the type of the object. This is deliberately so, as a result of re-using the JSON data model of microdata which itself is re-using a common JSON convention, such that microformatted data is clearly distinguishable (as opposed to any other random schema that may be using a similar data model).
# root-class-only support. Per [[microformats-2-implied-properties]], the ''name'' property is implied by the entirety of the root class name element.
# 'name' instead of 'fn'. As also documented in [[microformats-2-implied-properties]], the continuous challenges/problems and need to repeatedly re-explain 'fn' over the years combined with the real-world market response of nearly every other party doing a person vocabulary renaming 'fn' to 'name', microformats 2 makes this change as well.
# There is no automatic parse-time inferring of <code>'given-name': ['Ben']</code> and <code>'family-name': ['Ward']</code>. Any such inferring *might* be made by a vCard converter, but is left up to that specific application (not all applications) built on that vocabulary, though even in that case it may not be necessary, as an empty "N:;;;" [[vCard]] property is sufficient to satisfy the N property requirement of [[vCard]], and also causes no problems when imported into various [[vcard-implementations]].

It is required of the extractor to understand that when a microformats object specifies no explicit child properties, that it must treat <code>h-card</code> as having a <code>p-name</code>. But, the parser is generic, so it also treats <code>h-review</code>, <code>h-entry</code>, <code>h-recipe</code>, <code>h-geo</code> as having a ‘<code>p-name</code>’.

As a result, specific vocabularies are evolved to drop their specific form of name (e.g. fn, summary, entry-title) and simplified to use a common 'name' property instead.

Note: while the overwhelming majority of real world publishing/consuming uses of microformats do so with proper nouns which have names (and thus this parser-level incorporation of an implied 'name'), there are some formats that do not have a 'name' semantic. For example, [[geo]], [[adr]], and possibly if/when developed, units of measure, length, cost. The current thinking is that the benefits to the far greater proper-noun use-case of microformats outweigh the technical inelegance of having an extra/ignored 'name' property on formats that lack such a semantic.

Some formats also may appear in theory to better imply some other property, e.g. a review might be thought to imply its ''content'', not its name, and an Atom entry its ''content'', not its title, but in practice (actual publishing patterns) this is not the case. Typically, brief unstructured reviews (or mentions thereof) provide a ''summary'' (often hyperlinked to an expanded structured form) of that review, not its content, and similarly, brief unstructured posts (e.g. RSS items) have historically most often been link blog items which include the title of an item and a link. Short status updates as well established by Twitter are newer and would seem to imply purely content with no title, at least semantically, however, even Twitter populates the RSS title and ATOM entry title of their feeds with the content. It's not clear what went into that decision, however, that's likely irrelevant, as the outcome turns out to be emergent consistency among publishing behaviors.

To avoid overloading or undermining the semantics of a vocabulary, I propose that we handle this at the extractor level in a simpler fashion: Define a new property for literal data, that an extractor will provide if no other information was available. All ''interpreters'' may then be instructed that in the event that an object has no properties, it can attempt to interpret the literal value from the page instead.

* This was one of the design iterations I went through which led me to the current implied 'name' design. Another iteration was the ability for a vocabulary to specify a single required property which was implied if there were no properties provided. However, the combination of the fact that in most cases such single required properties were quite name-like, and that a vocabulary-specific rule like that would then bind parsers to specific vocabularies (even so slightly) led me to collapse them into implying a 'name'. It's not perfect, but it's the best alternative so far that balances practical convenience of publishing/consuming, avoids vocabulary-specific knowledge in the parser, and technical (in)elegance. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

In existing microformats, the closest existing example we have for this is the <code>label</code> property in hCard, which is used to represent the literal address label for a place. It is a corresponding piece of <code>fn</code>, <code>org</code> and <code>adr</code> in combination, but has no structure in and of itself. Possibly, every microformat could have a <code>label</code> form where structured data is unavailable.

However in practice, the hCard <code>label</code> property is both little understood and little used. It's not even clear that it ought to be kept for microformats 2 (no known consumers, very few (if any?) real-world non-test publishers). This disuse is likely a good indicator that we should avoid basing anything on its design.

Alternatively, <code>value</code> is used throughout microformats to target a generic value (e.g. in combination with <code>price</code> in hListing.) It has been proposed that when parsing properties that are also themselves microformats, we create native objects of the form:

{
'value': '1900 12th Street, San Francisco, CA 94'
, 'type': ['h-adr']
, 'properties': {
'street-address': '1900 12th Street'
, 'etc': 'etc'
}
}

We could apply this same pattern to the root level:

{
type: [h-card]
, properties: {}
, value: 'Ben Ward'
}

In this case, an interpreter or implementation is responsible for using <code>value</code> in place of <code>fn</code>, or restructuring the object. It would be the responsibility of each vocabulary to define its root property. The parsing layer of microformats 2.0 would not impose semantics or naming onto that.

For another example, h-geo would end up like this:

{
type: [h-geo]
, properties: {}
, value: '1.3232;-0.543'
}

* This is an alternative I've been considering as well: [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)
** 'value' is more generic than 'name' (applies to more vocabularies) with the trade-off that it naturally has less (weaker) semantics.
*** +1 I think that having naturally weaker semantics would be appropriate for this parsing functionality. —[[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC)
** The interesting thing that this analysis has revealed is that there appear to be two distinct clusters of microformats, the much more commonly used/understood/useful proper-noun microformats which markup things with names (people, events, reviews, recipes), and the less used compound-data microformats which are often used ''inside'' other microformats and just have some sort of semi-structured value (adr, geo, measure, and perhaps even things like tel). Perhaps this is implying the possibility and some degree of utility for ''two'' microformats root class name prefixes, 'h-' for existing proper-noun microformats, and something else ('m-' for microformat/molecule?, 's-' for structured-value?, 'v-' for value (though historically "v-"/"v." has meant "vendor-specific")?) for unnamed structured data microformats.
*** This more and more feels like a good idea, and I'm leaning toward "s-" for struct / structure / structured value. "s-" works just like "h-" except that it doesn't imply any properties at parse time. We can try it and see what happens. There's also no harm if publishers just use "h-" structures, they just (possibly) get a few extra properties if they happen to omit properties.
** Parallels the same JSON when a property has both a string value ''and'' is a structure itself.
*** Changed my mind on this. The parallel is not quite there. 'name'/'url'/'photo' are only implied if there are NO properties, where as the JSON string value + structure convention *always* provides a 'value'. [[User:Tantek|Tantek]] 22:39, 4 October 2011 (UTC)
*** And due to this difference in behavior ('value' is there when nested properties are present, whereas 'name' is only implied when there are no properties specified), I think it's correct to keep them separate, i.e. stick with implied 'name'. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
** However, I'm still currently leaning towards the practical convenience of providing a 'name' for the vast majority of microformats uses, rather than diluting this feature for the sake of avoiding implying inapplicable semantics to the few plain structured data microformats, and even then, only when no properties are explicitly specified! I'd rather introduce a new root prefix for those than lose the simplicity and utility of implied 'name'. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

== resolved ==
=== When to collapse whitespace in properties ===

The spec doesn’t explicitly require whitespace to be collapsed or not. The official mf2 test suite requires it to be collapsed.

Reasons why whitespace ''shouldn’t'' be collapsed:
* Plaintext property representations of syntax-highlighted code, poetry and song lyrics require whitespace to be present
* Whether or not whitespace is an important part of the content being parsed is determined by css white-space and CANNOT be inferred from HTML markup alone

Resolution 2013-11-12: Agreed, whitespace should not be collapsed (other than normal HTML5 parsing rules). The spec now refers to "textContent" rather than "innertext" to make this explicit.

=== How to interpret mf2 classnames on form inputs ===
E.G. how to parse:

<source lang=html4strict>
<input class="u-url" value="https://brennannovak.com/notes/338" />
</source>

Examples in the wild: https://brennannovak.com/notes/338

See proposal:
* [[hcard-parsing-brainstorming#input_element_handling]]

Resolution 2013-11-12: Per that proposal, p- u- dt- properties on input[value] elements now use the value attribute.

=== mixture of microformats2 and classic microformats classnames on different elements ===
Some sites in the wild have mistakenly combined classic mf and mf2 markup in ways which misrepresent the content if parsed in BC mode.

Typically this is caused by putting classic and mf2 classnames for the same vocabulary on different elements, e.g:

<source lang="html4strict">
<body class="hentry">
<article class="h-entry">
<h1 class="p-name"></h1>
</article>
</body>
</source>

Sites where this has been observed:
* http://acegiak.machinespirit.net/2013/10/17/barnaby-walters-notes-another-thing-i-love-about-the-web-users-have-the-power-to-take-control-of-their-uis-and-improve-their-own-experiences-aside-drm-for-html-would-prevent-this-from-being-possibl/
* http://shawfactor.com/2013/08/06/thoughts-on-extending-webmentions/ (fixed)
* http://notizblog.org/2013/06/18/the-rise-of-the-indieweb/ (fixed)

Discussion:

* As far as I can tell, the problems in all of these examples were caused by mf2 markup being injected by a wordpress plugin, but classic mf classnames being present further up the DOM in the themes. When parsed in compatibility mode, the classic mf classnames are transformed into mf2 classnames, making the original mf2 classnames look like children of empty items.
* Turns out this isn’t theme-specific, WordPress injects hentry via PHP [http://indiewebcamp.com/irc/2013-10-22/line/1382448759]. The bug with the wordpress mf2 plugin is resolved as of [http://indiewebcamp.com/irc/2013-10-22/line/1382449035 2013-10-22] --[[User:Barnabywalters|bw]] 13:38, 22 October 2013 (UTC)

=== e- and p- escaping levels ===
<div class="discussion">
* The fact that the parsed value of any element with .e-* is at a different level of escaping to the parsed values of p-*, dt-* etc. without any indication of how the property was parsed in the output is a security problem. For example:

<table style="width: 100%">
<tr>
<th>input</th>
<th>output</th>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="p-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="e-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
</table>

* As a parser developer, the most straightforward way I can think of solving this is to add an option (enabled by default) which encodes HTML special characters on all non e-* properties, so the developer knows that all property values are going to be at the same level of escaping. --[[User:Barnabywalters|bw]] 20:00, 15 June 2013 (UTC)
** Your suggestion of auto-HTML-encoding p-*/u-*/dt-* property values is the most sensible I think. I would NOT make it an option, as it makes sense write consistent microformats2 consumers. - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
** Can you think of any existing apps/consumers of microformats2 via the parser that would break? What would indieweb comments parsers do? - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
*** The only breakage which might occur would be over-encoding of non e-* properties, but I’ll release this update as v0.2.0 and warn people about the changes. The worst thing which could happen is that some comments look a bit weird, as opposed to the current worst possible scenario of easy XSS attacks --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** We should also decide exactly which characters get encoded — just angle brackets, or quotes/ampersands as well? --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** I am not sure about this, it seems more like a helper function rather than a core feature of the parser. Personally I would like to store data as text and encode only when I am going to use and I known the format it is going to be use in. --[[User:GlennJones|Glenn Jones]] 9:54, 14 July 2013 (UTC)
***After the discussion on the indiewebcamp IRC with Barnaby Walters I now understand the XSS issue that this change is trying to address. A rogue author could include HTML with scripts to execute a XSS attack. These could be masked by switch prefixes i.e. p-* to e-* on a well use property. As the consumer does not see the prefix in the JSON output they have no idea if a property will content HTML or text. I will update my two parsers and the test suite --[[User:GlennJones|Glenn Jones]] 8:02, 17 July 2013 (UTC)
**So what about an author setting a property to e-* when it would normal be p-*, dt-* or u-* i.e.
<source lang=html4strict>
<div class="h-card"><p class="e-name"><script> alert('xss test') </script></p></div>
</source>
** per [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]], parsers should never automatically attempt to HTML-special-characters encode - as that would provide the client of the parser a false sense of security. It's *always* up to client code to escape any text being output to HTML *at the moment it is output to HTML* and never before, because they can never trust that any text from storage/elsewhere has for sure been escaped or not. - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** Should we not encode e-* as well and the consumer can decode at their own risk --[[User:GlennJones|Glenn Jones]] 18:42, 21 July 2013 (UTC)
*** No, never, per above point from [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** See [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] etherpad: https://etherpad.mozilla.org/microformats2parsing for more details on the resolution to this issue - and incorporate here (then move to resolved section below). - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
* Resolved by changes to the parsing spec: all properties are plaintext (non-HTML escaped), e-* properties result in a dictionary with <code>value</code> = plaintext version, <code>html</code> = raw HTML version
----

</div>

=== br hr empty string ===
<div class="discussion">
* The parsing rule 'else if br.p-x or hr.p-x, then return "" (empty string)' for p-* can cause any code consuming the API to become quite bloated. It means that you have test every array value to see if its an empty string. It is also unclear to me what the purpose of this mark-up pattern is for [[User:GlennJones|Glenn Jones]]
** Upon reconsidering this, I agree with you, this is an unlikely use case. If a publisher wants to explicitly set an empty property "p-foo" they can simply write <code><span class="p-foo"></span></code> which looks explicit. Whereas BR and HR tags are often just presentational, so we should both not encourage usage of them for semantics, and anyone that did use them would be subject to likely loss of semantics upon a redesign (that got rid of those particular BR and HR tags). I'm going to remove them from the parsing spec. - [[User:Tantek|Tantek]] 15:29, 10 February 2013 (UTC)
</div>

=== datetime examples without T delimiter ===
<div class="discussion">
* The examples in the wiki microformats-2 pages such h-entry and h-entry had datetime without the 'T' delimiter between date and time. ie
<source lang="html4strict">
<time class="dt-published" datetime="2013-06-13 12:00:00">13<sup>th</sup> June 2013</time>
</source>
I have updated the pages. As far as I known this is a new pattern for dates. Was it a mistake in the examples or is it a new datetime pattern.
** The [[HTML5]] "time" element, and "datetime" attribute allow for space <span style="white-space:nowrap">" "</span> as a separator between date and time as well as "T", thus we allow it for microformats as well. The <span style="white-space:nowrap">" "</span> separator is preferred as the date and time are more readable when separated by a space. The examples noted in those specs deliberately use this. - [[User:Tantek|Tantek]] 18:48, 15 July 2013 (UTC)
</div>

=== rel-alternate absent optional attributes ===
<div class="discussion">
* What should rel-alternate parsing do when one of the optional attributes specified (<kbd>hreflang</kbd> or <kbd>media</kbd> or both) is not there? The options seem to be:
*# leave the corresponding key out of the alternate JSON object
*#* This one. Leave the corresponding key out.
*# include the corresponding key in the alternate JSON object, but set the value to the JSON null object
*# include the corresponding key in the alternate JSON object, but set the value to a blank string
*# something I haven't thought of

I haven't checked the existing implementations, but Barnaby said he's not sure what the appropriate way to deal with it is either. —[[User:TomMorris|Tom Morris]] 15:41, 9 August 2013 (UTC)
</div>

=== rel-alternate and type attribute ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Should rel-alternate parsing also pick up the <code>type</code> attribute? It’s fairly widely used, e.g. for ATOM feeds.
** Numerous existing sites/pages have various [[rel-alternate]] uses with a type attribute for feeds/APIs so that's good enough to add this for help with discovery in general. Rel parsing updated. - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
</div>

=== Extraction vs Interpretation ===
Issue raised by: [[User:BenWard|Ben Ward]]

A microformats ‘1.0’ parser performs the following function:

* Given a piece of HTML content, discover a known microformat, extract it, apply various extraction patterns based upon the HTML mark-up used (e.g. include pattern, <code>abbr</code> patterns, date-time patterns, value-title pattern), apply various content optimisations where applicable, and return the result in an object native to the programming language.

This is performing two types of function: Extraction of data from an HTML document or fragment, ''and'' interpretation and optimisation of that content to match the rules set out by a vocabulary specification.

It is only possible to write a generic parser that covers the first half of this task: Extraction, and application of global rules based on HTML elements and patterns common to all formats.

The purpose of a generic parser (as supported by use cases such as search engines, and other crawlers) is:

To provide a way for tools to extract rich data from a page for native storage, such that the data may be interpreted later by applications. This allows microformats to be crawled, and indexed, and removes the need to include complex HTML parsing within every implementation of microformat data.

Microformats will continue to define various vocabulary-specific optimisations. as part of the design to be optimised for authors. For example: The <code>fn</code> pattern in [[hcard]], or the <code>lat;long</code> pattern in [[geo]], as well as default values for properties, such as the maximum rating in an [[hreview]].
* Actually, no, as it is defined currently, microformats 2 ''drops'' vocabulary-specific optimizations. Such optimizations have often been too inapplicable, error prone or i18n-unsafe (e.g. fn to given-name + family-name fails for both numerous cases where middlenames/initials are used, and in general in numerous Asian languages where given/family name order is the reverse of Western English conventions, or languages with multiple family-names, e.g. Spanish - see [[hcard-issues-resolved]] for more). This is a deliberate cutting of a "feature" from microformats 1, it is a deliberate model simplification design decision. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

==== Extraction resolution ====
Proposed resolution:

Microformats2 should refer only to ''extraction'' of microformats. Vocabularies should in turn document their appropriate optimisations, which will need to be applied by implementations, or a companion to an extractor, which I'll refer to here as an ‘interpreter’.
* Vocabularies will no longer have optimizations, this is again deliberately, as they've been shown to be more error prone than helpful. Thus there should be no need for any vocabulary-specific 'interpreters'. However, due to design quirks in various legacy/interchange formats, ''export conversions algorithms'' to those legacy/interchange formats will require some additional legacy-format-specific rules (e.g. odd "required" rules in [[Atom]] or [[vCard]] will require specific synthesis rules, limitations in said formats will require filtering of some values, e.g. [[vcard3]] BDAY disallows vague birthdays like year-month and --month-day - subsequently allowed in [[vcard4]]). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

A microformats2 ‘extractor’, in combination with the functionality of a domain and format-aware ‘interpreter’ (either another shared component, or part of the implementation itself) would be equivalent to a microformats 1.0 ‘parser.’
* A microformats2 parser is both generic (no knowledge of specific vocabularies), and lacks any/all such vocabulary-specific rules as compared to a microformats 1.0 [[hcard-parsing|parser]] with the exception of a 1) a limited list of well-established/interoperable backward compat root class names (of current [[microformats]] that are or can be soon shown to be specifications/standards per the [[process]]), 2) flat sets of backward compat property names (some with prefix/name specific conversion) for each of those backward compat root class names. This is a deliberate design decision that makes microformats 2 more "micro", and yes this means that even with such backward compat support, this simple form of backward compat may mean that some existing microformats 1 content breaks. We'll assess those and iterate on a documented case-by-case basis rather than attempt to maintain theoretical 100% backward compatibility (since many current microformats format-specific-features are either unused, or may have caused more problems than solutions). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

N.B. I'll rewrite some of these as [[microformats2-parsing-faq]] to help better clarify. The reasoning that led to most of these design decisions is documented in the [[microformats-2#About_This_Brainstorm|microformats 2: About This Brainstorm]] section and following sections. I'll recheck those sections to see if/where reasoning for some of the above noted design decisions may have been missed, and back-fill accordingly. This is necessary because [[microformats2]] is a evolutionary result of simultaneously addressing both numerous generic [[issues]] as well as various common [[hcard-issues-resolved|format]]-[[hcalendar-issues-resolved|specific]] [[mfo|problems]] in microformats1 syntax and vocabularies. The very number of changes may make it more challenging (from a microformats1 perspective) to see why any particular design change has been made. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

This issue can be moved from resolved to closed once the above-mentioned write-ups have occurred.

===Parsing properties from rel attributes===
tl;dr resolution: As of 2013, [[microformats2-parsing]] handles parsing all link and a href rel values at document scope level, and producing canonical JSON accordingly. - [[User:Tantek|Tantek]]

Issue raised by [[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC):

* Currently, hAtom parses `bookmark` as a permalink
* Various microformats parse `rel=tag` as tags
* The current proposal for parsing does not allow parsing properties from rel attributes.

Microformats parsers could instead extract ''all'' link relationships from rel attributes within an microformat object, parsing them as if a u- prefixed property.
* Minor nit: Rather than same as a u- prefixed property, I think such "rel" properties should be parsed purely from the <code>href</code> attribute on <code><a></code> and <code><area></code> elements and nothing more. I would strongly disagree to extending rel to apply to other elements with URLs like img src, object data, or to apply to elements in general like div. That's the path that RDFa has taken and caused much confusion as a result. [[User:Tantek|Tantek]] 07:39, 5 October 2011 (UTC)
** Agree: That seems like a perfectly reasonable restriction. --[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)

This results in:

* Continuing use of the <code>rel</code> attribute in HTML, thereby building on HTML semantics rather than bypassing them or ignoring them in favour of something less meaningful.
* Parsing hAtom objects contain a property named <code>bookmark</code>, in place of <code>permalink</code>.
* All microformats that use <code>rel-tag</code> would contain a property named… <code>tag</code>. Perfect.

Since <code>rel</code> attributes are not overloaded for other functionality like class is, and other uses of <code>rel</code> within content are low (and non-semantic uses are nil, to the best of my knowledge) the risk of property pollution would be extremely low.

Note, with regard to this last point, that a generic microformats parser ''will'' parse false-positive properties, and ''will'' parse objects in combined chunks, rather than individually by format. Extracted objects will often not represent a vocabulary without further processing.

<div class="discussion">
* This sounds like it might be workable. Let's try it and see how well authors "get it". - [[User:Tantek|Tantek]]
* Possible issue: do we have any collisions between class property names and rel names? (I don't think so offhand, but useful to ask the question). - [[User:Tantek|Tantek]]
** None that I can think of in microformats. There is the case of Google's <code>rel=author</code> and <code>p-author</code> in hAtom. However, the next point, about mfo scoping, would cover it in most situations (rel-author on a hyperlink within an hcard wouldn't be applied to the hentry.) The one situation in a parse tree where it's ambiguous would be this:
<source lang=html4strict>
<a href="p-author h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
** I can think of two quite reasonable solutions:
*** 1. Declare that class properties take precedence over rel properties of the same name, discarding rel values if a class is also found, or
*** 2. Since all properties are now multi-value anyway, the hAtom object could be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
** —[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)
*** Option 2 makes sense and is consistent with the rest of the multi-value parsing/handling. - [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
*** What about without the 'p-author'?
<source lang=html4strict>
<a href="h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
Should that be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
Or
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': 'http://benward.me' /* from the rel="author" */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},

],
…
}
}
</source>
*** And if the former, then we're presumably saying that the value parsed due to the presence of a rel is always its own value, and does not combine with any other structures. I am fine with this, but I wanted to make sure we are ok with that explicitly. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
**** +1 I think that since the rel attribute is specifically concerned with the relation to an href attribute, it should not be combined with other structures that are rightly declared uses classes.
***** The more I've thought about this and how consuming applications may want to treat rel semantics, the more it seems correct to keep rel semantics distinct from class semantics. Class semantics are quite general/flexible, whereas rel is quite specific, naming something else in terms of a relationship from the current page/microformat's perspective. I think we should consider putting rel values in their own 'rel' collection, separate from the 'properties' collection. E.g. the original rel-author p-author h-card markup example would be parsed into this:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
}
],
…
}
'rel': {
'author': ['http://benward.me'] /* from the rel="author" */
}
}
</source>
***** and if a post had multiple authors:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from p-author */
'type': ['h-card'], /* from h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
{
'value': ['Tantek Çelik'], /* from 2nd p-author */
'type': ['h-card'], /* from 2nd h-card ... */
'properties': {
'name': ['Tantek Çelik'],
'url': ['http://tantek.com']
},
],
…
}
'rel': {
'author': [
'http://benward.me', /* from rel="author" */
'http://tantek.com' /* from 2nd rel="author" */
]
}
}
</source>
***** This preserves the semantic distinction between rel and properties in general, and leaves it up to a higher-level application to implement any logic around showing "more info" about a rel-author, e.g. by correlating the rel-author URL with the 'url' of an hCard it found in the same entry. However, note that even in the earlier JSON data model, the rel-author value just shows up as another property value, and any higher level application would still have to do some correlation logic. At least with this JSON data model, applications that may be looking for a rel value in particular, or a property value in particular can do so without having one unintentionally pollute the other. [[User:Tantek|Tantek]] 17:33, 6 October 2011 (UTC)

* Presumably we'd apply all the same property scoping rules to rel scoping as well. E.g. a rel hyperlink inside a microformat won't be seen by any containing microformat. - [[User:Tantek|Tantek]]
** Correct, it should be parsed in the same scope as all other class properties in the object.
*** Update: all rel microformats are now parsed at page-scope. Per-microformat scoping of rel has been found to be too confusing in practice (and against the general semantic of rel expressed in the HTML/HTML5 specs) [[User:Tantek|Tantek]] 01:00, 10 July 2014 (UTC)

This issue can be moved from resolved to closed once we've verified that all the above-mentioned and implied needs to write things up have occurred.
</div>

=== deduping of rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-02 by [[User:Kevin Marks|Kevin Marks]]
* 2015-06-05 resolved by consensus and one real world implementation proof of implementability and verification of expected results. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

Many sites have multiple duplicate rel links to the same url - a very common case is WordPress home pages eg [http://ma.tt ma.tt]

Each post on the page has a block like
<code><pre>
<div class="entry-meta">
<span class="date">
<a href="http://ma.tt/2015/05/beethoven-mozart-bach/"
title="Permalink to Beethoven, Mozart, Bach" rel="bookmark">
<time class="entry-date" datetime="2015-05-31T22:42:00+00:00">May 31, 2015</time></a></span>
<span class="categories-links">
<a href="http://ma.tt/category/asides/" rel="category tag">Asides</a></span>
<span class="author vcard">
<a class="url fn n" href="http://ma.tt/author/saxmatt/"
title="View all posts by Matt" rel="author">Matt</a></span>
</div></pre></code>

As currently defined, the parser will create duplicate entries in <code>rels</code> for each post:
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/",
"https://ma.tt/"
],
}
</pre></code>

and in the <code>rel-urls</code> we will also see:
<code><pre>
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author",
"author",
"author",
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home",
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag",
"category",
"tag",
"category",
"tag",
"category",
"tag"
],
"text": "Asides"
}
</pre></code>
These duplicates are unhelpful for parser consumers. We should:
* make them both sets - only listing distinct values. This will remove ordering information, but order is irrelevant for rel in html.
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/"
],
}
…
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag"
],
"text": "Asides"
}
</pre></code>

* possibly we could also make <code>title</code> <code>text</code> <code>type</code> sets too. That would solve the information loss issue with the current parsers
** Resolution: in the case of duplicate other attributes, first one set wins. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

<div class="discussion">
* +1 as the proposer. A version of mf2py that does this is running at unmung,com. see [http://www.unmung.com/mf2?url=https%3A%2F%2Fma.tt&html=&pretty=on fro ma.tt] or [http://www.unmung.com/?html=%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E&pretty=on a simple test] [[User:Kevin Marks|Kevin Marks]] 23:49, 2 June 2015 (UTC)
* +1 makes sense to me, and not having them be sets in the current spec is likely an oversight on my part. Thanks for noting this issue. [[User:Tantek|Tantek]] 05:28, 3 June 2015 (UTC)
</div>

=== include alternates in rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 resolved per consensus and one real world implementation proof of implementability. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* add "alternate" rels to the "rels" collection to make them easier to look-up in "rel-urls" - that is, all rel values end up in "rels" collections. No exceptions.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls".
* +1 This makes sense to me, as the <code>rels</code> and <code>rel-urls</code> should match so you can lookup in rels first, then get details about urls from rel-urls. We can drop "alternates" independently from this change. [[User:Kevin Marks|Kevin Marks]] 00:23, 2 June 2015 (UTC)
** +1 drop "alternates" independently now made a separate issue. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
* +1 Makes sense. And I agree with Kevin; I think parsers should deprecate "alternates" for now and drop it after a version cycle or two. [[User:Kylewm|Kylewm]] 00:30, 2 June 2015 (UTC)
* implemented in [https://github.com/kevinmarks/mf2py/commit/4dba45200eef11da811f64817d02044ab9e98b77 my fork of mf2py] and running on [http://www.unmung.com/?html=%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fa%22%3Eauthor+a%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fb%22%3Eauthor+b%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F1%22%3Epost+1%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F2%22%3Epost+2%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22alternate+home%22%0D%0A+++href%3D%22http%3A%2F%2Fexample.com%2Ffr%22%0D%0A+++media%3D%22handheld%22%0D%0A+++hreflang%3D%22fr%22%3EFrench+mobile+homepage%3C%2Fa%3E&pretty=on unmung] [[User:Kevin Marks|Kevin Marks]] 01:29, 2 June 2015 (UTC)
</div>

=== Empty properties overridden by implied rules against user expectation ===
Status: resolved, existing behavior correct, no changes to parsing spec.

2015-07-03: raised by [[User:Glenn Jones|Glenn Jones]]

Emma Kuo brought up an issue (https://github.com/glennjones/microformat-node/issues/22) based on following the indieweb note pattern, where the content of a note is given both the e-content and p-name classes. If the element containing the notes only has none text content like image the p-name can have unexpected value. Here is the example she gave:

<code><pre>
<div class="h-entry">
<a href="http://this.site/photo" class="u-url"></a>
<div class="e-content p-name"><img src="photo.jpg" class="u-photo"/></div>
Some extraneous text
<div class="h-cite">
<a href="http://someother.site/like" class="u-url"></a>
<a href="http://this.site/photo" class="u-like-of"></a>
<div class="e-content p-name">liked this</div>
</div>
</div>
</pre></code>

At the moment I parser this as follows: - if a property (p-name) is empty do not add it to the output. In this case "empty" is classed as not containing any non-whitespace text. As far as I known there is no guidance on how to handle "empty" properties in microformats paring rules, so I followed the conventions of JSON API's not to return "empty" properties.

The side effect of the above is that p-name also has a number of "implied rules". The "implied rules" try to automatically fill properties like p-name if there is no defined value. In the example above it uses the textContent of the parent h-entry, so value of the h-entry>p-name is the text content of the h-cite i.e. "likes this".

Options:

1. We should not allow the "implied name rule" to get textContent from within a child h-*
<div class="discussion">
* <strike>+1 I believe this is inline with how we parse properties and will meet user/author expectations [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* -1 A nested h-* is still part of the content of the parent h-*, I don't quite understand the rationale for excluding it. For example, I may include lots of h-cards in the body of a post that references people and wouldn't want them to be excluded from the implied name generation. [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* -1 I'm not sure this would solve the problem because auto-filled text could come from the parent h-* ("some extraneous text" in the example above) [[User:emmak|Emma Kuo]] 20:50, 4 July 2015 (UTC)
* -1 I agree with the other -1s. This would break some of the simplicity of the model. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
</div>
2. We should not execute the "implied rules" where there is an author defined "empty" property.
<div class="discussion">
* <strike>-1 Although the output would meet author expectations it is complex for parsers as they will have to keep state for each property through the whole series of parsing rules. [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* +1 An explicit, empty, p-name property should prevent an implicit p-name from being generated. For example tantek.com includes <span class="p-name"></span> at the start of the h-feed to prevent a giant name from being auto-generated. From my reading of the parsing spec, I don't see any reason that blank strings should be excluded from parsing. (mf2py and php-mf2 will both happily include empty strings in their output) [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* +1 We already have interop on this between mf2py and phpmf2, as well as people depending on it to explicitly set empty property values. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
* +1 As we already have interop with two parsers and solid user issue from Emma we should take this approach. [[User:GlennJones|Glenn Jones]] 11:51, 29 July 2015 (UTC)</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== uf2 children inside a classic microformats root class name ===
Status: incorporated into [[microformats2-parsing]]

2015-020: (raised by kylewm) What should microformats2 children inside a classic microformats root class name do?

Options:

1. Nothing. Any unattached uf2 children inside a classic microformats root are ignored. Problems:
<div class="discussion">
* However then there's a possible surprise if/when the author upgrades the classic microformats root to uf2, then all of a sudden all the new uf2 children show-up.
* Another downside: author adds uf2 markup, can't figure out why nothing is happening (because somewhere up the tree in code they didn't touch is classic microformats that are hiding these unattached uf2 children.
</div>
2. Show up in the children collection of the classic microformats root
<div class="discussion">
* Feels most predictable. When you add uf2 root class names anywhere, they will show up in the JSON output hierarchy.
* When you convert ancestor class microformats root class names to uf2 root class names, no surprise in terms of which microformats show up. Same children collection.
* +1 Thus I'm leaning towards this one, despite the fact that classic microformats never had a concept of generic unattached children. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)
* +1 I think this is the best option I will implement it and update the wiki once its in the JavaScript parser. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>
3. Show up as peers to the classic microformats root. Issue(s)
<div class="discussion">
* Has ths surprise aspect of if/when you convert the classic root class name to a uf2 root class name, the former peers become unattached children.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== any h- root class name overrides and stops backcompat root ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: The presence of any h-* root class name overrides and stop any backcompat parsing of classic microformats root class names on that same element. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for restricting backcompat root class name to only seeing backcompat property class names
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
* I don't think I understand this rule. If I was stop all parsing of of classic microformats in the presence of any h-* root in a document then some of the other rules such as "uf2 children inside a classic microformats root class name" do not make sense. Could this item be expanded and explained a bit more? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** added "on that same element" as that was what we were discussing/implying in this issue. [[User:Tantek|Tantek]] 22:49, 18 September 2015 (UTC)
</div>

=== backcompat classic microformats should only see backcompat properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats vocabulary that indicates a backcompat root class name (and thus an absence of the microformats2 equivalent on the same element), parsers must only look for the backcompat properties that are specified explicitly for that backcompat root class.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such behaviour was never expected by authors, and crossing a classic microformats root class name with microformats2 property names were never explicitly expected nor specified to work.

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== microformats2 root class names should only see microformats2 properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats2 root class name, only explicit microformats2 properties should be parsed. Any backcompat property names must be ignored.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such microformats2 authors should be expected to do all their microformats markup with microformats2 class names - this is a deliberate expectation so that their microformats aren't polluted with other (classic microformats) coincidentally named generic class names.

Thoughts?
<div class="discussion">
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== implied properties on backcompat parsing unlikely to be intended ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
Since classic microformats had no notion of implied properties, when implied property parsing occurs on backward compat classic microformats root class names, it is unlikely that any implied property (p-name u-url u-photo) was ever intended by the author of the classic microformat. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
Examples:
* see https://indiewebcamp.com/h-entry#bad_hentry_properties for a growing list

'''Proposed resolution:'''

* Be explicit in implied property parsing that it must only be done for explicit 'h-*' root class name microformats, not for any (back)compat parsing of microformats. Please comment on this proposal with "** comment" on new lines below. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
** +1 This makes a lot of sense to me. We should strive to parse mf1 as it was intended by the author, and I think you're right that implied rules are unlikely to be what was intended [[User:Kylewm|Kylewm]] 03:22, 30 December 2014 (UTC)
** +1 I think this will help backcompat parsing, but there are two major things to consider. It may well break some consumer code as the output for a microformats currently always has the name property, there may not be the defences code to check this is true when we remove the implied name rule for classic microformats. The test suite will also need major updating as all the test output for classic microformats will have. I will look into implementing this and report back to the wiki. [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** Also it should be made clear that we are only removing the implied rules from classic microformats parsing and not the value property? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
*** The "parsing for implied properties" section only references name, photo, url properties. Where (in the spec) is the confusion about "value" coming from? [[User:Tantek|Tantek]]
** RESOLVED at [[2015-01-20]] meetup. [[User:Tantek|Tantek]] 04:09, 21 January 2015 (UTC)
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Set implied properties by microformat version"

=== link elements and u- parsing ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Raised by tantek on 2014-07-08 on [http://logs.glob.uno/?c=freenode%23microformats&s=8+Jul+2014&e=9+Jul+2014#c72916 irc]: should the parsing specification for handling u- properties be modified to include the <code>link</code> element? The potential downside is that [[invisible-metadata-is-considered-harmful]], however all known real world examples of <code>link</code> are <em>semi-</em>visible data (not fully hidden).

There are potential cases for wanting to use link as an alternative to <code>a</code> (and <code>area</code>), such as a whole page where the root <code>html</code> element is an <code>h-card</code> and the properties are included across the page: some in visible data in the <code>body</code> while others are in the <code>head</code> as <code>link</code> elements. Example:

One specific use-case is the semi-visible <code>link rel="shortcut icon" href="..."</code> - which is visible sometimes in browser UI, and also when a user chooses "Add to Home Screen" on a mobile device. Such page level icons may be used as a <code>u-photo</code> or <code>u-logo</code> of the containing <code>h-*</code> object on the <code>html</code> element.
* http://adactio.com/about/myself/ on 2014-190
** <em>could</em> use <code><html class=h-card></code> - page is all about Jeremy Keith the person
** <em>icon / logo is only</em> on <code><link></code> tag which <em>could</em> use <code>class=u-logo</code>: <br/><code><link rel="shortcut icon apple-touch-icon" type="image/png" href="/icon.png" /></code>

Another specific use-case is a post permalink page, e.g. with <code><html class=h-entry></code>
* http://waterpigs.co.uk/notes/4WjHpC/
** <em>has</em> <code><html class="no-js h-entry hentry h-as-note" lang="en"></code>

Another use-case is publishing links to PGP/GPG keys linked from the head which is currently handled by <code><link rel=pgpkey></code> which is already supported in existing [[microformats2-parsing#parse_a_hyperlink_element_for_rel_microformats|microformats2 rel parsing]] of <code>link rel</code> elements. Thus there is a (admittedly weak) argument for consistently parsing <em>both</em> <code><link rel></code> <em>and</em> <code><link class="u-*"></code>.

E.g. inside that aforementioned real world <code><html class=h-entry></code> post permalink page example,
* why should <code><link rel="in-reply-to"></code> work
* but not <code><link class="u-in-reply-to"></code> ?
The slightly stronger argument for consistency of link handling is that it <strong>[[simpler|simplifies]]</strong> the publisher (and parser) model:
* <code><a></code> and <code><area></code> work for both <code>rel</code> and <code>class</code>
* why does <code><link></code> only work for <code>rel</code> ?
* it would be <em>simpler</em> if all three tags just worked (in the same way) for both <code>rel</code> and <code>class</code>

'''Should the parsing spec be modified to handle these cases?''' —[[User:TomMorris|Tom Morris]] 09:25, 9 July 2014 (UTC)

** I'm generally in favour. It'd be good to see what other parser developers think. —[[User:TomMorris|Tom Morris]] 10:16, 9 July 2014 (UTC)
** adding this to the parsers won't be an issue. <del datetime="2014-07-09T18:45">The question is should the door be opened to hidden mf data?</del> <ins datetime="2014-07-09T18:45">Up on further reflection, there seems to be no need to distinguish between <code>rel=property</code> and <code>class=u-property</code> on link elements. So I am in favour for consistency.</ins> [[User:KP|Kartik]] 18:30, 2014-07-09 (EST)
** RESOLVED at [[2015-01-20]] meetup. Make link consistent with a.
</div>

=== drop alternates collection ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 split into separate issue from include alternates in rels per implementation feedback from Kevin Marks. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* drop "alternates" as its no longer needed, and all current consuming code clients like rel-urls better anyway.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls" in original issue now "include alternates in rels", we no longer need "alternates", and those with client consuming code have universally indicated that they would rather use rel-urls anyway. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
</div>

== see also ==
* [[microformats2-parsing]]
* [[microformats2]]

User:Barnabywalters

2016-03-13T18:43:19Z

Barnabywalters: removed out of date text, replaced with text which is not doomed to go out of date

More information about Barnaby on [http://waterpigs.co.uk waterpigs.co.uk]

mf2py

2015-07-12T15:07:38Z

Barnabywalters: Added list of live implementations

{{stub}}

This is a holding page for '''mf2py''', the [[microformats2]] parser for Python.

* [https://github.com/tommorris/mf2py tommorris/mf2py] on github
* [https://pypi.python.org/pypi/mf2py/ mf2py] on PyPI

You can test how mf2py parses HTML on the following pages:
* URL and/or textarea: https://kylewm.com/services/mf2
* URL entry: [https://mf2py.herokuapp.com/ mf2py.herokuapp.com]
* textarea entry: https://kartikprabhu.com/connection/mfparser
* another textarea: http://www.unmung.com/?html=

== See Also ==

* [[parsers]]
* [[microformats2]]
* [[validators]]

representative-h-card-parsing

2014-10-06T23:14:56Z

Barnabywalters: added mf-cleaner implementation

Assuming you already have access to a [[parsers#microformats2_parsers|microformats2 parser]], the algorithm defined here allows you to determine the representative [[h-card]] for a given page.

This algorithm is the microformats2 update to [[representative-hcard-parsing]].

== Algorithm ==

After [[parsing]] the page:

* If the page contains an h-card with '''uid''' and '''url''' properties both matching the page URL, the first such h-card is the representative h-card
* If no representative h-card was found, if the page contains an h-card with a '''url''' property value which also has a <code>rel=me</code> relation (i.e. matches a URL in parse_results.rels.me), the first such h-card is the representative h-card
* If no representative h-card was found, if the page contains '''one single''' h-card with a '''url''' property matching the page URL, that h-card is the representative h-card
* If no representative h-card was found, the page has no representative h-card

=== Matching URLs ===
URLs are to be matched as per the parsing algorithm defined in https://url.spec.whatwg.org:

* Parse the URLs
* If every component matches, the URLs match

== Implementations ==
Open source implementations of the representative h-card algorithm.

* '''PHP''' [https://github.com/barnabywalters/php-mf-cleaner barnabywalters/mf-cleaner] package implements representative h-card parsing in [https://github.com/barnabywalters/php-mf-cleaner/blob/master/src/BarnabyWalters/Mf2/Functions.php#L211 getRepresentativeHCard()] function
** Example usage: <code>$hcard = BarnabyWalters\Mf2\getRepresentativeHCard($mfs, $url);</code>
* Add yours here!
* …

== Back compat ==
All backcompat for representative h-card parsing should already be handled by the [[h-card#Backward_Compatibility|h-card backcompat]] rules, implemented by a conforming parser.

== See Also ==
* [[h-card]]
* [[representative-hcard]] — original hCard work, most of which applies equally to the updated algorithm

representative-hcard-parsing

2014-10-06T22:41:45Z

Barnabywalters: Linked to updated version

<entry-title>representative hCard parsing</entry-title>

{{latest|representative-h-card-parsing}}

Assuming you are already using code that properly implements [[hcard-parsing]], this page documents how to determine a [[representative hCard]] for a page using the current [[representative-hcard-brainstorming]] proposal.

== representative hCard algorithm ==
After [[microformats2-parsing|parsing]] the page:
# '''url uid source.''' The first hCard found which has a "url" property whose value is the url of the page (source) and is also a "uid" property for the hCard, is the representative hCard for the page.
# '''url and rel me.''' If the previous step didn't find a representative hCard, then the first hCard with a "url" property that also has the <code>rel="me"</code> relation is the representative hCard for the page.

== Issues ==
* In the first step, how should URLs be matched? Resolving relative URLs is a given, but there are other cases. E.g. if the h-card has a URL of 'http://aaronparecki.com/', should 'http://aaronparecki.com' match? What about 'https://aaronparecki.com/'? --[[User:Barnabywalters|bw]] 14:47, 6 October 2014 (UTC)
** Per https://url.spec.whatwg.org/ : [[User:Tantek|Tantek]] 22:18, 6 October 2014 (UTC)
*** Parse the URLs
*** Compare the serialization
*** If all the components match, the two URLs match.
*** (background/discussion: [http://krijnhoetmer.nl/irc-logs/whatwg/20141006#l-843])
* Why is u-uid required in addition to u-url in the first step but not the second step? In what case has an h-card had a u-url property matching the URL of the page it’s on, but *not* been the representative h-card? --[[User:Barnabywalters|bw]] 14:47, 6 October 2014 (UTC)
** Let's try a third step: if there is only one hCard with url == page URL then use that hCard, else there is no representative hCard [[User:Tantek|Tantek]] 22:18, 6 October 2014 (UTC)

== open source implementations ==
The below open source implementations of '''representative hCard parsing''' have been contributed inline and are thus in the public domain per [[Microformats_Wiki:Copyrights]].

=== Draft hKit (PHP5) code ===
I - ([[User:TomMorris|Tom]]) - have been working on implementing represenative hCard parsing in PHP so that a user can simply type in a URL pointing to a page with an hCard on it, and have their name and some details automatically filled in the form. The code below implements the following:
# If there is only one hCard on a page, it uses that.
# If there is more than one hCard on a page, it looks through to see if any of the cards have UID or URL fields that match the URL it searches, then selects that one if one exists.

It's experimental and quite 'alpha', so I'd suggest you test it and make adjustments as necessary.

<source lang="php">
<?php
// example hKit code to extract a representative hCard
// tom morris <http://tommorris.org>
// public domain 2007

// An hCard could have more than one url, so we use a multi-dimensional array search. - Sarven Capadisli

// From http://nl2.php.net/manual/en/function.array-search.php#80692
function multidimArrayLocate($array, $text){
foreach($array as $key => $arrayValue){
if (is_array($arrayValue)){
if ($key == $text) $arrayResult[$key] = $arrayValue;
$temp[$key] = multidimArrayLocate($arrayValue, $text);
if ($temp[$key]) $arrayResult[$key] = $temp[$key];
}
else{
if ($key == $text) $arrayResult[$key] = $arrayValue;
}
}
return $arrayResult;
}

include("hkit.class.php");
$hkit = new hKit;
$result = $hkit->getByURL('hcard', $HTTP_GET_VARS['url']);
if (count($result) != 0) {
if (count($result) == 1) {
$repcard = $result[0];
} else {
foreach ($result as $card) {
if (multidimArrayLocate($card, $HTTP_GET_VARS['url']) == true || $card['uid'] == $HTTP_GET_VARS['url']) {
$repcard = $card;
}
}
}
}
print_r($repcard);
?></source>

=== jQuery (JavaScript) code ===
The following JavaScript code follows the [[representative-hcard-brainstorming#current_proposal|current proposal for finding a representative hCard]]. It requires the [http://jquery.com/ jQuery] library, however, it can be easily switched over to another library.

* If a vCard has a <code>class="url"</code> and <code>class="uid"</code> with an href value same as the source URI (current document), then that vCard is a representative hCard candidate, otherwise;
* If a vCard has a <code>class="url"</code> and a <code>rel="me"</code> on the same element, then that vCard is a representative hCard candidate, otherwise;
* There is no representative hCard.
* Grab the first hCard from the list of candidates.

<source lang="javascript">
/***
Note: Extracts representative hCard
Author: Sarven Capadisli http://csarven.ca/
License: Public Domain 2009-06-04
*/
var sourceURI = window.location.href;
var rep_hCard = new Array();

function rep_hCard_uidurlsource() {
$('.vcard .uid[href='+sourceURI+']').each(function() {
$(this).each(function() {
if ($(this).closest('.vcard').find('.url[href='+sourceURI+']').length > 0) {
rep_hCard.push($(this).closest('.vcard')[0]);
}
});
});
return (rep_hCard.length > 0) ? true : false;
}

function rep_hCard_urlme() {
$('.vcard .url[rel=me]').each(function() {
rep_hCard.push($(this).closest('.vcard')[0]);
});
return (rep_hCard.length > 0) ? true : false;
}

if (rep_hCard_uidurlsource() || rep_hCard_urlme()) {
rep_hCard = $($(rep_hCard)[0]);
rep_hCard_url = (rep_hCard.find('.uid').length > 0) ? rep_hCard.find('.uid')[0].href : rep_hCard.find('.url[rel=me]')[0].href;
hCard_fn = $('.fn', rep_hCard).text();
hCard_photo_src = ($('.photo', rep_hCard).length > 0) ? $('.photo', rep_hCard)[0].src : '';
}
else {
//no representative hCard
}
</source>
--[[User:Csarven|Sarven Capadisli]] 04:24, 4 June 2009 (UTC)

== see also ==
* [[representative-hcard]]
* [[representative-hcard-authoring]]
* [[representative-hcard-parsing]]
* [[representative-hcard-examples]]
* [[representative-hcard-formats]]
* [[representative-hcard-brainstorming]]
* [[hcard]]
* [[hcard-parsing]]

representative-h-card-parsing

2014-10-06T22:40:39Z

Barnabywalters: initial updated microformats2 version of representative h-card algorithm

Assuming you already have access to a [[parsers#microformats2_parsers|microformats2 parser]], the algorithm defined here allows you to determine the representative [[h-card]] for a given page.

This algorithm is the microformats2 update to [[representative-hcard-parsing]].

== Algorithm ==

After [[parsing]] the page:

* If the page contains an h-card with '''uid''' and '''url''' properties both matching the page URL, the first such h-card is the representative h-card
* If no representative h-card was found, if the page contains an h-card with a '''url''' property value which also has a <code>rel=me</code> relation (i.e. matches a URL in parse_results.rels.me), the first such h-card is the representative h-card
* If no representative h-card was found, if the page contains '''one single''' h-card with a '''url''' property matching the page URL, that h-card is the representative h-card
* If no representative h-card was found, the page has no representative h-card

=== Matching URLs ===
URLs are to be matched as per the parsing algorithm defined in https://url.spec.whatwg.org:

* Parse the URLs
* If every component matches, the URLs match

== Implementations ==
Open source implementations of the representative h-card algorithm.

* Add yours here!
* …

== Back compat ==
All backcompat for representative h-card parsing should already be handled by the [[h-card#Backward_Compatibility|h-card backcompat]] rules, implemented by a conforming parser.

== See Also ==
* [[h-card]]
* [[representative-hcard]] — original hCard work, most of which applies equally to the updated algorithm

h-card

2014-10-06T22:08:55Z

Barnabywalters: /* Properties */ clarified u-uid, u-logo as set apart from u-photo

<entry-title>h-card</entry-title>
<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-card</dfn> is a simple, open format for publishing people and organisations on the web. h-card is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML/HTML5.

h-card is the [[microformats2]] update to [[hCard]].

{{cc0-owfa-license}}

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

<source lang=html4strict>
<a class="h-card" href="http://example.com">Joe Bloggs</a>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"Joe Bloggs"
],
"url": [
"http://example.com"
]
}
}
]
}
</source>

And a slightly more complete example:

<source lang=html4strict>
<p class="h-card">
<img class="u-photo" src="http://example.org/photo.png" alt="" />
<a class="p-name u-url" href="http://example.org">Joe Bloggs</a>
<a class="u-email" href="mailto:joebloggs@example.com">joebloggs@example.com</a>,
<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>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"photo": [
"http://example.org/photo.png"
],
"name": [
"Joe Bloggs"
],
"url": [
"http://example.org"
],
"email": [
"mailto:joebloggs@example.com"
],
"street-address": [
"17 Austerstræti"
],
"locality": [
"Reykjavík"
],
"country-name": [
"Iceland"
]
}
}
]
}
</source>

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

For minimal examples where at most <code>p-name</code>, <code>u-url</code> and <code>u-photo</code> are required (such as the first given above), only the root class name is needed — see [[microformats-2-implied-properties|implied properties]].

For more complex examples, the root class name must be placed on an element which encloses all the desired properties, and then the properties themselves marked up using the classnames given below.

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

== Properties ==
h-card properties, inside an element with class '''h-card''':
* '''<code>p-name</code>''' - The full/formatted name of the person or organisation
* '''<code>p-honorific-prefix</code>''' - e.g. Mrs., Mr. or Dr.
* '''<code>p-given-name</code>''' - given (often first) name
* '''<code>p-additional-name</code>''' - other/middle name
* '''<code>p-family-name</code>''' - family (often last) name
* '''<code>p-sort-string</code>''' - string to sort by
* '''<code>p-honorific-suffix</code>''' - e.g. Ph.D, Esq.
* '''<code>p-nickname</code>''' - nickname/alias/handle
* '''<code>u-email</code>''' - email address
* '''<code>u-logo</code>''' - a logo representing the person or organisation
* '''<code>u-photo</code>'''
* '''<code>u-url</code>''' - home page
* '''<code>u-uid</code>''' - unique identifier, often canonical URL
* '''<code>p-category</code>''' - category/tag
* '''<code>p-adr</code>''' - postal address, optionally embed an [[h-adr]] {{main|h-adr}}
* '''<code>p-post-office-box</code>'''
* '''<code>p-extended-address</code>''' - apartment/suite/room name/number if any
* '''<code>p-street-address</code>''' - street number + name
* '''<code>p-locality</code>''' - city/town/village
* '''<code>p-region</code>''' - state/county/province
* '''<code>p-postal-code</code>''' - postal code, e.g. US ZIP
* '''<code>p-country-name</code>''' - country name
* '''<code>p-label</code>'''
* '''<code>p-geo</code>''' or '''<code>u-geo</code>''', optionally embed an [[h-geo]] {{main|h-geo}}
* '''<code>p-latitude</code>''' - decimal latitude
* '''<code>p-longitude</code>''' - decimal longitude
* '''<code>p-altitude</code>''' - decimal altitude
* '''<code>p-tel</code>''' - telephone number
* '''<code>p-note</code>''' - additional notes
* '''<code>dt-bday</code>''' - birth date
* '''<code>u-key</code>''' - cryptographic public key e.g. SSH or GPG
* '''<code>p-org</code>''' - affiliated organization, optionally embed an [[h-card]]
* '''<code>p-job-title</code>''' - job title, previously 'title' in [[hCard]], disambiguated.
* '''<code>p-role</code>''' - description of role
* '''<code>u-impp</code>''' per RFC 4770, new in vCard4 (RFC6350)
* '''<code>p-sex</code>''' - biological sex, new in vCard4 (RFC6350)
* '''<code>p-gender-identity</code>''' - gender identity, new in vCard4 (RFC6350)
* '''<code>dt-anniversary</code>'''

All properties are optional.

== Status ==
'''h-card''' is a microformats.org draft specification. Public discussion on h-card takes place on [[h-card-feedback]], the #microformats [[irc]] channel on irc.freenode.net, and [http://microformats.org/discuss/mail/microformats-new/ microformats-new mailing list].

h-card is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-cards up as classic [[hCard]]s.

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

=== p-adr ===
<code>p-adr</code> can optionally embed an [[h-adr]] to cluster associated structured address properties. E.g. adding "p-adr" to the example earlier:

<source lang=html4strict>
<div class="h-card">
<p class="p-name">Joe Bloggs</p>
<p class="p-adr 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>
</div>
</source>

Q: Why would you use "p-adr" to cluster associated structured address properties?

A: Because if you have more than one structured address, it helps to cluster which properties go with which address, e.g. home vs. work.

=== p-tel ===
Note: use of 'value' within 'p-tel' should be automatically handled by the support of the [[value-class-pattern]]. And for now, the former [[hCard]] 'type' subproperty of 'tel' is dropped/ignored. If there is demonstrable documented need for additional tel types (e.g. fax), we can introduce new flat properties as needed (e.g. p-tel-fax).

=== Reserved properties ===
Reserved properties (not used much, if at all, in practice):

* '''<code>p-organization-name</code>'''
* '''<code>p-organization-unit</code>'''
* '''<code>p-tz</code>''' - timezone offset, e.g. <code><data class="p-tz" value="-0800">PST</data></code>
* '''<code>dt-rev</code>'''

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

* ... add uses of h-card you see in the wild here.
* App.net rolled out support for h-card and h-entry on all profile pages and permalink pages as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* Brett Comnes marks up his posts with h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his homepage and posts with h-card [http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his homepage and posts up with h-card and h-entry ([sandeep.io/101 example])
* spreadly marks up share permalink pages with minimal h-cards inside h-entry ([http://my.spread.ly/share/51d570bc09e9486562000002 example])
* [http://eschnou.com/ Laurent Eschenauer] marks his homepage profile up using h-card
* [http://tommorris.org/ Tom Morris] marks himself up with h-card as well as venues he’s checked into ([http://tommorris.org/posts/8408 example])
* [http://www.w3.org/conf/ W3Conf 2013] uses h-card for all the event speakers and notable attendees. The h-cards make particularly good use of implied name, url, and photo properties.
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry and h-as-*
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card markup on their homepage and individual thoughts pages
* Tom Morris uses h-card and [[XFN]] to markup [http://tommorris.org/pages/blogroll his blogroll].
* Aaron Parecki uses h-card to markup both authorship and references to people in his notes permalinks, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-card on his home page as well as within [[h-entry]]s on permalink pages to indicate authorship.
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-card on his home page, as well as within h-entries for notes and articles, both to indicate authorship and also when mentioning people within the body of the notes.
* [http://tantek.com/presentations/2012/06/microformats microformats.org at 7 years] presentation with and h-card markup for people and organizations.
* [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-card markup
* WebMaker by Mozilla has [[microformats2]] 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]
* WebFWD by Mozilla has [[microformats2]] h-card markup on [https://webfwd.org/about/experts/ experts] and [https://webfwd.org/about/team/ team] pages
* [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.

== Validating ==
* '''[http://indiewebify.waterpigs.co.uk/validate-h-card/ indiewebify.me h-card validator]''' parses [[h-card]] markup and makes suggestions for things to add, with code samples
{{h-spec-section-validating}}

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

<source lang=html4strict>
<p class="h-card vcard">
<span class="p-name fn">Joe Bloggs</span>,
<span class="p-org org">Awesome Nonprofit</span>
...
</p>
</source>

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

'''fn''', '''org''', and all the other backward compatibility hCard property class names 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-card" is found, don't look for a "vcard" on the same element.

Compat. root class name: <code id="vcard">vcard</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>honorific-prefix</code>
* <code>given-name</code>
* <code>additional-name</code>
* <code>family-name</code>
* <code>honorific-suffix</code>
* <code>nickname</code>
* <code>email</code> - parse as '''u-'''
* <code>logo</code> - parse as '''u-'''
* <code>photo</code> - parse as '''u-'''
* <code>url</code> - parse as '''u-'''
* <code>uid</code> - parse as '''u-'''
* <code>category</code>
* <code>adr</code> - parse as '''<code>p-adr h-adr</code>''' including compat root class <code>adr</code>
* <code>extended-address</code>
* <code>street-address</code>
* <code>locality</code>
* <code>region</code>
* <code>postal-code</code>
* <code>country-name</code>
* <code>label</code>
* <code>geo</code> - parse as '''<code>p-geo h-geo</code>''' including compat root class <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* <code>tel</code>
* <code>note</code>
* <code>bday</code> - parse as '''dt-'''
* <code>key</code> - parse as '''u-'''
* <code>org</code>
* <code>organization-name</code>
* <code>organization-unit</code>
* <code>title</code> - parse as '''p-job-title'''
* <code>role</code>

Reserved: (backward compat properties that parsers {{may}} implement, if they do, they {{must}} implement in this way:
* <code>tz</code>
* <code>rev</code> - parse as '''dt-'''

== Background ==
This work is based on the existing [[hCard]] and [[vcard]] specifications.

== Design Principles ==

(stub, expand)

== See Also ==

* [[microformats2]]
* [[microformats2-parsing]]
* [[h-adr]]
* [[h-geo]]
* [[hCard]]

[[Category:Draft Specifications]]