Microformats Wiki - User contributions [en]

h-review-feedback

2016-05-16T14:34:43Z

Kylewm: /* Consistency with other microformats */ +1

Feedback and discussion of [[h-review]]. Summarise any useful conclusions from discussions in [[irc]] here.

== Consistency with other microformats ==

Some h-review properties are extremely similar to more generic, reusable properties in other microformats such as [[h-entry]], [[h-recipe]]:

* p-reviewer => p-author
* dt-reviewed => dt-published
* e-description => e-content

What is the value of duplicating these properties? Could they be merged, increasing consistency between microformats and reducing total amount of surface area which must be remembered? As there are almost no microformats2 h-reviews in the wild, right now would be a good time to make these changes --[[User:Barnabywalters|bw]] 15:22, 13 March 2014 (UTC)

** +1 Would make the publishing side a little easier, and the consuming side a lot easier. Right now, Woodwind does not display h-reviews, but if they used mostly common properties, they would be easier to add. [[User:Kylewm|Kylewm]] 14:34, 16 May 2016 (UTC)

microformats2-parsing-brainstorming

2016-05-07T19:45:32Z

Kylewm: /* Pronouns in different languages */ Inherited language

<entry-title>microformats2 parsing brainstorming</entry-title>

This page is for brainstorming, discussion, and other questions and explorations about [[microformats2]] parsing.

For the microformats2 parsing algorithm, see:
* [[microformats2-parsing]]

For filing issues / problems with microformats2-parsing, see:
* [[microformats2-parsing-issues]]

__TOC__

== Parse language information ==
Raised by [[User:VoxPelli|VoxPelli]] 18:04, 23 July 2015 (UTC)
* 2016-060: Update: and parse "id" attribute. [[User:Tantek|Tantek]] 16:39, 29 February 2016 (UTC) (see Additionally below)

Currently there’s no way to tell the language of parsed microformats even if those microformats has been marked up with HTML "lang"-attributes.

There are examples in the wild of people marking up pages in such a way:

* [http://voxpelli.com/ VoxPelli.com] has a "lang"-attribute on the h-entry of his [http://voxpelli.com/2011/03/sista-dagen-p-good-old/ swedish articles] to signify that the article is swedish even though the rest of the site is english.
* Stephanie [http://climbtothestars.org/archives/2013/09/17/basic-bilingual-1-0-plugin-for-wordpress-blog-in-more-than-one-language/ uses a WordPress plugin] that adds summaries of other languages at the start of her content.

Proposal is to add a new "lang" keyword to h-* and e-* objects so that the following example:

<source lang=html4strict>
<div class="h-entry" lang="sv">
<h1 class="p-name">En svensk titel</h1>
<div class="e-content" lang="en">With an <em>english</em> summary</div>
<div class="e-content">Och <em>svensk</em> huvudtext</div>
</div>
</source>

Would be parsed into something like:

<source lang=javascript>
{
"type": ["h-entry"],
"lang": "sv",
"properties": {
"name": ["En svensk titel"],
"content": [
{
"lang": "en",
"html": "With an <em>english</em> summary",
"value": "With an english summary"
},
{
"html": "Och <em>svensk</em> huvudtext",
"value": "Och svensk huvudtext"
}
]
}
}
</source>

This was [http://indiewebcamp.com/irc/2015-07-23#t1437667712078 brainstormed on the IndieWebCamp IRC-channel] where the mentioned example came up.

* Pull request for implementation in microformat-node added 2015-07-23 https://github.com/glennjones/microformat-node/pull/23
** Closed 2015-09-08 because the library has changed and parsing is now handled by microformat-shiv. New issue opened there: https://github.com/glennjones/microformat-shiv/issues/22

Additionally: consider the same for "id" attributes (use-case: rel=feed local discovery of a nested h-feed on the home page), specifically, parsing the first instance of any "id" attribute (ignoring latter duplicate id attribute values on any subsequent elements).

And alternatively: consider parsing as "html-id" and "html-lang" prefixed properties in the parsed result, e.g.

<source lang=html4strict>
<div class="h-entry" lang="sv" id="postfrag123">
<h1 class="p-name">En svensk titel</h1>
<div class="e-content" lang="en">With an <em>english</em> summary</div>
<div class="e-content">Och <em>svensk</em> huvudtext</div>
</div>
</source>

Would be parsed into something like:

<source lang=javascript>
{
"type": ["h-entry"],
"html-id": "postfrag123",
"html-lang": "sv",
"properties": {
"name": ["En svensk titel"],
"content": [
{
"html-lang": "en",
"html": "With an <em>english</em> summary",
"value": "With an english summary"
},
{
"html": "Och <em>svensk</em> huvudtext",
"value": "Och svensk huvudtext"
}
]
}
}
</source>

=== Language inheritance ===

If the "lang" attribute is not specified for a particular element, it is inherited from the nearest parent (or from the HTTP Content-Language header)

https://www.w3.org/TR/html4/struct/dirlang.html#h-8.1.2

Proposal: Determine and include the inherited "lang" value on *every* microformat object that directly specifies a lang or that has an ancestor that does, e.g. if <html lang="en">, then every object in the output will have "lang": "en".

=== Pronouns in different languages ===

Language is also useful context when defining [[pronouns]], discussed a bit here[https://github.com/idno/Known/pull/1426#issuecomment-217626923].

<source lang=html4strict>
<div class="h-card" lang="en">
<span class="p-x-pronoun-nominative">he</span> /
<span class="p-x-pronoun-possessive">him</span> /
<span class="p-x-pronoun-oblique">his</span>
</div>
</source>

would parse as

<source lang=javascript>
{
"type": ["h-card"],
"lang": "en",
"properties": {
"x-pronoun-nominative": ["he"],
"x-pronoun-possessive": ["him"],
"x-pronoun-oblique": ["his"]
}
}
</source>

It could also be useful to specify multiple languages within a single h-card (pardon me if I butcher Swedish pronouns)

<source lang=html4strict>
<div class="h-card">
<span lang="en" class="p-x-pronoun-nominative">he</span> /
<span lang="en" class="p-x-pronoun-possessive">him</span> /
<span lang="en" class="p-x-pronoun-oblique">his</span>
<span lang="sv" class="p-x-pronoun-nominative">han</span> /
<span lang="sv" class="p-x-pronoun-possessive">hans</span> /
<span lang="sv" class="p-x-pronoun-oblique">honom</span>
</div>
</source>

which might parse as

<source lang=javascript>
{
"type": ["h-card"],
"properties": {
"x-pronoun-nominative": [{"lang": "en", "value": "he"}, {"lang": "sv", "value": "han"}],
"x-pronoun-possessive": [{"lang": "en", "value": "him"}, {"lang": "sv", "value": "hans"}],
"x-pronoun-oblique": [{"lang": "en", "value": "his"}, {"lang": "sv", "value": "honom"}]
}
}
</source>

or alternatively, we could introduce a new microformat h-x-pronoun to wrap a set of pronouns

<source lang=html4strict>
<div class="h-card">
<div class="p-x-pronoun h-x-pronoun" lang="en">
<span class="p-nominative">he</span> /
<span class="p-possessive">him</span> /
<span class="p-oblique">his</span>
</div>
<div class="p-x-pronoun h-x-pronoun" lang="en">
<span class="p-nominative">han</span> /
<span class="p-possessive">hans</span> /
<span class="p-oblique">honom</span>
</div>
</div>
</source>

parsed as

<source lang=javascript>
{
"type": ["h-card"],
"properties": {
"x-pronoun": [{
"type": ["h-x-pronoun"],
"lang": "en",
"properties": {
"nominative": ["he"],
"possessive": ["him"],
"oblique": ["his"]
}
}, {
"type": ["h-x-pronoun"],
"lang": "sv",
"properties": {
"nominative": ["han"],
"possessive": ["hans"],
"oblique": ["honom"]
}
}]
}
}
</source>

<div class="discussion">
Discussion:
* [[User:Kylewm|Kylewm]] Including the "lang" attribute in h- and e- properties makes a ton of sense to me.
* [[User:Kylewm|Kylewm]] I like the idea of introducing an h-x-pronoun container that can define all the different pronoun forms for a particular language
* ...

</div>

== Canonicalization of datetime output ==
Status: resolved, awaiting implementation attempt/experience.

It would be useful to choose a (more) uniform output format for datetimes to make it easier for users of the parser to consume datetimes. Microformats2 parsers already do sophisticated pattern matching to recognize date vs. time vs. datetimes, so converting this to any specific format should not add overhead.

<div class="discussion">
Specifically:
* Choose either 'T' or space as the date/time separator.
** Prefer space as it is more human friendly/readable, which matters even for syntaxes/formats, as human still develop, debug them. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* Choose either +XXYY or +XX:YY as the timezone specification (and convert 'Z' to +0000).
** Would appreciate some study / input here as to which timezone offset syntax is more human friendly. I lean slightly toward +/-NNNN (without the colon) because in the context of seeing a time, leaving out the colon makes it less likely the offset will be confused for a time. E.g. "07:00-08:00" looks like 7-8am, even if it meant 07:00 in PST. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** Space is fine - consensus [[2015-01-20]] meetup.
* Parsers should ''not'' attempt make datetimes more exact than specified. They should not add time, seconds, or timezone if omitted in the original. [[User:Kylewm|Kylewm]] 04:02, 14 May 2014 (UTC)
** Agreed. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** or month, day per Tom Morris
** consensus [[2015-01-20]] meetup

* Counterpoint: PHP's builtin date parsing does not require strict formatting. And the equivalent functionality for Python is provided by the widely used python-dateutil library. [[User:Kylewm|Kylewm]] 19:02, 14 May 2014 (UTC)
** However we cannot (must not) depend on either PHP or Python's "smart" "fixing" or Postelian "liberal handling", or any other language/framework's for that matter, as they all differ in how "intelligent" they are. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
</div>

Perhaps just provide a guideline for these based on the above consensus.

== Add meta http-equiv to microformats2 parsing model ==
Status: disagreement, awaiting implementation attempt/experience.

Similar to document level parsing of <code>rel</code> attributes, it makes sense simultaneously to parse <code><meta http-equiv></code> elements, perhaps treating "Status" in a special way (only using first number (sequence of digits) for its "value").

Use case: IndieWeb "deleted" indication inline in content for static file services that don't support HTTP return codes.
* http://indiewebcamp.com/deleted#HTML_meta_http-equiv_for_status

HTTP Header example:
* <samp>Content-Type: text/html; charset=utf-8</samp>
HTML equivalent:
* <code><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></code>

Related:
* https://www.w3.org/International/O-HTTP-charset

<div class="discussion">
* Interesting thought. Are you suggesting a top level "http-equivs:" collection similar to "rels:" in the parsed output? Should we consider "metas:" instead or in addition? [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* What's the use case for this? Also, http-equiv on its own is useless. http-equiv is only a supplement to the data stored in headers. And headers aren't always there: what happens in the context of someone debugging a page who pastes the source into the textarea of an mf2 parser? Without a compelling use case for including headers (and then over-riding some of them with http-equivs), I'm not sure why an implementor want to do this. —[[User:TomMorris|Tom Morris]] 00:25, 8 May 2015 (UTC)
</div>

E.g. from https://gist.github.com/aaronpk/10297489

<source lang="html4strict">
<meta http-equiv="Status" content="410 GONE"/>
</source>

<source lang="javascript">
{
"items": [],
"rels": {},
"http": {
"status": 410
}
}
</source>

<div class="discussion">
* Maybe make this an optional pass in the parser? - Tom Morris [[2015-01-20]]
* For now, don't bother with metas until someone provides a use-case. Tom Morris
* Agreed on both counts. [[User:Tantek|Tantek]] 06:56, 21 January 2015 (UTC)
</div>

==MIME type==
See [[microformats2-mime-type]]

----

==Other Interpretation Parsing Notes==
Note: most of these need to be written up as separate [[microformats2-parsing-issues]]

Author: [[User:BenWard|Ben Ward]]

[[microformats-2|Microformats 2]] proposes a new, all encompassing syntax modification of [[microformats-2-prefixes|prefixes]] that will allow microformats to be parsed from pages by processors without prior knowledge of a vocabulary. The core components of this model are quite simple, are quite simple to implement, but there are a number of conflicts that emerge with the functionality of existing microformats parsers that need to be handled. This page documents a proposed model to separate these concerns clearly in a way that can be applied to the documentation of generic microformats parsing rules, and the documentation of individual vocabularies.

Collection of other unresolved parsing issues in a generic model:

This is good material for documenting as [[microformats-2-issues]], [[microformats-2-faq]], and perhaps some of the more technical details in [[microformats-2-parsing-faq]].

* The include pattern references other elements from elsewhere in a document. A generic parser needs to track IDs and fill them in after walking the DOM. (also, <code>itemref</code> if adopted.)
** The current thinking per [[microformats-2-brainstorming]] is to adopt <code>itemref</code> and drop the [[include-pattern]]. [[User:Tantek|Tantek]]
* Will <code>itemref</code> always map to an <code>item</code> property name?
** No, <code>itemref</code> maps to one or more elements by ids, and their children. Those referenced elements may have property class names themselves, or they may contain elements that do. [[User:Tantek|Tantek]]
* [[hAtom]] implies <code>author</code> from an hCard in a page that uses an <code>address</code> element. This requires format knowledge, but a generic parser does not currently track the element type of a property node. Should it?
** It should not. element-specific handling (e.g. using "alt" from img, and "title" from abbr) is completely done at parse time. The JSON data model does not reflect which element type or attribute the value came from. Additionally, [[hAtom]] is an example where we created far too many vocabulary-specific rules, in practice they're not necessary, and only complicate the microformat for both publisher understanding and parser implementation. [[User:Tantek|Tantek]]
* [[hAtom]] defines that the highest level heading within an entry implies <code>entry-title</code>. This particular optimisation might be better off dead.
** Agreed, this is gone in microformats 2. [[User:Tantek|Tantek]]
* [[hAtom]] defines that permalinks be parsed from <code>rel</code> attributes, not <code>class</code>
** In practice this has been one of the more problematic/error prone aspects of hAtom implementations, and it's also inconsistent with other microformats (although [[hReview]] tried to use both rel permalinks and "url"). The dependence upon [[rel-bookmark]] for permalinks is dropped in h-atom in preference to re-using "u-url" and "u-uid". [[User:Tantek|Tantek]]
* [[XFN]] is entirely built on <code>rel</code> (although, has various other differences from structural microformats, as do vote-links, so perhaps are excluded from this discussion and will always be handled by dedicated parsers/queries regardless?)
** The best (easiest and most reliable) use of 'rel' microformats in practice is when they are orthogonal to 'class' microformats. This is true both with [[XFN]] and some newer [[existing-rel-values|rel values]] like [[rel-author]]. In addition, it was very clear at the recent [[schema.org]] workshop's syntax session that RDFa's decision to apparently arbitrarily mix use of 'rel' and 'property' attributes for specifying different types of properties (it wasn't clear to people in the room when you use which for what) has caused a high degree of confusion among publishers and thus high error-rates. Thus if anything we should learn from both the mistakes of RDFa and our own experiences with even very deliberate/specific mixing of rel microformats in class microformats, and keep them defined as separate orthogonal building blocks that work together, but don't depend on each other. [[User:Tantek|Tantek]]
*** Relatedly to this: <code>rel-tag</code> in hAtom. --[[User:BenWard|BenWard]] 06:50, 5 October 2011 (UTC)
**** Yes, and two related things here. First, despite my (and others') objection and (past) interoperable post/entry-specific treatment by Technorati and Ice Rocket, Hixie has redefined rel-tag in [[HTML5]] to mean applying to the whole page, not a single post. Second, I've explicitly added 'p-category' to the draft 'h-atom' vocabulary in [[microformats-2]]. [[User:Tantek|Tantek]] 07:12, 5 October 2011 (UTC)
* HTML's <code>time</code> element includes an optional <code>pubdate</code> attribute. Simply: We should parse this as <code>dt-published</code>. --[[User:BenWard|BenWard]] 06:12, 10 October 2011 (UTC)
** *If* there is even some reasonable data on actual use of the "pubdate" attribute (I don't think there is, frankly, especially with the removal of the algorithm to produce Atom from HTML5), then we could consider parsing "pubdate" as backwards compatible option for "dt-published". As a general rule, however, it is bad (demonstrably/experienced) design to depend on additional attributes (c.f. RDFa confusion over "property" vs. "rel"), especially for an instance where no additional attribute is necessary. I would leave this out for now until there is non-trivial (more than just test pages or folks who've written HTML5 books, ahem) use in the wild. When there is such use in the wild, it should be documented on a wiki page. We don't want to encourage more complex (additional attribute) publishing as a result of supporting it. [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)
* [[value-class-pattern]]: In microformats-2, since there are no sub-properties, there will presumably no-longer be a 'value' property in any parsed model. Properties such as 'tel > type' in hCard are, as I recall, deprecated due to underuse anyway, so 'tel > value' becomes redundant. (There's also potentially some clarification around 'price > value' in hListing, whereby value was used in a pattern. So, what does this mean for value class parsing, with regard to value-title patterns and date separation patterns. Are we looking for a 'p-value' and 'p-value-title' classname, but treating them specially (excluding them from regular property parsing.) Or, are we giving them a special prefix (v-text, v-title? That seems confusing, but could be a concept.) I'm fine with p- for both, and just having the parser ignore them since they're special, but need clarification and naming confirmation. --[[User:BenWard|BenWard]] 09:35, 10 October 2011 (UTC)
** A few things:
*** 1. Yes, no more subproperties. 'tel' becomes just 'p-tel'. If there is demand for a structured 'tel' value, then we can use that demand (and research into publishing in practice) to brainstorm and create an 'h-tel' structured telephone number (with perhaps fields like 'type', 'extension', some indication of it being local dialing (an extra 0 in some countries) or international dialing, etc.) Or, we address the different 'tel' types as their own flat properties (again as justified by research), e.g. perhaps 'p-tel-fax', or 'p-tel-mobile'. Something for hcard-2-brainstorming.
*** 2. For prices, e.g. hListing, either we're going to need to encode how to parse monetary amounts including monetary symbols, or consider creating an 'h-price' structured price. Not sure what the right answer is here, again, will need to be informed by analysis of documented actual price publication practices.
*** 3. We should avoid introducing a new prefix 'v-' just for value-class-pattern. As we've noted elsewhere, each new prefix adds complexity and should be avoided without substantial advantage.
*** 4. Using 'p-value-title' is strange, as it would be an exception to 'p-' parsing, since it would get the value from the 'title' attribute whereas 'p-' properties don't normally do that (exception: abbr).
*** 5. Using 'p-value' is also strange, as it wouldn't generate a 'value' property in the JSON data model.
*** 6. Class name 'value-title' is already sufficiently prefixed - we've found or even heard of no collisions in practice.
*** 7. Class name 'value' can, by its simpler naming nature, be expected to potentially collide with other web designer class name usage though we have no documentation/mention thereof. We could consider a renaming, or providing of alternative, such as 'value-string', or 'value-content', etc. However, let's keep that as a backup plan to use only if/when evidence is presented that we need to.
** Conclusions: for now, in microformats-2, keep using 'value' and 'value-title' as defined in the [[value-class-pattern]], and add the additional (obvious) interpretation that [[value-class-pattern#Date_and_time_parsing|value class pattern: date and time parsing]] applies to all 'dt-' properties. - [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)

== incorporated 2015-05-28 ==
The following brainstorms were incorporated 2015-05-28.

== more information for alternates ==
Raised 2015-04-24 by [[User:Kevin Marks|Kevin Marks]]

The existing <code>alternate</code> parsing is omitting <code>title</code> - that should be added. The <code>text</code> would make sense to add here too.

Use-case: labels for presenting alternates

<div class="discussion">
* +1 Makes sense. [[User:Tantek|Tantek]] 03:41, 25 April 2015 (UTC)
</div>

== more information for rel-based formats ==
Raised 2015-04-18 by [[User:Kevin Marks|Kevin Marks]]

Related github test suite issue: https://github.com/microformats/tests/issues/16

Several rel-based formats have additional information that is useful beyond the link itself, which is all we capture at the moment. As I am trying to update the Universal feedparser to support mf2 based I will show examples from the [https://github.com/kevinmarks/feedparser/tree/365623a9470e99246f393a8c1f49a0db567826b8/feedparser/tests/microformats testcases] there.

The main change is to add a <code>rel-urls</code> entry for more information about the attributes and text of the urls pointed to by rel's in the document

A fork of mf2py that implements these changes is at https://github.com/kevinmarks/mf2py
=== rel-tag ===

<code><a rel="tag" href="http://del.icio.us/tag/tech">Technology</a> </code>

currently parses to:

<code>{"rels": {"tag": ["http://del.icio.us/tag/tech"]}, "items": []} </code>

This loses the link text, which is useful as a label.

We add a <code>rel-urls</code> element to the parsed output with this extra data that can be looked up from the rels, which doesn't break backward compatibility and works better with xfn (see below)

<code><pre>
{
"rels": {
"tag": [
"http://del.icio.us/tag/tech"
]
},
"items": [],
"rel-urls": {
"http://del.icio.us/tag/tech": {
"rels": [
"tag"
],
"text": "Technology"
}
}
}
</pre></code>

=== xfn ===

<code><a rel="coworker" href="http://example.com/johndoe">John Doe</a></code>

currently parses to:

<code>{"rels": {"coworker": ["http://example.com/johndoe"]}, "items": []}</code>

This loses the link text, which is the person's name. Suggested output using the urls object:

<code><pre>
{
{
"rels": {
"coworker": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker"
],
"text": "John Doe"
}
}
}
</pre></code>

with multiple xfn values

<code><a rel="coworker friend" href="http://example.com/johndoe">John Doe</a></code>
we get this:

<code><pre>
{
"rels": {
"coworker": [
"http://example.com/johndoe"
],
"friend": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker",
"friend"
],
"text": "John Doe"
}
}
}
</pre></code>

=== rel-enclosure ===

<code><a rel="enclosure" href="http://example.com/movie.mp4" type="video/mpeg" title="real title">my movie</a></code>

currently parses to:

<code>'{"rels": {"enclosure": ["http://example.com/movie.mp4"]}, "items": []}'</code>

This loses the link text, which is the title and the attributes which give type. Suggested output:

<code><pre>
{
"rels": {
"enclosure": [
"http://example.com/movie.mp4"
]
},
"items": [],
"rel-urls": {
"http://example.com/movie.mp4": {
"rels": [
"enclosure"
],
"text": "my movie",
"type": "video/mpeg",
"title": "real title"
}
}
}
</pre></code>

This generalises to other rel's too, such as [[rel-feed]] and [[rel-alternate]] that have type, lang etc attributes.

(updated to include changes from feedback below) [[User:Kevin Marks|Kevin Marks]] 22:13, 26 April 2015 (UTC)

=== attributes parsed ===
Attributes currently parsed are:
* <code>hreflang</code> for alternate and enclosure
* <code>media</code> for alternate and enclosure
* <code>title</code> for alternate and enclosure
* <code>type</code> for alternate and enclosure

Attributes we may consider parsing if we have a use case are
* <code>sizes</code> for icon - need use-case documentation
* <code>coords</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats
* <code>shape</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats

In addition there is a special attribute <s><code>name</code> </s><code>text</code> which is the text contents of the link, which is useful in rel-tag rel-enclosure and xfn, and in alternate when used for feeds. It's also clarifying for rel-me links.

Tantek [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79057 suggests] we use <code>textContent</code> for this instead, and make it a single string, not a list as <code>name</code> is elsewhere in mf2 parsing
* Update: "text" is good enough, and "textContent" is ugly camelCase. [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)

=== feedback on more rel info ===
<div class="discussion">
# "name" is bad because it misleadingly conflates with use of "name" elsewhere in microformats2.
#* Suggested alternative: [https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent textContent] - since that's literally what is being returned there. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** as all other mf2 keys are lowercase-with-hyphens, [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79101 Tantek suggests] 'text' as that isn't going to be an html [[User:Kevin Marks|Kevin Marks]] 07:28, 25 April 2015 (UTC)
# no need for array for "name"/textContent - since there is always only one at most
#* E.g. should be "textContent": "my movie" [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#* Update: "text": "my movie" [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)
# "urls" key is misleading - implies all URLs in the document, which is neither true, nor desired (takes much more parsing time and work and code)
#* Suggested alternative: "rel-urls". And open to better alternatives too. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** If we are trying to extend the number of properties retuned from a rel without breaking the old structure why don't we call the new structure something like "rels-extended" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#*** Extension is not the point, but rather to use them complementary. One structure for look-up of any rel value, hence "rels", which returns you a list of URLs. Then you can lookup those URLs in the new mapping, by URL, hence it is called "rel-urls" - that's the point to use them in conjunction and that's why rel-urls is named what it is. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

# Why is the structure of "rel-urls" different to the "alternates" structure. Should the "url" not just be added as a property and not as a key. Creating two data structures for one type of object seems inconsistent. It adds cognitive load to anyone trying to understand the JSON structure [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* I was trying to avoid breaking the existing <code>rels</code> structure and use of it - I did implement a variant that put the structure inside rels, and it became cumbersome and repetitive where there were multiple rels on a url (xfn cases). Denormalising as properties of the URL made more sense. It also dedupes if there is repetitive linking to the same URL, eg a series of posts with rel-author on each. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
# If the rel is a "tag" then the main value we need to return should be the last path component of the URL, not the link text? Should we add another output property ie "tag" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* No need to return last path segment of the URL, because the URL is already there - and that's just a library/framework utility function to get the last path segment of a URL. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)
# As currently described, the URL from <code>alternates</code> is repeated in the <code>rel-urls</code> structure. If we are doing this, surely <code>alternate</code> should be in <code>rels</code> too? I assumed a mapping between them. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
## edit showing this variant: http://microformats.org/wiki/index.php?title=microformats2-parsing&oldid=65021#parse_a_hyperlink_element_for_rel_microformats
</div>
#* Yes it makes sense to drop "alternates" assuming the backcompat impact is low, put alternates in "rels" along with everything else, and direct people to use rels and rel-urls for alternates functionality. Evidence this is an acceptable even preferable approach.[http://indiewebcamp.com/irc/2015-06-01/line/1433195247005] Will add an issue accordingly. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

== Incorporated 2015-06-06 ==

== Nested h-* objects' "value" property ==
Status: resolved, resolution iterated, one real world implementation proven implementability, incorporated
* 2015-06-06 incorporated into [[microformats2-parsing]]

Raised 2015-01-06 by [[User:Kylewm]];

If a child element has a microformat (h-*) and is a property element (p-*, u-*, dt-*, e-*), the parser will add a "value" property to the resulting object. The value should attempt to be a useful representation of the object for consumers that do not have semantic knowledge of the particular h-* type. Ref: [[microformats2-parsing#parse_an_element_for_class_microformats]].

To determine the "value", we parse the property element simply (as if it did not have a h-* class), which works well for simple h-* objects, e.g. <code><a class="u-like-of h-cite" href="...">...</a></code>

<div class="discussion">
* To handle more complex microformats, I propose that "value" for a p-* property element take on the first explicit "name" property of the nested microformat, and for a u-* property, the first explicit "url" property. Parsing will fall back on the current rules if an explicit property does not exist.
** This makes sense to me, and fits with the use-cases and examples I've seen. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** A similar (possibly simpler?) formulation would use the implied name and url rules to determine the "value" for p-* and u-* properties respectively
*** I don't think that's needed, as there are already implied rules on a property that should handle that. I'd start with just the "first explicit" scoping to be more conservative, and then see if we find any use-cases that (and existing implied rules) don't/doesn't catch. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
**** Agreement at [[2015-01-20]] meetup.
</div>

For example:

<code><pre>
<div class="h-entry">
<div class="u-in-reply-to h-cite">
<a class="p-author h-card" href="http://example.com">Example Author</a>
<a class="p-name u-url" href="http://example.com/post">Example Post</a>
</div>
</div>
</pre></code>

The nested u-in-reply-to object would parse as

<code><pre>
...
"in-reply-to": [{
"type": ["h-cite"],
"properties": {
"name": ["Example Post"],
"url": ["http://example.com/post"],
"author": [{
"type":["h-card"],
"properties": {
"url": ["http://example.com"],
"name": ["Example Author"]
},
"value": "Example Author"
}],
},
"value": "http://example.com/post"
}]
...
</pre></code>

where the outer "value" gets the in-reply-to h-cite's u-url property, and the inner "value" gets the author's p-name property.

<div class="discussion">
* Because there are no implied properties of the dt-* and e-* types, and no obvious defaults, the value rules for these types would not change.
** A possibility for dt-* h-*: The dt-* could take either the first dt-* of the h-*, or (perhaps if no dt-* in the h-*,) the first <code><time></code> element inside. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** First dt-* seems reasonable, predictable, and usable. Consensus at [[2015-01-20]] meetup.
** Update 2015-05-29: no known use-cases for first dt-* or first e-*, and implementing that "would require some refactoring" (in mf2py at least per kylewm), thus until there's a use-case for first dt-*/e-* inside, let's treat "dt-* h-*" and "e-* h-*" as before. [[User:Tantek|Tantek]] . In particular:
*** p-* h-* - value from first "name" as proposed above
*** u-* h-* - value from first "url" as proposed above
*** e-* h-* - value is already defined for e-* parsing, nothing special here
*** dt-* h-* - value from normal dt-* parsing - nothing special.
*** +1 totally agree, let's wait for use cases of e-* dt-* [[User:Kylewm|Kylewm]] 19:44, 29 May 2015 (UTC)
</div>

* Implemented in mf2py 2015-06-01 https://github.com/tommorris/mf2py/commit/edc895ef5a780bcee654e6644a688688934517b0
* Added to microformats test suite (experimental) 2015-06-01 https://github.com/microformats/tests/commit/90c8a7d8e96c7160036a298e13f16d9ddaec218e

== see also ==
* [[microformats2]]
* [[microformats2-brainstorming]]
* [[microformats2-prefixes]]
* [[microformats2-faq]]
* [[microformats2-issues]]
* [[microformats2-parsing-faq]]

microformats2-parsing-brainstorming

2016-05-07T16:57:57Z

Kylewm: /* Pronouns */ discussion

<entry-title>microformats2 parsing brainstorming</entry-title>

This page is for brainstorming, discussion, and other questions and explorations about [[microformats2]] parsing.

For the microformats2 parsing algorithm, see:
* [[microformats2-parsing]]

For filing issues / problems with microformats2-parsing, see:
* [[microformats2-parsing-issues]]

__TOC__

== Parse language information ==
Raised by [[User:VoxPelli|VoxPelli]] 18:04, 23 July 2015 (UTC)
* 2016-060: Update: and parse "id" attribute. [[User:Tantek|Tantek]] 16:39, 29 February 2016 (UTC) (see Additionally below)

Currently there’s no way to tell the language of parsed microformats even if those microformats has been marked up with HTML "lang"-attributes.

There are examples in the wild of people marking up pages in such a way:

* [http://voxpelli.com/ VoxPelli.com] has a "lang"-attribute on the h-entry of his [http://voxpelli.com/2011/03/sista-dagen-p-good-old/ swedish articles] to signify that the article is swedish even though the rest of the site is english.
* Stephanie [http://climbtothestars.org/archives/2013/09/17/basic-bilingual-1-0-plugin-for-wordpress-blog-in-more-than-one-language/ uses a WordPress plugin] that adds summaries of other languages at the start of her content.

Proposal is to add a new "lang" keyword to h-* and e-* objects so that the following example:

<source lang=html4strict>
<div class="h-entry" lang="sv">
<h1 class="p-name">En svensk titel</h1>
<div class="e-content" lang="en">With an <em>english</em> summary</div>
<div class="e-content">Och <em>svensk</em> huvudtext</div>
</div>
</source>

Would be parsed into something like:

<source lang=javascript>
{
"type": ["h-entry"],
"lang": "sv",
"properties": {
"name": ["En svensk titel"],
"content": [
{
"lang": "en",
"html": "With an <em>english</em> summary",
"value": "With an english summary"
},
{
"html": "Och <em>svensk</em> huvudtext",
"value": "Och svensk huvudtext"
}
]
}
}
</source>

This was [http://indiewebcamp.com/irc/2015-07-23#t1437667712078 brainstormed on the IndieWebCamp IRC-channel] where the mentioned example came up.

* Pull request for implementation in microformat-node added 2015-07-23 https://github.com/glennjones/microformat-node/pull/23

Additionally: consider the same for "id" attributes (use-case: rel=feed local discovery of a nested h-feed on the home page), specifically, parsing the first instance of any "id" attribute (ignoring latter duplicate id attribute values on any subsequent elements).

And alternatively: consider parsing as "html-id" and "html-lang" prefixed properties in the parsed result, e.g.

<source lang=html4strict>
<div class="h-entry" lang="sv" id="postfrag123">
<h1 class="p-name">En svensk titel</h1>
<div class="e-content" lang="en">With an <em>english</em> summary</div>
<div class="e-content">Och <em>svensk</em> huvudtext</div>
</div>
</source>

Would be parsed into something like:

<source lang=javascript>
{
"type": ["h-entry"],
"html-id": "postfrag123",
"html-lang": "sv",
"properties": {
"name": ["En svensk titel"],
"content": [
{
"html-lang": "en",
"html": "With an <em>english</em> summary",
"value": "With an english summary"
},
{
"html": "Och <em>svensk</em> huvudtext",
"value": "Och svensk huvudtext"
}
]
}
}
</source>

=== Pronouns in different languages ===

Language is also useful context when defining [[pronouns]], discussed a bit here[https://github.com/idno/Known/pull/1426#issuecomment-217626923].

<source lang=html4strict>
<div class="h-card" lang="en">
<span class="p-x-pronoun-nominative">he</span> /
<span class="p-x-pronoun-possessive">him</span> /
<span class="p-x-pronoun-oblique">his</span>
</div>
</source>

would parse as

<source lang=javascript>
{
"type": ["h-card"],
"lang": "en",
"properties": {
"x-pronoun-nominative": ["he"],
"x-pronoun-possessive": ["him"],
"x-pronoun-oblique": ["his"]
}
}
</source>

It could also be useful to specify multiple languages within a single h-card (pardon me if I butcher Swedish pronouns)

<source lang=html4strict>
<div class="h-card">
<span lang="en" class="p-x-pronoun-nominative">he</span> /
<span lang="en" class="p-x-pronoun-possessive">him</span> /
<span lang="en" class="p-x-pronoun-oblique">his</span>
<span lang="sv" class="p-x-pronoun-nominative">han</span> /
<span lang="sv" class="p-x-pronoun-possessive">hans</span> /
<span lang="sv" class="p-x-pronoun-oblique">honom</span>
</div>
</source>

which might parse as

<source lang=javascript>
{
"type": ["h-card"],
"properties": {
"x-pronoun-nominative": [{"lang": "en", "value": "he"}, {"lang": "sv", "value": "han"}],
"x-pronoun-possessive": [{"lang": "en", "value": "him"}, {"lang": "sv", "value": "hans"}],
"x-pronoun-oblique": [{"lang": "en", "value": "his"}, {"lang": "sv", "value": "honom"}]
}
}
</source>

or alternatively, we could introduce a new microformat h-x-pronoun to wrap a set of pronouns

<source lang=html4strict>
<div class="h-card">
<div class="p-x-pronoun h-x-pronoun" lang="en">
<span class="p-nominative">he</span> /
<span class="p-possessive">him</span> /
<span class="p-oblique">his</span>
</div>
<div class="p-x-pronoun h-x-pronoun" lang="en">
<span class="p-nominative">han</span> /
<span class="p-possessive">hans</span> /
<span class="p-oblique">honom</span>
</div>
</div>
</source>

parsed as

<source lang=javascript>
{
"type": ["h-card"],
"properties": {
"x-pronoun": [{
"type": ["h-x-pronoun"],
"lang": "en",
"properties": {
"nominative": ["he"],
"possessive": ["him"],
"oblique": ["his"]
}
}, {
"type": ["h-x-pronoun"],
"lang": "sv",
"properties": {
"nominative": ["han"],
"possessive": ["hans"],
"oblique": ["honom"]
}
}]
}
}
</source>

<div class="discussion">
Discussion:
* [[User:Kylewm|Kylewm]] Including the "lang" attribute in h- and e- properties makes a ton of sense to me.
* [[User:Kylewm|Kylewm]] I like the idea of introducing an h-x-pronoun container that can define all the different pronoun forms for a particular language
* ...

</div>

== Canonicalization of datetime output ==
Status: resolved, awaiting implementation attempt/experience.

It would be useful to choose a (more) uniform output format for datetimes to make it easier for users of the parser to consume datetimes. Microformats2 parsers already do sophisticated pattern matching to recognize date vs. time vs. datetimes, so converting this to any specific format should not add overhead.

<div class="discussion">
Specifically:
* Choose either 'T' or space as the date/time separator.
** Prefer space as it is more human friendly/readable, which matters even for syntaxes/formats, as human still develop, debug them. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* Choose either +XXYY or +XX:YY as the timezone specification (and convert 'Z' to +0000).
** Would appreciate some study / input here as to which timezone offset syntax is more human friendly. I lean slightly toward +/-NNNN (without the colon) because in the context of seeing a time, leaving out the colon makes it less likely the offset will be confused for a time. E.g. "07:00-08:00" looks like 7-8am, even if it meant 07:00 in PST. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** Space is fine - consensus [[2015-01-20]] meetup.
* Parsers should ''not'' attempt make datetimes more exact than specified. They should not add time, seconds, or timezone if omitted in the original. [[User:Kylewm|Kylewm]] 04:02, 14 May 2014 (UTC)
** Agreed. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** or month, day per Tom Morris
** consensus [[2015-01-20]] meetup

* Counterpoint: PHP's builtin date parsing does not require strict formatting. And the equivalent functionality for Python is provided by the widely used python-dateutil library. [[User:Kylewm|Kylewm]] 19:02, 14 May 2014 (UTC)
** However we cannot (must not) depend on either PHP or Python's "smart" "fixing" or Postelian "liberal handling", or any other language/framework's for that matter, as they all differ in how "intelligent" they are. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
</div>

Perhaps just provide a guideline for these based on the above consensus.

== Add meta http-equiv to microformats2 parsing model ==
Status: disagreement, awaiting implementation attempt/experience.

Similar to document level parsing of <code>rel</code> attributes, it makes sense simultaneously to parse <code><meta http-equiv></code> elements, perhaps treating "Status" in a special way (only using first number (sequence of digits) for its "value").

Use case: IndieWeb "deleted" indication inline in content for static file services that don't support HTTP return codes.
* http://indiewebcamp.com/deleted#HTML_meta_http-equiv_for_status

HTTP Header example:
* <samp>Content-Type: text/html; charset=utf-8</samp>
HTML equivalent:
* <code><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></code>

Related:
* https://www.w3.org/International/O-HTTP-charset

<div class="discussion">
* Interesting thought. Are you suggesting a top level "http-equivs:" collection similar to "rels:" in the parsed output? Should we consider "metas:" instead or in addition? [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* What's the use case for this? Also, http-equiv on its own is useless. http-equiv is only a supplement to the data stored in headers. And headers aren't always there: what happens in the context of someone debugging a page who pastes the source into the textarea of an mf2 parser? Without a compelling use case for including headers (and then over-riding some of them with http-equivs), I'm not sure why an implementor want to do this. —[[User:TomMorris|Tom Morris]] 00:25, 8 May 2015 (UTC)
</div>

E.g. from https://gist.github.com/aaronpk/10297489

<source lang="html4strict">
<meta http-equiv="Status" content="410 GONE"/>
</source>

<source lang="javascript">
{
"items": [],
"rels": {},
"http": {
"status": 410
}
}
</source>

<div class="discussion">
* Maybe make this an optional pass in the parser? - Tom Morris [[2015-01-20]]
* For now, don't bother with metas until someone provides a use-case. Tom Morris
* Agreed on both counts. [[User:Tantek|Tantek]] 06:56, 21 January 2015 (UTC)
</div>

==MIME type==
See [[microformats2-mime-type]]

----

==Other Interpretation Parsing Notes==
Note: most of these need to be written up as separate [[microformats2-parsing-issues]]

Author: [[User:BenWard|Ben Ward]]

[[microformats-2|Microformats 2]] proposes a new, all encompassing syntax modification of [[microformats-2-prefixes|prefixes]] that will allow microformats to be parsed from pages by processors without prior knowledge of a vocabulary. The core components of this model are quite simple, are quite simple to implement, but there are a number of conflicts that emerge with the functionality of existing microformats parsers that need to be handled. This page documents a proposed model to separate these concerns clearly in a way that can be applied to the documentation of generic microformats parsing rules, and the documentation of individual vocabularies.

Collection of other unresolved parsing issues in a generic model:

This is good material for documenting as [[microformats-2-issues]], [[microformats-2-faq]], and perhaps some of the more technical details in [[microformats-2-parsing-faq]].

* The include pattern references other elements from elsewhere in a document. A generic parser needs to track IDs and fill them in after walking the DOM. (also, <code>itemref</code> if adopted.)
** The current thinking per [[microformats-2-brainstorming]] is to adopt <code>itemref</code> and drop the [[include-pattern]]. [[User:Tantek|Tantek]]
* Will <code>itemref</code> always map to an <code>item</code> property name?
** No, <code>itemref</code> maps to one or more elements by ids, and their children. Those referenced elements may have property class names themselves, or they may contain elements that do. [[User:Tantek|Tantek]]
* [[hAtom]] implies <code>author</code> from an hCard in a page that uses an <code>address</code> element. This requires format knowledge, but a generic parser does not currently track the element type of a property node. Should it?
** It should not. element-specific handling (e.g. using "alt" from img, and "title" from abbr) is completely done at parse time. The JSON data model does not reflect which element type or attribute the value came from. Additionally, [[hAtom]] is an example where we created far too many vocabulary-specific rules, in practice they're not necessary, and only complicate the microformat for both publisher understanding and parser implementation. [[User:Tantek|Tantek]]
* [[hAtom]] defines that the highest level heading within an entry implies <code>entry-title</code>. This particular optimisation might be better off dead.
** Agreed, this is gone in microformats 2. [[User:Tantek|Tantek]]
* [[hAtom]] defines that permalinks be parsed from <code>rel</code> attributes, not <code>class</code>
** In practice this has been one of the more problematic/error prone aspects of hAtom implementations, and it's also inconsistent with other microformats (although [[hReview]] tried to use both rel permalinks and "url"). The dependence upon [[rel-bookmark]] for permalinks is dropped in h-atom in preference to re-using "u-url" and "u-uid". [[User:Tantek|Tantek]]
* [[XFN]] is entirely built on <code>rel</code> (although, has various other differences from structural microformats, as do vote-links, so perhaps are excluded from this discussion and will always be handled by dedicated parsers/queries regardless?)
** The best (easiest and most reliable) use of 'rel' microformats in practice is when they are orthogonal to 'class' microformats. This is true both with [[XFN]] and some newer [[existing-rel-values|rel values]] like [[rel-author]]. In addition, it was very clear at the recent [[schema.org]] workshop's syntax session that RDFa's decision to apparently arbitrarily mix use of 'rel' and 'property' attributes for specifying different types of properties (it wasn't clear to people in the room when you use which for what) has caused a high degree of confusion among publishers and thus high error-rates. Thus if anything we should learn from both the mistakes of RDFa and our own experiences with even very deliberate/specific mixing of rel microformats in class microformats, and keep them defined as separate orthogonal building blocks that work together, but don't depend on each other. [[User:Tantek|Tantek]]
*** Relatedly to this: <code>rel-tag</code> in hAtom. --[[User:BenWard|BenWard]] 06:50, 5 October 2011 (UTC)
**** Yes, and two related things here. First, despite my (and others') objection and (past) interoperable post/entry-specific treatment by Technorati and Ice Rocket, Hixie has redefined rel-tag in [[HTML5]] to mean applying to the whole page, not a single post. Second, I've explicitly added 'p-category' to the draft 'h-atom' vocabulary in [[microformats-2]]. [[User:Tantek|Tantek]] 07:12, 5 October 2011 (UTC)
* HTML's <code>time</code> element includes an optional <code>pubdate</code> attribute. Simply: We should parse this as <code>dt-published</code>. --[[User:BenWard|BenWard]] 06:12, 10 October 2011 (UTC)
** *If* there is even some reasonable data on actual use of the "pubdate" attribute (I don't think there is, frankly, especially with the removal of the algorithm to produce Atom from HTML5), then we could consider parsing "pubdate" as backwards compatible option for "dt-published". As a general rule, however, it is bad (demonstrably/experienced) design to depend on additional attributes (c.f. RDFa confusion over "property" vs. "rel"), especially for an instance where no additional attribute is necessary. I would leave this out for now until there is non-trivial (more than just test pages or folks who've written HTML5 books, ahem) use in the wild. When there is such use in the wild, it should be documented on a wiki page. We don't want to encourage more complex (additional attribute) publishing as a result of supporting it. [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)
* [[value-class-pattern]]: In microformats-2, since there are no sub-properties, there will presumably no-longer be a 'value' property in any parsed model. Properties such as 'tel > type' in hCard are, as I recall, deprecated due to underuse anyway, so 'tel > value' becomes redundant. (There's also potentially some clarification around 'price > value' in hListing, whereby value was used in a pattern. So, what does this mean for value class parsing, with regard to value-title patterns and date separation patterns. Are we looking for a 'p-value' and 'p-value-title' classname, but treating them specially (excluding them from regular property parsing.) Or, are we giving them a special prefix (v-text, v-title? That seems confusing, but could be a concept.) I'm fine with p- for both, and just having the parser ignore them since they're special, but need clarification and naming confirmation. --[[User:BenWard|BenWard]] 09:35, 10 October 2011 (UTC)
** A few things:
*** 1. Yes, no more subproperties. 'tel' becomes just 'p-tel'. If there is demand for a structured 'tel' value, then we can use that demand (and research into publishing in practice) to brainstorm and create an 'h-tel' structured telephone number (with perhaps fields like 'type', 'extension', some indication of it being local dialing (an extra 0 in some countries) or international dialing, etc.) Or, we address the different 'tel' types as their own flat properties (again as justified by research), e.g. perhaps 'p-tel-fax', or 'p-tel-mobile'. Something for hcard-2-brainstorming.
*** 2. For prices, e.g. hListing, either we're going to need to encode how to parse monetary amounts including monetary symbols, or consider creating an 'h-price' structured price. Not sure what the right answer is here, again, will need to be informed by analysis of documented actual price publication practices.
*** 3. We should avoid introducing a new prefix 'v-' just for value-class-pattern. As we've noted elsewhere, each new prefix adds complexity and should be avoided without substantial advantage.
*** 4. Using 'p-value-title' is strange, as it would be an exception to 'p-' parsing, since it would get the value from the 'title' attribute whereas 'p-' properties don't normally do that (exception: abbr).
*** 5. Using 'p-value' is also strange, as it wouldn't generate a 'value' property in the JSON data model.
*** 6. Class name 'value-title' is already sufficiently prefixed - we've found or even heard of no collisions in practice.
*** 7. Class name 'value' can, by its simpler naming nature, be expected to potentially collide with other web designer class name usage though we have no documentation/mention thereof. We could consider a renaming, or providing of alternative, such as 'value-string', or 'value-content', etc. However, let's keep that as a backup plan to use only if/when evidence is presented that we need to.
** Conclusions: for now, in microformats-2, keep using 'value' and 'value-title' as defined in the [[value-class-pattern]], and add the additional (obvious) interpretation that [[value-class-pattern#Date_and_time_parsing|value class pattern: date and time parsing]] applies to all 'dt-' properties. - [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)

== incorporated 2015-05-28 ==
The following brainstorms were incorporated 2015-05-28.

== more information for alternates ==
Raised 2015-04-24 by [[User:Kevin Marks|Kevin Marks]]

The existing <code>alternate</code> parsing is omitting <code>title</code> - that should be added. The <code>text</code> would make sense to add here too.

Use-case: labels for presenting alternates

<div class="discussion">
* +1 Makes sense. [[User:Tantek|Tantek]] 03:41, 25 April 2015 (UTC)
</div>

== more information for rel-based formats ==
Raised 2015-04-18 by [[User:Kevin Marks|Kevin Marks]]

Related github test suite issue: https://github.com/microformats/tests/issues/16

Several rel-based formats have additional information that is useful beyond the link itself, which is all we capture at the moment. As I am trying to update the Universal feedparser to support mf2 based I will show examples from the [https://github.com/kevinmarks/feedparser/tree/365623a9470e99246f393a8c1f49a0db567826b8/feedparser/tests/microformats testcases] there.

The main change is to add a <code>rel-urls</code> entry for more information about the attributes and text of the urls pointed to by rel's in the document

A fork of mf2py that implements these changes is at https://github.com/kevinmarks/mf2py
=== rel-tag ===

<code><a rel="tag" href="http://del.icio.us/tag/tech">Technology</a> </code>

currently parses to:

<code>{"rels": {"tag": ["http://del.icio.us/tag/tech"]}, "items": []} </code>

This loses the link text, which is useful as a label.

We add a <code>rel-urls</code> element to the parsed output with this extra data that can be looked up from the rels, which doesn't break backward compatibility and works better with xfn (see below)

<code><pre>
{
"rels": {
"tag": [
"http://del.icio.us/tag/tech"
]
},
"items": [],
"rel-urls": {
"http://del.icio.us/tag/tech": {
"rels": [
"tag"
],
"text": "Technology"
}
}
}
</pre></code>

=== xfn ===

<code><a rel="coworker" href="http://example.com/johndoe">John Doe</a></code>

currently parses to:

<code>{"rels": {"coworker": ["http://example.com/johndoe"]}, "items": []}</code>

This loses the link text, which is the person's name. Suggested output using the urls object:

<code><pre>
{
{
"rels": {
"coworker": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker"
],
"text": "John Doe"
}
}
}
</pre></code>

with multiple xfn values

<code><a rel="coworker friend" href="http://example.com/johndoe">John Doe</a></code>
we get this:

<code><pre>
{
"rels": {
"coworker": [
"http://example.com/johndoe"
],
"friend": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker",
"friend"
],
"text": "John Doe"
}
}
}
</pre></code>

=== rel-enclosure ===

<code><a rel="enclosure" href="http://example.com/movie.mp4" type="video/mpeg" title="real title">my movie</a></code>

currently parses to:

<code>'{"rels": {"enclosure": ["http://example.com/movie.mp4"]}, "items": []}'</code>

This loses the link text, which is the title and the attributes which give type. Suggested output:

<code><pre>
{
"rels": {
"enclosure": [
"http://example.com/movie.mp4"
]
},
"items": [],
"rel-urls": {
"http://example.com/movie.mp4": {
"rels": [
"enclosure"
],
"text": "my movie",
"type": "video/mpeg",
"title": "real title"
}
}
}
</pre></code>

This generalises to other rel's too, such as [[rel-feed]] and [[rel-alternate]] that have type, lang etc attributes.

(updated to include changes from feedback below) [[User:Kevin Marks|Kevin Marks]] 22:13, 26 April 2015 (UTC)

=== attributes parsed ===
Attributes currently parsed are:
* <code>hreflang</code> for alternate and enclosure
* <code>media</code> for alternate and enclosure
* <code>title</code> for alternate and enclosure
* <code>type</code> for alternate and enclosure

Attributes we may consider parsing if we have a use case are
* <code>sizes</code> for icon - need use-case documentation
* <code>coords</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats
* <code>shape</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats

In addition there is a special attribute <s><code>name</code> </s><code>text</code> which is the text contents of the link, which is useful in rel-tag rel-enclosure and xfn, and in alternate when used for feeds. It's also clarifying for rel-me links.

Tantek [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79057 suggests] we use <code>textContent</code> for this instead, and make it a single string, not a list as <code>name</code> is elsewhere in mf2 parsing
* Update: "text" is good enough, and "textContent" is ugly camelCase. [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)

=== feedback on more rel info ===
<div class="discussion">
# "name" is bad because it misleadingly conflates with use of "name" elsewhere in microformats2.
#* Suggested alternative: [https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent textContent] - since that's literally what is being returned there. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** as all other mf2 keys are lowercase-with-hyphens, [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79101 Tantek suggests] 'text' as that isn't going to be an html [[User:Kevin Marks|Kevin Marks]] 07:28, 25 April 2015 (UTC)
# no need for array for "name"/textContent - since there is always only one at most
#* E.g. should be "textContent": "my movie" [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#* Update: "text": "my movie" [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)
# "urls" key is misleading - implies all URLs in the document, which is neither true, nor desired (takes much more parsing time and work and code)
#* Suggested alternative: "rel-urls". And open to better alternatives too. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** If we are trying to extend the number of properties retuned from a rel without breaking the old structure why don't we call the new structure something like "rels-extended" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#*** Extension is not the point, but rather to use them complementary. One structure for look-up of any rel value, hence "rels", which returns you a list of URLs. Then you can lookup those URLs in the new mapping, by URL, hence it is called "rel-urls" - that's the point to use them in conjunction and that's why rel-urls is named what it is. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

# Why is the structure of "rel-urls" different to the "alternates" structure. Should the "url" not just be added as a property and not as a key. Creating two data structures for one type of object seems inconsistent. It adds cognitive load to anyone trying to understand the JSON structure [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* I was trying to avoid breaking the existing <code>rels</code> structure and use of it - I did implement a variant that put the structure inside rels, and it became cumbersome and repetitive where there were multiple rels on a url (xfn cases). Denormalising as properties of the URL made more sense. It also dedupes if there is repetitive linking to the same URL, eg a series of posts with rel-author on each. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
# If the rel is a "tag" then the main value we need to return should be the last path component of the URL, not the link text? Should we add another output property ie "tag" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* No need to return last path segment of the URL, because the URL is already there - and that's just a library/framework utility function to get the last path segment of a URL. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)
# As currently described, the URL from <code>alternates</code> is repeated in the <code>rel-urls</code> structure. If we are doing this, surely <code>alternate</code> should be in <code>rels</code> too? I assumed a mapping between them. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
## edit showing this variant: http://microformats.org/wiki/index.php?title=microformats2-parsing&oldid=65021#parse_a_hyperlink_element_for_rel_microformats
</div>
#* Yes it makes sense to drop "alternates" assuming the backcompat impact is low, put alternates in "rels" along with everything else, and direct people to use rels and rel-urls for alternates functionality. Evidence this is an acceptable even preferable approach.[http://indiewebcamp.com/irc/2015-06-01/line/1433195247005] Will add an issue accordingly. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

== Incorporated 2015-06-06 ==

== Nested h-* objects' "value" property ==
Status: resolved, resolution iterated, one real world implementation proven implementability, incorporated
* 2015-06-06 incorporated into [[microformats2-parsing]]

Raised 2015-01-06 by [[User:Kylewm]];

If a child element has a microformat (h-*) and is a property element (p-*, u-*, dt-*, e-*), the parser will add a "value" property to the resulting object. The value should attempt to be a useful representation of the object for consumers that do not have semantic knowledge of the particular h-* type. Ref: [[microformats2-parsing#parse_an_element_for_class_microformats]].

To determine the "value", we parse the property element simply (as if it did not have a h-* class), which works well for simple h-* objects, e.g. <code><a class="u-like-of h-cite" href="...">...</a></code>

<div class="discussion">
* To handle more complex microformats, I propose that "value" for a p-* property element take on the first explicit "name" property of the nested microformat, and for a u-* property, the first explicit "url" property. Parsing will fall back on the current rules if an explicit property does not exist.
** This makes sense to me, and fits with the use-cases and examples I've seen. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** A similar (possibly simpler?) formulation would use the implied name and url rules to determine the "value" for p-* and u-* properties respectively
*** I don't think that's needed, as there are already implied rules on a property that should handle that. I'd start with just the "first explicit" scoping to be more conservative, and then see if we find any use-cases that (and existing implied rules) don't/doesn't catch. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
**** Agreement at [[2015-01-20]] meetup.
</div>

For example:

<code><pre>
<div class="h-entry">
<div class="u-in-reply-to h-cite">
<a class="p-author h-card" href="http://example.com">Example Author</a>
<a class="p-name u-url" href="http://example.com/post">Example Post</a>
</div>
</div>
</pre></code>

The nested u-in-reply-to object would parse as

<code><pre>
...
"in-reply-to": [{
"type": ["h-cite"],
"properties": {
"name": ["Example Post"],
"url": ["http://example.com/post"],
"author": [{
"type":["h-card"],
"properties": {
"url": ["http://example.com"],
"name": ["Example Author"]
},
"value": "Example Author"
}],
},
"value": "http://example.com/post"
}]
...
</pre></code>

where the outer "value" gets the in-reply-to h-cite's u-url property, and the inner "value" gets the author's p-name property.

<div class="discussion">
* Because there are no implied properties of the dt-* and e-* types, and no obvious defaults, the value rules for these types would not change.
** A possibility for dt-* h-*: The dt-* could take either the first dt-* of the h-*, or (perhaps if no dt-* in the h-*,) the first <code><time></code> element inside. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** First dt-* seems reasonable, predictable, and usable. Consensus at [[2015-01-20]] meetup.
** Update 2015-05-29: no known use-cases for first dt-* or first e-*, and implementing that "would require some refactoring" (in mf2py at least per kylewm), thus until there's a use-case for first dt-*/e-* inside, let's treat "dt-* h-*" and "e-* h-*" as before. [[User:Tantek|Tantek]] . In particular:
*** p-* h-* - value from first "name" as proposed above
*** u-* h-* - value from first "url" as proposed above
*** e-* h-* - value is already defined for e-* parsing, nothing special here
*** dt-* h-* - value from normal dt-* parsing - nothing special.
*** +1 totally agree, let's wait for use cases of e-* dt-* [[User:Kylewm|Kylewm]] 19:44, 29 May 2015 (UTC)
</div>

* Implemented in mf2py 2015-06-01 https://github.com/tommorris/mf2py/commit/edc895ef5a780bcee654e6644a688688934517b0
* Added to microformats test suite (experimental) 2015-06-01 https://github.com/microformats/tests/commit/90c8a7d8e96c7160036a298e13f16d9ddaec218e

== see also ==
* [[microformats2]]
* [[microformats2-brainstorming]]
* [[microformats2-prefixes]]
* [[microformats2-faq]]
* [[microformats2-issues]]
* [[microformats2-parsing-faq]]

microformats2-parsing-brainstorming

2016-05-07T16:54:19Z

Kylewm: /* Parse language information */ add section brainstorming possible markup for i8n pronouns

<entry-title>microformats2 parsing brainstorming</entry-title>

This page is for brainstorming, discussion, and other questions and explorations about [[microformats2]] parsing.

For the microformats2 parsing algorithm, see:
* [[microformats2-parsing]]

For filing issues / problems with microformats2-parsing, see:
* [[microformats2-parsing-issues]]

__TOC__

== Parse language information ==
Raised by [[User:VoxPelli|VoxPelli]] 18:04, 23 July 2015 (UTC)
* 2016-060: Update: and parse "id" attribute. [[User:Tantek|Tantek]] 16:39, 29 February 2016 (UTC) (see Additionally below)

Currently there’s no way to tell the language of parsed microformats even if those microformats has been marked up with HTML "lang"-attributes.

There are examples in the wild of people marking up pages in such a way:

* [http://voxpelli.com/ VoxPelli.com] has a "lang"-attribute on the h-entry of his [http://voxpelli.com/2011/03/sista-dagen-p-good-old/ swedish articles] to signify that the article is swedish even though the rest of the site is english.
* Stephanie [http://climbtothestars.org/archives/2013/09/17/basic-bilingual-1-0-plugin-for-wordpress-blog-in-more-than-one-language/ uses a WordPress plugin] that adds summaries of other languages at the start of her content.

Proposal is to add a new "lang" keyword to h-* and e-* objects so that the following example:

<source lang=html4strict>
<div class="h-entry" lang="sv">
<h1 class="p-name">En svensk titel</h1>
<div class="e-content" lang="en">With an <em>english</em> summary</div>
<div class="e-content">Och <em>svensk</em> huvudtext</div>
</div>
</source>

Would be parsed into something like:

<source lang=javascript>
{
"type": ["h-entry"],
"lang": "sv",
"properties": {
"name": ["En svensk titel"],
"content": [
{
"lang": "en",
"html": "With an <em>english</em> summary",
"value": "With an english summary"
},
{
"html": "Och <em>svensk</em> huvudtext",
"value": "Och svensk huvudtext"
}
]
}
}
</source>

This was [http://indiewebcamp.com/irc/2015-07-23#t1437667712078 brainstormed on the IndieWebCamp IRC-channel] where the mentioned example came up.

* Pull request for implementation in microformat-node added 2015-07-23 https://github.com/glennjones/microformat-node/pull/23

Additionally: consider the same for "id" attributes (use-case: rel=feed local discovery of a nested h-feed on the home page), specifically, parsing the first instance of any "id" attribute (ignoring latter duplicate id attribute values on any subsequent elements).

And alternatively: consider parsing as "html-id" and "html-lang" prefixed properties in the parsed result, e.g.

<source lang=html4strict>
<div class="h-entry" lang="sv" id="postfrag123">
<h1 class="p-name">En svensk titel</h1>
<div class="e-content" lang="en">With an <em>english</em> summary</div>
<div class="e-content">Och <em>svensk</em> huvudtext</div>
</div>
</source>

Would be parsed into something like:

<source lang=javascript>
{
"type": ["h-entry"],
"html-id": "postfrag123",
"html-lang": "sv",
"properties": {
"name": ["En svensk titel"],
"content": [
{
"html-lang": "en",
"html": "With an <em>english</em> summary",
"value": "With an english summary"
},
{
"html": "Och <em>svensk</em> huvudtext",
"value": "Och svensk huvudtext"
}
]
}
}
</source>

=== Pronouns ===

Language is also useful context when defining [[pronouns]], discussed a bit here[https://github.com/idno/Known/pull/1426#issuecomment-217626923].

<source lang=html4strict>
<div class="h-card" lang="en">
<span class="p-x-pronoun-nominative">he</span> /
<span class="p-x-pronoun-possessive">him</span> /
<span class="p-x-pronoun-oblique">his</span>
</div>
</source>

would parse as

<source lang=javascript>
{
"type": ["h-card"],
"lang": "en",
"properties": {
"x-pronoun-nominative": ["he"],
"x-pronoun-possessive": ["him"],
"x-pronoun-oblique": ["his"]
}
}
</source>

It could also be useful to specify multiple languages within a single h-card (pardon my possible butchering of Swedish pronouns)

<source lang=html4strict>
<div class="h-card">
<span lang="en" class="p-x-pronoun-nominative">he</span> /
<span lang="en" class="p-x-pronoun-possessive">him</span> /
<span lang="en" class="p-x-pronoun-oblique">his</span>
<span lang="sv" class="p-x-pronoun-nominative">han</span> /
<span lang="sv" class="p-x-pronoun-possessive">hans</span> /
<span lang="sv" class="p-x-pronoun-oblique">honom</span>
</div>
</source>

which might parse as

<source lang=javascript>
{
"type": ["h-card"],
"properties": {
"x-pronoun-nominative": [{"lang": "en", "value": "he"}, {"lang": "sv", "value": "han"}],
"x-pronoun-possessive": [{"lang": "en", "value": "him"}, {"lang": "sv", "value": "hans"}],
"x-pronoun-oblique": [{"lang": "en", "value": "his"}, {"lang": "sv", "value": "honom"}]
}
}
</source>

or alternatively, we could introduce a new microformat h-pronoun

<source lang=html4strict>
<div class="h-card">
<div class="p-x-pronoun h-x-pronoun" lang="en">
<span class="p-nominative">he</span> /
<span class="p-possessive">him</span> /
<span class="p-oblique">his</span>
</div>
<div class="p-x-pronoun h-x-pronoun" lang="en">
<span class="p-nominative">han</span> /
<span class="p-possessive">hans</span> /
<span class="p-oblique">honom</span>
</div>
</div>
</source>

parsed as

<source lang=javascript>
{
"type": ["h-card"],
"properties": {
"x-pronoun": [{
"type": ["h-x-pronoun"],
"lang": "en",
"properties": {
"nominative": ["he"],
"possessive": ["him"],
"oblique": ["his"]
}
}, {
"type": ["h-x-pronoun"],
"lang": "sv",
"properties": {
"nominative": ["han"],
"possessive": ["hans"],
"oblique": ["honom"]
}
}]
}
}
</source>

<div class="discussion">
Discussion:
* ...

</div>

== Canonicalization of datetime output ==
Status: resolved, awaiting implementation attempt/experience.

It would be useful to choose a (more) uniform output format for datetimes to make it easier for users of the parser to consume datetimes. Microformats2 parsers already do sophisticated pattern matching to recognize date vs. time vs. datetimes, so converting this to any specific format should not add overhead.

<div class="discussion">
Specifically:
* Choose either 'T' or space as the date/time separator.
** Prefer space as it is more human friendly/readable, which matters even for syntaxes/formats, as human still develop, debug them. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* Choose either +XXYY or +XX:YY as the timezone specification (and convert 'Z' to +0000).
** Would appreciate some study / input here as to which timezone offset syntax is more human friendly. I lean slightly toward +/-NNNN (without the colon) because in the context of seeing a time, leaving out the colon makes it less likely the offset will be confused for a time. E.g. "07:00-08:00" looks like 7-8am, even if it meant 07:00 in PST. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** Space is fine - consensus [[2015-01-20]] meetup.
* Parsers should ''not'' attempt make datetimes more exact than specified. They should not add time, seconds, or timezone if omitted in the original. [[User:Kylewm|Kylewm]] 04:02, 14 May 2014 (UTC)
** Agreed. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** or month, day per Tom Morris
** consensus [[2015-01-20]] meetup

* Counterpoint: PHP's builtin date parsing does not require strict formatting. And the equivalent functionality for Python is provided by the widely used python-dateutil library. [[User:Kylewm|Kylewm]] 19:02, 14 May 2014 (UTC)
** However we cannot (must not) depend on either PHP or Python's "smart" "fixing" or Postelian "liberal handling", or any other language/framework's for that matter, as they all differ in how "intelligent" they are. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
</div>

Perhaps just provide a guideline for these based on the above consensus.

== Add meta http-equiv to microformats2 parsing model ==
Status: disagreement, awaiting implementation attempt/experience.

Similar to document level parsing of <code>rel</code> attributes, it makes sense simultaneously to parse <code><meta http-equiv></code> elements, perhaps treating "Status" in a special way (only using first number (sequence of digits) for its "value").

Use case: IndieWeb "deleted" indication inline in content for static file services that don't support HTTP return codes.
* http://indiewebcamp.com/deleted#HTML_meta_http-equiv_for_status

HTTP Header example:
* <samp>Content-Type: text/html; charset=utf-8</samp>
HTML equivalent:
* <code><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></code>

Related:
* https://www.w3.org/International/O-HTTP-charset

<div class="discussion">
* Interesting thought. Are you suggesting a top level "http-equivs:" collection similar to "rels:" in the parsed output? Should we consider "metas:" instead or in addition? [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* What's the use case for this? Also, http-equiv on its own is useless. http-equiv is only a supplement to the data stored in headers. And headers aren't always there: what happens in the context of someone debugging a page who pastes the source into the textarea of an mf2 parser? Without a compelling use case for including headers (and then over-riding some of them with http-equivs), I'm not sure why an implementor want to do this. —[[User:TomMorris|Tom Morris]] 00:25, 8 May 2015 (UTC)
</div>

E.g. from https://gist.github.com/aaronpk/10297489

<source lang="html4strict">
<meta http-equiv="Status" content="410 GONE"/>
</source>

<source lang="javascript">
{
"items": [],
"rels": {},
"http": {
"status": 410
}
}
</source>

<div class="discussion">
* Maybe make this an optional pass in the parser? - Tom Morris [[2015-01-20]]
* For now, don't bother with metas until someone provides a use-case. Tom Morris
* Agreed on both counts. [[User:Tantek|Tantek]] 06:56, 21 January 2015 (UTC)
</div>

==MIME type==
See [[microformats2-mime-type]]

----

==Other Interpretation Parsing Notes==
Note: most of these need to be written up as separate [[microformats2-parsing-issues]]

Author: [[User:BenWard|Ben Ward]]

[[microformats-2|Microformats 2]] proposes a new, all encompassing syntax modification of [[microformats-2-prefixes|prefixes]] that will allow microformats to be parsed from pages by processors without prior knowledge of a vocabulary. The core components of this model are quite simple, are quite simple to implement, but there are a number of conflicts that emerge with the functionality of existing microformats parsers that need to be handled. This page documents a proposed model to separate these concerns clearly in a way that can be applied to the documentation of generic microformats parsing rules, and the documentation of individual vocabularies.

Collection of other unresolved parsing issues in a generic model:

This is good material for documenting as [[microformats-2-issues]], [[microformats-2-faq]], and perhaps some of the more technical details in [[microformats-2-parsing-faq]].

* The include pattern references other elements from elsewhere in a document. A generic parser needs to track IDs and fill them in after walking the DOM. (also, <code>itemref</code> if adopted.)
** The current thinking per [[microformats-2-brainstorming]] is to adopt <code>itemref</code> and drop the [[include-pattern]]. [[User:Tantek|Tantek]]
* Will <code>itemref</code> always map to an <code>item</code> property name?
** No, <code>itemref</code> maps to one or more elements by ids, and their children. Those referenced elements may have property class names themselves, or they may contain elements that do. [[User:Tantek|Tantek]]
* [[hAtom]] implies <code>author</code> from an hCard in a page that uses an <code>address</code> element. This requires format knowledge, but a generic parser does not currently track the element type of a property node. Should it?
** It should not. element-specific handling (e.g. using "alt" from img, and "title" from abbr) is completely done at parse time. The JSON data model does not reflect which element type or attribute the value came from. Additionally, [[hAtom]] is an example where we created far too many vocabulary-specific rules, in practice they're not necessary, and only complicate the microformat for both publisher understanding and parser implementation. [[User:Tantek|Tantek]]
* [[hAtom]] defines that the highest level heading within an entry implies <code>entry-title</code>. This particular optimisation might be better off dead.
** Agreed, this is gone in microformats 2. [[User:Tantek|Tantek]]
* [[hAtom]] defines that permalinks be parsed from <code>rel</code> attributes, not <code>class</code>
** In practice this has been one of the more problematic/error prone aspects of hAtom implementations, and it's also inconsistent with other microformats (although [[hReview]] tried to use both rel permalinks and "url"). The dependence upon [[rel-bookmark]] for permalinks is dropped in h-atom in preference to re-using "u-url" and "u-uid". [[User:Tantek|Tantek]]
* [[XFN]] is entirely built on <code>rel</code> (although, has various other differences from structural microformats, as do vote-links, so perhaps are excluded from this discussion and will always be handled by dedicated parsers/queries regardless?)
** The best (easiest and most reliable) use of 'rel' microformats in practice is when they are orthogonal to 'class' microformats. This is true both with [[XFN]] and some newer [[existing-rel-values|rel values]] like [[rel-author]]. In addition, it was very clear at the recent [[schema.org]] workshop's syntax session that RDFa's decision to apparently arbitrarily mix use of 'rel' and 'property' attributes for specifying different types of properties (it wasn't clear to people in the room when you use which for what) has caused a high degree of confusion among publishers and thus high error-rates. Thus if anything we should learn from both the mistakes of RDFa and our own experiences with even very deliberate/specific mixing of rel microformats in class microformats, and keep them defined as separate orthogonal building blocks that work together, but don't depend on each other. [[User:Tantek|Tantek]]
*** Relatedly to this: <code>rel-tag</code> in hAtom. --[[User:BenWard|BenWard]] 06:50, 5 October 2011 (UTC)
**** Yes, and two related things here. First, despite my (and others') objection and (past) interoperable post/entry-specific treatment by Technorati and Ice Rocket, Hixie has redefined rel-tag in [[HTML5]] to mean applying to the whole page, not a single post. Second, I've explicitly added 'p-category' to the draft 'h-atom' vocabulary in [[microformats-2]]. [[User:Tantek|Tantek]] 07:12, 5 October 2011 (UTC)
* HTML's <code>time</code> element includes an optional <code>pubdate</code> attribute. Simply: We should parse this as <code>dt-published</code>. --[[User:BenWard|BenWard]] 06:12, 10 October 2011 (UTC)
** *If* there is even some reasonable data on actual use of the "pubdate" attribute (I don't think there is, frankly, especially with the removal of the algorithm to produce Atom from HTML5), then we could consider parsing "pubdate" as backwards compatible option for "dt-published". As a general rule, however, it is bad (demonstrably/experienced) design to depend on additional attributes (c.f. RDFa confusion over "property" vs. "rel"), especially for an instance where no additional attribute is necessary. I would leave this out for now until there is non-trivial (more than just test pages or folks who've written HTML5 books, ahem) use in the wild. When there is such use in the wild, it should be documented on a wiki page. We don't want to encourage more complex (additional attribute) publishing as a result of supporting it. [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)
* [[value-class-pattern]]: In microformats-2, since there are no sub-properties, there will presumably no-longer be a 'value' property in any parsed model. Properties such as 'tel > type' in hCard are, as I recall, deprecated due to underuse anyway, so 'tel > value' becomes redundant. (There's also potentially some clarification around 'price > value' in hListing, whereby value was used in a pattern. So, what does this mean for value class parsing, with regard to value-title patterns and date separation patterns. Are we looking for a 'p-value' and 'p-value-title' classname, but treating them specially (excluding them from regular property parsing.) Or, are we giving them a special prefix (v-text, v-title? That seems confusing, but could be a concept.) I'm fine with p- for both, and just having the parser ignore them since they're special, but need clarification and naming confirmation. --[[User:BenWard|BenWard]] 09:35, 10 October 2011 (UTC)
** A few things:
*** 1. Yes, no more subproperties. 'tel' becomes just 'p-tel'. If there is demand for a structured 'tel' value, then we can use that demand (and research into publishing in practice) to brainstorm and create an 'h-tel' structured telephone number (with perhaps fields like 'type', 'extension', some indication of it being local dialing (an extra 0 in some countries) or international dialing, etc.) Or, we address the different 'tel' types as their own flat properties (again as justified by research), e.g. perhaps 'p-tel-fax', or 'p-tel-mobile'. Something for hcard-2-brainstorming.
*** 2. For prices, e.g. hListing, either we're going to need to encode how to parse monetary amounts including monetary symbols, or consider creating an 'h-price' structured price. Not sure what the right answer is here, again, will need to be informed by analysis of documented actual price publication practices.
*** 3. We should avoid introducing a new prefix 'v-' just for value-class-pattern. As we've noted elsewhere, each new prefix adds complexity and should be avoided without substantial advantage.
*** 4. Using 'p-value-title' is strange, as it would be an exception to 'p-' parsing, since it would get the value from the 'title' attribute whereas 'p-' properties don't normally do that (exception: abbr).
*** 5. Using 'p-value' is also strange, as it wouldn't generate a 'value' property in the JSON data model.
*** 6. Class name 'value-title' is already sufficiently prefixed - we've found or even heard of no collisions in practice.
*** 7. Class name 'value' can, by its simpler naming nature, be expected to potentially collide with other web designer class name usage though we have no documentation/mention thereof. We could consider a renaming, or providing of alternative, such as 'value-string', or 'value-content', etc. However, let's keep that as a backup plan to use only if/when evidence is presented that we need to.
** Conclusions: for now, in microformats-2, keep using 'value' and 'value-title' as defined in the [[value-class-pattern]], and add the additional (obvious) interpretation that [[value-class-pattern#Date_and_time_parsing|value class pattern: date and time parsing]] applies to all 'dt-' properties. - [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)

== incorporated 2015-05-28 ==
The following brainstorms were incorporated 2015-05-28.

== more information for alternates ==
Raised 2015-04-24 by [[User:Kevin Marks|Kevin Marks]]

The existing <code>alternate</code> parsing is omitting <code>title</code> - that should be added. The <code>text</code> would make sense to add here too.

Use-case: labels for presenting alternates

<div class="discussion">
* +1 Makes sense. [[User:Tantek|Tantek]] 03:41, 25 April 2015 (UTC)
</div>

== more information for rel-based formats ==
Raised 2015-04-18 by [[User:Kevin Marks|Kevin Marks]]

Related github test suite issue: https://github.com/microformats/tests/issues/16

Several rel-based formats have additional information that is useful beyond the link itself, which is all we capture at the moment. As I am trying to update the Universal feedparser to support mf2 based I will show examples from the [https://github.com/kevinmarks/feedparser/tree/365623a9470e99246f393a8c1f49a0db567826b8/feedparser/tests/microformats testcases] there.

The main change is to add a <code>rel-urls</code> entry for more information about the attributes and text of the urls pointed to by rel's in the document

A fork of mf2py that implements these changes is at https://github.com/kevinmarks/mf2py
=== rel-tag ===

<code><a rel="tag" href="http://del.icio.us/tag/tech">Technology</a> </code>

currently parses to:

<code>{"rels": {"tag": ["http://del.icio.us/tag/tech"]}, "items": []} </code>

This loses the link text, which is useful as a label.

We add a <code>rel-urls</code> element to the parsed output with this extra data that can be looked up from the rels, which doesn't break backward compatibility and works better with xfn (see below)

<code><pre>
{
"rels": {
"tag": [
"http://del.icio.us/tag/tech"
]
},
"items": [],
"rel-urls": {
"http://del.icio.us/tag/tech": {
"rels": [
"tag"
],
"text": "Technology"
}
}
}
</pre></code>

=== xfn ===

<code><a rel="coworker" href="http://example.com/johndoe">John Doe</a></code>

currently parses to:

<code>{"rels": {"coworker": ["http://example.com/johndoe"]}, "items": []}</code>

This loses the link text, which is the person's name. Suggested output using the urls object:

<code><pre>
{
{
"rels": {
"coworker": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker"
],
"text": "John Doe"
}
}
}
</pre></code>

with multiple xfn values

<code><a rel="coworker friend" href="http://example.com/johndoe">John Doe</a></code>
we get this:

<code><pre>
{
"rels": {
"coworker": [
"http://example.com/johndoe"
],
"friend": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker",
"friend"
],
"text": "John Doe"
}
}
}
</pre></code>

=== rel-enclosure ===

<code><a rel="enclosure" href="http://example.com/movie.mp4" type="video/mpeg" title="real title">my movie</a></code>

currently parses to:

<code>'{"rels": {"enclosure": ["http://example.com/movie.mp4"]}, "items": []}'</code>

This loses the link text, which is the title and the attributes which give type. Suggested output:

<code><pre>
{
"rels": {
"enclosure": [
"http://example.com/movie.mp4"
]
},
"items": [],
"rel-urls": {
"http://example.com/movie.mp4": {
"rels": [
"enclosure"
],
"text": "my movie",
"type": "video/mpeg",
"title": "real title"
}
}
}
</pre></code>

This generalises to other rel's too, such as [[rel-feed]] and [[rel-alternate]] that have type, lang etc attributes.

(updated to include changes from feedback below) [[User:Kevin Marks|Kevin Marks]] 22:13, 26 April 2015 (UTC)

=== attributes parsed ===
Attributes currently parsed are:
* <code>hreflang</code> for alternate and enclosure
* <code>media</code> for alternate and enclosure
* <code>title</code> for alternate and enclosure
* <code>type</code> for alternate and enclosure

Attributes we may consider parsing if we have a use case are
* <code>sizes</code> for icon - need use-case documentation
* <code>coords</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats
* <code>shape</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats

In addition there is a special attribute <s><code>name</code> </s><code>text</code> which is the text contents of the link, which is useful in rel-tag rel-enclosure and xfn, and in alternate when used for feeds. It's also clarifying for rel-me links.

Tantek [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79057 suggests] we use <code>textContent</code> for this instead, and make it a single string, not a list as <code>name</code> is elsewhere in mf2 parsing
* Update: "text" is good enough, and "textContent" is ugly camelCase. [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)

=== feedback on more rel info ===
<div class="discussion">
# "name" is bad because it misleadingly conflates with use of "name" elsewhere in microformats2.
#* Suggested alternative: [https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent textContent] - since that's literally what is being returned there. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** as all other mf2 keys are lowercase-with-hyphens, [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79101 Tantek suggests] 'text' as that isn't going to be an html [[User:Kevin Marks|Kevin Marks]] 07:28, 25 April 2015 (UTC)
# no need for array for "name"/textContent - since there is always only one at most
#* E.g. should be "textContent": "my movie" [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#* Update: "text": "my movie" [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)
# "urls" key is misleading - implies all URLs in the document, which is neither true, nor desired (takes much more parsing time and work and code)
#* Suggested alternative: "rel-urls". And open to better alternatives too. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** If we are trying to extend the number of properties retuned from a rel without breaking the old structure why don't we call the new structure something like "rels-extended" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#*** Extension is not the point, but rather to use them complementary. One structure for look-up of any rel value, hence "rels", which returns you a list of URLs. Then you can lookup those URLs in the new mapping, by URL, hence it is called "rel-urls" - that's the point to use them in conjunction and that's why rel-urls is named what it is. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

# Why is the structure of "rel-urls" different to the "alternates" structure. Should the "url" not just be added as a property and not as a key. Creating two data structures for one type of object seems inconsistent. It adds cognitive load to anyone trying to understand the JSON structure [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* I was trying to avoid breaking the existing <code>rels</code> structure and use of it - I did implement a variant that put the structure inside rels, and it became cumbersome and repetitive where there were multiple rels on a url (xfn cases). Denormalising as properties of the URL made more sense. It also dedupes if there is repetitive linking to the same URL, eg a series of posts with rel-author on each. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
# If the rel is a "tag" then the main value we need to return should be the last path component of the URL, not the link text? Should we add another output property ie "tag" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* No need to return last path segment of the URL, because the URL is already there - and that's just a library/framework utility function to get the last path segment of a URL. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)
# As currently described, the URL from <code>alternates</code> is repeated in the <code>rel-urls</code> structure. If we are doing this, surely <code>alternate</code> should be in <code>rels</code> too? I assumed a mapping between them. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
## edit showing this variant: http://microformats.org/wiki/index.php?title=microformats2-parsing&oldid=65021#parse_a_hyperlink_element_for_rel_microformats
</div>
#* Yes it makes sense to drop "alternates" assuming the backcompat impact is low, put alternates in "rels" along with everything else, and direct people to use rels and rel-urls for alternates functionality. Evidence this is an acceptable even preferable approach.[http://indiewebcamp.com/irc/2015-06-01/line/1433195247005] Will add an issue accordingly. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

== Incorporated 2015-06-06 ==

== Nested h-* objects' "value" property ==
Status: resolved, resolution iterated, one real world implementation proven implementability, incorporated
* 2015-06-06 incorporated into [[microformats2-parsing]]

Raised 2015-01-06 by [[User:Kylewm]];

If a child element has a microformat (h-*) and is a property element (p-*, u-*, dt-*, e-*), the parser will add a "value" property to the resulting object. The value should attempt to be a useful representation of the object for consumers that do not have semantic knowledge of the particular h-* type. Ref: [[microformats2-parsing#parse_an_element_for_class_microformats]].

To determine the "value", we parse the property element simply (as if it did not have a h-* class), which works well for simple h-* objects, e.g. <code><a class="u-like-of h-cite" href="...">...</a></code>

<div class="discussion">
* To handle more complex microformats, I propose that "value" for a p-* property element take on the first explicit "name" property of the nested microformat, and for a u-* property, the first explicit "url" property. Parsing will fall back on the current rules if an explicit property does not exist.
** This makes sense to me, and fits with the use-cases and examples I've seen. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** A similar (possibly simpler?) formulation would use the implied name and url rules to determine the "value" for p-* and u-* properties respectively
*** I don't think that's needed, as there are already implied rules on a property that should handle that. I'd start with just the "first explicit" scoping to be more conservative, and then see if we find any use-cases that (and existing implied rules) don't/doesn't catch. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
**** Agreement at [[2015-01-20]] meetup.
</div>

For example:

<code><pre>
<div class="h-entry">
<div class="u-in-reply-to h-cite">
<a class="p-author h-card" href="http://example.com">Example Author</a>
<a class="p-name u-url" href="http://example.com/post">Example Post</a>
</div>
</div>
</pre></code>

The nested u-in-reply-to object would parse as

<code><pre>
...
"in-reply-to": [{
"type": ["h-cite"],
"properties": {
"name": ["Example Post"],
"url": ["http://example.com/post"],
"author": [{
"type":["h-card"],
"properties": {
"url": ["http://example.com"],
"name": ["Example Author"]
},
"value": "Example Author"
}],
},
"value": "http://example.com/post"
}]
...
</pre></code>

where the outer "value" gets the in-reply-to h-cite's u-url property, and the inner "value" gets the author's p-name property.

<div class="discussion">
* Because there are no implied properties of the dt-* and e-* types, and no obvious defaults, the value rules for these types would not change.
** A possibility for dt-* h-*: The dt-* could take either the first dt-* of the h-*, or (perhaps if no dt-* in the h-*,) the first <code><time></code> element inside. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** First dt-* seems reasonable, predictable, and usable. Consensus at [[2015-01-20]] meetup.
** Update 2015-05-29: no known use-cases for first dt-* or first e-*, and implementing that "would require some refactoring" (in mf2py at least per kylewm), thus until there's a use-case for first dt-*/e-* inside, let's treat "dt-* h-*" and "e-* h-*" as before. [[User:Tantek|Tantek]] . In particular:
*** p-* h-* - value from first "name" as proposed above
*** u-* h-* - value from first "url" as proposed above
*** e-* h-* - value is already defined for e-* parsing, nothing special here
*** dt-* h-* - value from normal dt-* parsing - nothing special.
*** +1 totally agree, let's wait for use cases of e-* dt-* [[User:Kylewm|Kylewm]] 19:44, 29 May 2015 (UTC)
</div>

* Implemented in mf2py 2015-06-01 https://github.com/tommorris/mf2py/commit/edc895ef5a780bcee654e6644a688688934517b0
* Added to microformats test suite (experimental) 2015-06-01 https://github.com/microformats/tests/commit/90c8a7d8e96c7160036a298e13f16d9ddaec218e

== see also ==
* [[microformats2]]
* [[microformats2-brainstorming]]
* [[microformats2-prefixes]]
* [[microformats2-faq]]
* [[microformats2-issues]]
* [[microformats2-parsing-faq]]

microformats2-parsing-issues

2016-05-07T07:10:52Z

Kylewm: /* Noscript skip/parse */ -0 and a question

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.

=== parsing a dt- property ===
* Should instruct to replace a "T" separator with a single space.
* Value-class-pattern parsing should instruct to use a single space as the separator.
* Value-class-pattern should instruct to keep the authored level of specificity, rather than implying 00 seconds when not present. http://microformats.org/wiki/value-class-pattern##If+by+parsing+the+%22value%22

Log: https://indiewebcamp.com/irc/2016-04-25#t1461606553653

<div class="discussion">
* +0 [[User:Kylewm|Kylewm]] on replacing "T" as the separator. Would you please clarify whether that is only for value class pattern/assembling dates from components, or is it proposing to *always* normalize dt's?
* +1 [[User:Kylewm|Kylewm]] on not implying seconds
</div>

=== implied name when alt="" ===

The implied name rule

* else if .h-x>img:only-child[alt]:not[.h-*] then use that img alt for name

is slightly under-specified for the case where alt is provided but intentionally blank. The desired behavior is to use the img alt tag only if it is non-empty. For example:

<pre>
<a class="h-card" href="https://kylewm.com">
<img src="https://kylewm.com/photo.jpg" alt="">
Kyle
</a>
</pre>

The PHP and JS parsers already seem to return the desired result ("Kyle" in the above example). The Python parser uses the alt text and returns "".

Proposal: modify the spec to explicitly exclude these tags:

* else if .h-x>img:only-child[alt]:not([alt=""]):not[.h-*] then use that img alt for name

And audit the other implied rules for similar cases.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] this makes sense to me, and as far as I can tell, for the other cases too for *implied* properties:
** area[alt], abbr[title], and all other attributes where there is an existence test, there should be a :not[alt=""] empty test, for implied p-name, u-photo, u-url
* +1 [[User:GRegorLove|gRegor]] sounds good to me.
* +1 [[User:Kylewm|Kylewm]] We've added this in mf2py too now, and I'm happy with it.
* ...
</div>

=== img fallback in p- ===
Trying to make an author h-card without too many extra elements I first did:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" >mention.tech</a>
</div></pre>

rather than:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" alt="">mention.tech</a>
</div></pre>

I was surprised that the p-name and p-org took the src and the plaintext and concatenated them giving <code>http://mention-tech.appspot.com/static/logo.jpgmention.tech</code>, though that is the current spec (a separate php-mf2 bug ignored the empty alt when I added it).

While this is what the spec says, I can't think of a scenario where concatenating a string to a URL gives a useful result. Instead, if we fallback on the src of an img due to it having no alt I propose we put a space on beginning and end. As whitespace is stripped from beginning and end of p- values, this should still give the url in the simplest case, but avoid creating nonsensical URLs in cases like this.

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] reasoning given here makes sense
* ...
</div>

=== de-dupe URLs? ===
Currently, Known templates end up linking to the author's url in the h-card twice. This leads to duplicate URLs in the parsed output, which make jf2 conversion insert a children element.
Should we be deduping URLs? Or is this a GIGO issue?

<div class="discussion">
* -1 [[User:Kylewm|Kylewm]] I can't necessarily think of a case where two of the same URL values is useful, but it feels like the parser's job to preserve the fidelity of the input. (this has been fixed in Known's markup btw [https://github.com/idno/Known/issues/1372])
* ...
</div>

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] with a caveat.
** Returned JSON SHOULD (not MUST) be UTF8 rather than ASCII with \u encoding because it is easier to read and debug.
** When parsing e- properties, HTML entities should be left escaped in the "html" value. This is important when parsing a reply-context; if the original post contains an escaped HTML code snippet, I want the reply context to show the same code snippet, rather than converting it all into real tags.
** e.g. <code>"content": [{"html": "&lt;b&gt;1&mdash;2&lt;/b&gt;", "value": "<b>1—2</b>"}]</code>.
</div>

=== 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 this twitter markup]

(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
* +1 [[User:Kylewm|Kylewm]] agree with rejecting property names that include capital letters (specifically detecting camelCase seems harder to define)
* ...
</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)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 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]]
* +1 [[User:Kylewm|Kylewm]] leave sanitization to the sanitizers!
* ...
</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
* +1 [[User:Kylewm|Kylewm]] sgtm
* ...
</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.
* -1 [[User:Kylewm|Kylewm]] A pretty display would be a nice debugging tool, but I'm -1 the proposal to define a specific, default HTML output. The two proposed use-cases are totally buildable without it.
* ...
</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.
* +0 [[User:Kylewm|Kylewm]] Is it possible a js-only client-rendered site would want to serve microformats in a noscript block? I know we encourage people to do better progressive-enhancement than that, but not everyone does, and I'd prefer it to no microformats.

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?

Should "p-name" still be implied if another explicit class is already provided?

Here is a somewhat contrived "u-url" related example, 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)
*** -0 failed consensus, this proposal is rejected. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
** 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
**** though if there is an img with u-featured but not u-photo, it's likely that was an explicit author decision (e.g. for an article) - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** Especially difficult to make a case for name.
**** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
**** Yet over-implied p-names appear to cause problems with many Bridgy webmention consuming use-cases[https://indiewebcamp.com/irc/2016-04-01/line/1459530869915], that's a good case - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
**** may need a broader rule, like any explicit p-* property on an element stops implied p-name. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** ... 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-05-07T07:03:43Z

Kylewm: /* default generated HTML */ -1

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.

=== parsing a dt- property ===
* Should instruct to replace a "T" separator with a single space.
* Value-class-pattern parsing should instruct to use a single space as the separator.
* Value-class-pattern should instruct to keep the authored level of specificity, rather than implying 00 seconds when not present. http://microformats.org/wiki/value-class-pattern##If+by+parsing+the+%22value%22

Log: https://indiewebcamp.com/irc/2016-04-25#t1461606553653

<div class="discussion">
* +0 [[User:Kylewm|Kylewm]] on replacing "T" as the separator. Would you please clarify whether that is only for value class pattern/assembling dates from components, or is it proposing to *always* normalize dt's?
* +1 [[User:Kylewm|Kylewm]] on not implying seconds
</div>

=== implied name when alt="" ===

The implied name rule

* else if .h-x>img:only-child[alt]:not[.h-*] then use that img alt for name

is slightly under-specified for the case where alt is provided but intentionally blank. The desired behavior is to use the img alt tag only if it is non-empty. For example:

<pre>
<a class="h-card" href="https://kylewm.com">
<img src="https://kylewm.com/photo.jpg" alt="">
Kyle
</a>
</pre>

The PHP and JS parsers already seem to return the desired result ("Kyle" in the above example). The Python parser uses the alt text and returns "".

Proposal: modify the spec to explicitly exclude these tags:

* else if .h-x>img:only-child[alt]:not([alt=""]):not[.h-*] then use that img alt for name

And audit the other implied rules for similar cases.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] this makes sense to me, and as far as I can tell, for the other cases too for *implied* properties:
** area[alt], abbr[title], and all other attributes where there is an existence test, there should be a :not[alt=""] empty test, for implied p-name, u-photo, u-url
* +1 [[User:GRegorLove|gRegor]] sounds good to me.
* +1 [[User:Kylewm|Kylewm]] We've added this in mf2py too now, and I'm happy with it.
* ...
</div>

=== img fallback in p- ===
Trying to make an author h-card without too many extra elements I first did:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" >mention.tech</a>
</div></pre>

rather than:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" alt="">mention.tech</a>
</div></pre>

I was surprised that the p-name and p-org took the src and the plaintext and concatenated them giving <code>http://mention-tech.appspot.com/static/logo.jpgmention.tech</code>, though that is the current spec (a separate php-mf2 bug ignored the empty alt when I added it).

While this is what the spec says, I can't think of a scenario where concatenating a string to a URL gives a useful result. Instead, if we fallback on the src of an img due to it having no alt I propose we put a space on beginning and end. As whitespace is stripped from beginning and end of p- values, this should still give the url in the simplest case, but avoid creating nonsensical URLs in cases like this.

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] reasoning given here makes sense
* ...
</div>

=== de-dupe URLs? ===
Currently, Known templates end up linking to the author's url in the h-card twice. This leads to duplicate URLs in the parsed output, which make jf2 conversion insert a children element.
Should we be deduping URLs? Or is this a GIGO issue?

<div class="discussion">
* -1 [[User:Kylewm|Kylewm]] I can't necessarily think of a case where two of the same URL values is useful, but it feels like the parser's job to preserve the fidelity of the input. (this has been fixed in Known's markup btw [https://github.com/idno/Known/issues/1372])
* ...
</div>

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] with a caveat.
** Returned JSON SHOULD (not MUST) be UTF8 rather than ASCII with \u encoding because it is easier to read and debug.
** When parsing e- properties, HTML entities should be left escaped in the "html" value. This is important when parsing a reply-context; if the original post contains an escaped HTML code snippet, I want the reply context to show the same code snippet, rather than converting it all into real tags.
** e.g. <code>"content": [{"html": "&lt;b&gt;1&mdash;2&lt;/b&gt;", "value": "<b>1—2</b>"}]</code>.
</div>

=== 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 this twitter markup]

(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
* +1 [[User:Kylewm|Kylewm]] agree with rejecting property names that include capital letters (specifically detecting camelCase seems harder to define)
* ...
</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)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 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]]
* +1 [[User:Kylewm|Kylewm]] leave sanitization to the sanitizers!
* ...
</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
* +1 [[User:Kylewm|Kylewm]] sgtm
* ...
</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.
* -1 [[User:Kylewm|Kylewm]] A pretty display would be a nice debugging tool, but I'm -1 the proposal to define a specific, default HTML output. The two proposed use-cases are totally buildable without it.
* ...
</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?

Should "p-name" still be implied if another explicit class is already provided?

Here is a somewhat contrived "u-url" related example, 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)
*** -0 failed consensus, this proposal is rejected. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
** 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
**** though if there is an img with u-featured but not u-photo, it's likely that was an explicit author decision (e.g. for an article) - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** Especially difficult to make a case for name.
**** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
**** Yet over-implied p-names appear to cause problems with many Bridgy webmention consuming use-cases[https://indiewebcamp.com/irc/2016-04-01/line/1459530869915], that's a good case - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
**** may need a broader rule, like any explicit p-* property on an element stops implied p-name. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** ... 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-05-07T06:53:22Z

Kylewm: /* use poster if no src on video for u props */ +1

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.

=== parsing a dt- property ===
* Should instruct to replace a "T" separator with a single space.
* Value-class-pattern parsing should instruct to use a single space as the separator.
* Value-class-pattern should instruct to keep the authored level of specificity, rather than implying 00 seconds when not present. http://microformats.org/wiki/value-class-pattern##If+by+parsing+the+%22value%22

Log: https://indiewebcamp.com/irc/2016-04-25#t1461606553653

<div class="discussion">
* +0 [[User:Kylewm|Kylewm]] on replacing "T" as the separator. Would you please clarify whether that is only for value class pattern/assembling dates from components, or is it proposing to *always* normalize dt's?
* +1 [[User:Kylewm|Kylewm]] on not implying seconds
</div>

=== implied name when alt="" ===

The implied name rule

* else if .h-x>img:only-child[alt]:not[.h-*] then use that img alt for name

is slightly under-specified for the case where alt is provided but intentionally blank. The desired behavior is to use the img alt tag only if it is non-empty. For example:

<pre>
<a class="h-card" href="https://kylewm.com">
<img src="https://kylewm.com/photo.jpg" alt="">
Kyle
</a>
</pre>

The PHP and JS parsers already seem to return the desired result ("Kyle" in the above example). The Python parser uses the alt text and returns "".

Proposal: modify the spec to explicitly exclude these tags:

* else if .h-x>img:only-child[alt]:not([alt=""]):not[.h-*] then use that img alt for name

And audit the other implied rules for similar cases.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] this makes sense to me, and as far as I can tell, for the other cases too for *implied* properties:
** area[alt], abbr[title], and all other attributes where there is an existence test, there should be a :not[alt=""] empty test, for implied p-name, u-photo, u-url
* +1 [[User:GRegorLove|gRegor]] sounds good to me.
* +1 [[User:Kylewm|Kylewm]] We've added this in mf2py too now, and I'm happy with it.
* ...
</div>

=== img fallback in p- ===
Trying to make an author h-card without too many extra elements I first did:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" >mention.tech</a>
</div></pre>

rather than:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" alt="">mention.tech</a>
</div></pre>

I was surprised that the p-name and p-org took the src and the plaintext and concatenated them giving <code>http://mention-tech.appspot.com/static/logo.jpgmention.tech</code>, though that is the current spec (a separate php-mf2 bug ignored the empty alt when I added it).

While this is what the spec says, I can't think of a scenario where concatenating a string to a URL gives a useful result. Instead, if we fallback on the src of an img due to it having no alt I propose we put a space on beginning and end. As whitespace is stripped from beginning and end of p- values, this should still give the url in the simplest case, but avoid creating nonsensical URLs in cases like this.

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] reasoning given here makes sense
* ...
</div>

=== de-dupe URLs? ===
Currently, Known templates end up linking to the author's url in the h-card twice. This leads to duplicate URLs in the parsed output, which make jf2 conversion insert a children element.
Should we be deduping URLs? Or is this a GIGO issue?

<div class="discussion">
* -1 [[User:Kylewm|Kylewm]] I can't necessarily think of a case where two of the same URL values is useful, but it feels like the parser's job to preserve the fidelity of the input. (this has been fixed in Known's markup btw [https://github.com/idno/Known/issues/1372])
* ...
</div>

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] with a caveat.
** Returned JSON SHOULD (not MUST) be UTF8 rather than ASCII with \u encoding because it is easier to read and debug.
** When parsing e- properties, HTML entities should be left escaped in the "html" value. This is important when parsing a reply-context; if the original post contains an escaped HTML code snippet, I want the reply context to show the same code snippet, rather than converting it all into real tags.
** e.g. <code>"content": [{"html": "&lt;b&gt;1&mdash;2&lt;/b&gt;", "value": "<b>1—2</b>"}]</code>.
</div>

=== 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 this twitter markup]

(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
* +1 [[User:Kylewm|Kylewm]] agree with rejecting property names that include capital letters (specifically detecting camelCase seems harder to define)
* ...
</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)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 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]]
* +1 [[User:Kylewm|Kylewm]] leave sanitization to the sanitizers!
* ...
</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
* +1 [[User:Kylewm|Kylewm]] sgtm
* ...
</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?

Should "p-name" still be implied if another explicit class is already provided?

Here is a somewhat contrived "u-url" related example, 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)
*** -0 failed consensus, this proposal is rejected. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
** 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
**** though if there is an img with u-featured but not u-photo, it's likely that was an explicit author decision (e.g. for an article) - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** Especially difficult to make a case for name.
**** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
**** Yet over-implied p-names appear to cause problems with many Bridgy webmention consuming use-cases[https://indiewebcamp.com/irc/2016-04-01/line/1459530869915], that's a good case - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
**** may need a broader rule, like any explicit p-* property on an element stops implied p-name. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** ... 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-05-07T06:51:51Z

Kylewm: /* exclude style elements before parsing */ +1 amended proposal

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.

=== parsing a dt- property ===
* Should instruct to replace a "T" separator with a single space.
* Value-class-pattern parsing should instruct to use a single space as the separator.
* Value-class-pattern should instruct to keep the authored level of specificity, rather than implying 00 seconds when not present. http://microformats.org/wiki/value-class-pattern##If+by+parsing+the+%22value%22

Log: https://indiewebcamp.com/irc/2016-04-25#t1461606553653

<div class="discussion">
* +0 [[User:Kylewm|Kylewm]] on replacing "T" as the separator. Would you please clarify whether that is only for value class pattern/assembling dates from components, or is it proposing to *always* normalize dt's?
* +1 [[User:Kylewm|Kylewm]] on not implying seconds
</div>

=== implied name when alt="" ===

The implied name rule

* else if .h-x>img:only-child[alt]:not[.h-*] then use that img alt for name

is slightly under-specified for the case where alt is provided but intentionally blank. The desired behavior is to use the img alt tag only if it is non-empty. For example:

<pre>
<a class="h-card" href="https://kylewm.com">
<img src="https://kylewm.com/photo.jpg" alt="">
Kyle
</a>
</pre>

The PHP and JS parsers already seem to return the desired result ("Kyle" in the above example). The Python parser uses the alt text and returns "".

Proposal: modify the spec to explicitly exclude these tags:

* else if .h-x>img:only-child[alt]:not([alt=""]):not[.h-*] then use that img alt for name

And audit the other implied rules for similar cases.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] this makes sense to me, and as far as I can tell, for the other cases too for *implied* properties:
** area[alt], abbr[title], and all other attributes where there is an existence test, there should be a :not[alt=""] empty test, for implied p-name, u-photo, u-url
* +1 [[User:GRegorLove|gRegor]] sounds good to me.
* +1 [[User:Kylewm|Kylewm]] We've added this in mf2py too now, and I'm happy with it.
* ...
</div>

=== img fallback in p- ===
Trying to make an author h-card without too many extra elements I first did:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" >mention.tech</a>
</div></pre>

rather than:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" alt="">mention.tech</a>
</div></pre>

I was surprised that the p-name and p-org took the src and the plaintext and concatenated them giving <code>http://mention-tech.appspot.com/static/logo.jpgmention.tech</code>, though that is the current spec (a separate php-mf2 bug ignored the empty alt when I added it).

While this is what the spec says, I can't think of a scenario where concatenating a string to a URL gives a useful result. Instead, if we fallback on the src of an img due to it having no alt I propose we put a space on beginning and end. As whitespace is stripped from beginning and end of p- values, this should still give the url in the simplest case, but avoid creating nonsensical URLs in cases like this.

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] reasoning given here makes sense
* ...
</div>

=== de-dupe URLs? ===
Currently, Known templates end up linking to the author's url in the h-card twice. This leads to duplicate URLs in the parsed output, which make jf2 conversion insert a children element.
Should we be deduping URLs? Or is this a GIGO issue?

<div class="discussion">
* -1 [[User:Kylewm|Kylewm]] I can't necessarily think of a case where two of the same URL values is useful, but it feels like the parser's job to preserve the fidelity of the input. (this has been fixed in Known's markup btw [https://github.com/idno/Known/issues/1372])
* ...
</div>

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] with a caveat.
** Returned JSON SHOULD (not MUST) be UTF8 rather than ASCII with \u encoding because it is easier to read and debug.
** When parsing e- properties, HTML entities should be left escaped in the "html" value. This is important when parsing a reply-context; if the original post contains an escaped HTML code snippet, I want the reply context to show the same code snippet, rather than converting it all into real tags.
** e.g. <code>"content": [{"html": "&lt;b&gt;1&mdash;2&lt;/b&gt;", "value": "<b>1—2</b>"}]</code>.
</div>

=== 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 this twitter markup]

(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
* +1 [[User:Kylewm|Kylewm]] agree with rejecting property names that include capital letters (specifically detecting camelCase seems harder to define)
* ...
</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)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 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]]
* +1 [[User:Kylewm|Kylewm]] leave sanitization to the sanitizers!
* ...
</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?

Should "p-name" still be implied if another explicit class is already provided?

Here is a somewhat contrived "u-url" related example, 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)
*** -0 failed consensus, this proposal is rejected. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
** 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
**** though if there is an img with u-featured but not u-photo, it's likely that was an explicit author decision (e.g. for an article) - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** Especially difficult to make a case for name.
**** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
**** Yet over-implied p-names appear to cause problems with many Bridgy webmention consuming use-cases[https://indiewebcamp.com/irc/2016-04-01/line/1459530869915], that's a good case - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
**** may need a broader rule, like any explicit p-* property on an element stops implied p-name. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** ... 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-05-07T06:48:08Z

Kylewm: /* 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.

=== parsing a dt- property ===
* Should instruct to replace a "T" separator with a single space.
* Value-class-pattern parsing should instruct to use a single space as the separator.
* Value-class-pattern should instruct to keep the authored level of specificity, rather than implying 00 seconds when not present. http://microformats.org/wiki/value-class-pattern##If+by+parsing+the+%22value%22

Log: https://indiewebcamp.com/irc/2016-04-25#t1461606553653

<div class="discussion">
* +0 [[User:Kylewm|Kylewm]] on replacing "T" as the separator. Would you please clarify whether that is only for value class pattern/assembling dates from components, or is it proposing to *always* normalize dt's?
* +1 [[User:Kylewm|Kylewm]] on not implying seconds
</div>

=== implied name when alt="" ===

The implied name rule

* else if .h-x>img:only-child[alt]:not[.h-*] then use that img alt for name

is slightly under-specified for the case where alt is provided but intentionally blank. The desired behavior is to use the img alt tag only if it is non-empty. For example:

<pre>
<a class="h-card" href="https://kylewm.com">
<img src="https://kylewm.com/photo.jpg" alt="">
Kyle
</a>
</pre>

The PHP and JS parsers already seem to return the desired result ("Kyle" in the above example). The Python parser uses the alt text and returns "".

Proposal: modify the spec to explicitly exclude these tags:

* else if .h-x>img:only-child[alt]:not([alt=""]):not[.h-*] then use that img alt for name

And audit the other implied rules for similar cases.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] this makes sense to me, and as far as I can tell, for the other cases too for *implied* properties:
** area[alt], abbr[title], and all other attributes where there is an existence test, there should be a :not[alt=""] empty test, for implied p-name, u-photo, u-url
* +1 [[User:GRegorLove|gRegor]] sounds good to me.
* +1 [[User:Kylewm|Kylewm]] We've added this in mf2py too now, and I'm happy with it.
* ...
</div>

=== img fallback in p- ===
Trying to make an author h-card without too many extra elements I first did:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" >mention.tech</a>
</div></pre>

rather than:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" alt="">mention.tech</a>
</div></pre>

I was surprised that the p-name and p-org took the src and the plaintext and concatenated them giving <code>http://mention-tech.appspot.com/static/logo.jpgmention.tech</code>, though that is the current spec (a separate php-mf2 bug ignored the empty alt when I added it).

While this is what the spec says, I can't think of a scenario where concatenating a string to a URL gives a useful result. Instead, if we fallback on the src of an img due to it having no alt I propose we put a space on beginning and end. As whitespace is stripped from beginning and end of p- values, this should still give the url in the simplest case, but avoid creating nonsensical URLs in cases like this.

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] reasoning given here makes sense
* ...
</div>

=== de-dupe URLs? ===
Currently, Known templates end up linking to the author's url in the h-card twice. This leads to duplicate URLs in the parsed output, which make jf2 conversion insert a children element.
Should we be deduping URLs? Or is this a GIGO issue?

<div class="discussion">
* -1 [[User:Kylewm|Kylewm]] I can't necessarily think of a case where two of the same URL values is useful, but it feels like the parser's job to preserve the fidelity of the input. (this has been fixed in Known's markup btw [https://github.com/idno/Known/issues/1372])
* ...
</div>

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] with a caveat.
** Returned JSON SHOULD (not MUST) be UTF8 rather than ASCII with \u encoding because it is easier to read and debug.
** When parsing e- properties, HTML entities should be left escaped in the "html" value. This is important when parsing a reply-context; if the original post contains an escaped HTML code snippet, I want the reply context to show the same code snippet, rather than converting it all into real tags.
** e.g. <code>"content": [{"html": "&lt;b&gt;1&mdash;2&lt;/b&gt;", "value": "<b>1—2</b>"}]</code>.
</div>

=== 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 this twitter markup]

(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
* +1 [[User:Kylewm|Kylewm]] agree with rejecting property names that include capital letters (specifically detecting camelCase seems harder to define)
* ...
</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)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 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?

Should "p-name" still be implied if another explicit class is already provided?

Here is a somewhat contrived "u-url" related example, 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)
*** -0 failed consensus, this proposal is rejected. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
** 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
**** though if there is an img with u-featured but not u-photo, it's likely that was an explicit author decision (e.g. for an article) - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** Especially difficult to make a case for name.
**** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
**** Yet over-implied p-names appear to cause problems with many Bridgy webmention consuming use-cases[https://indiewebcamp.com/irc/2016-04-01/line/1459530869915], that's a good case - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
**** may need a broader rule, like any explicit p-* property on an element stops implied p-name. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** ... 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-05-07T06:47:43Z

Kylewm: /* ignore u-camelCase properties */ +1

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.

=== parsing a dt- property ===
* Should instruct to replace a "T" separator with a single space.
* Value-class-pattern parsing should instruct to use a single space as the separator.
* Value-class-pattern should instruct to keep the authored level of specificity, rather than implying 00 seconds when not present. http://microformats.org/wiki/value-class-pattern##If+by+parsing+the+%22value%22

Log: https://indiewebcamp.com/irc/2016-04-25#t1461606553653

<div class="discussion">
* +0 [[User:Kylewm|Kylewm]] on replacing "T" as the separator. Would you please clarify whether that is only for value class pattern/assembling dates from components, or is it proposing to *always* normalize dt's?
* +1 [[User:Kylewm|Kylewm]] on not implying seconds
</div>

=== implied name when alt="" ===

The implied name rule

* else if .h-x>img:only-child[alt]:not[.h-*] then use that img alt for name

is slightly under-specified for the case where alt is provided but intentionally blank. The desired behavior is to use the img alt tag only if it is non-empty. For example:

<pre>
<a class="h-card" href="https://kylewm.com">
<img src="https://kylewm.com/photo.jpg" alt="">
Kyle
</a>
</pre>

The PHP and JS parsers already seem to return the desired result ("Kyle" in the above example). The Python parser uses the alt text and returns "".

Proposal: modify the spec to explicitly exclude these tags:

* else if .h-x>img:only-child[alt]:not([alt=""]):not[.h-*] then use that img alt for name

And audit the other implied rules for similar cases.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] this makes sense to me, and as far as I can tell, for the other cases too for *implied* properties:
** area[alt], abbr[title], and all other attributes where there is an existence test, there should be a :not[alt=""] empty test, for implied p-name, u-photo, u-url
* +1 [[User:GRegorLove|gRegor]] sounds good to me.
* +1 [[User:Kylewm|Kylewm]] We've added this in mf2py too now, and I'm happy with it.
* ...
</div>

=== img fallback in p- ===
Trying to make an author h-card without too many extra elements I first did:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" >mention.tech</a>
</div></pre>

rather than:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" alt="">mention.tech</a>
</div></pre>

I was surprised that the p-name and p-org took the src and the plaintext and concatenated them giving <code>http://mention-tech.appspot.com/static/logo.jpgmention.tech</code>, though that is the current spec (a separate php-mf2 bug ignored the empty alt when I added it).

While this is what the spec says, I can't think of a scenario where concatenating a string to a URL gives a useful result. Instead, if we fallback on the src of an img due to it having no alt I propose we put a space on beginning and end. As whitespace is stripped from beginning and end of p- values, this should still give the url in the simplest case, but avoid creating nonsensical URLs in cases like this.

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] reasoning given here makes sense
* ...
</div>

=== de-dupe URLs? ===
Currently, Known templates end up linking to the author's url in the h-card twice. This leads to duplicate URLs in the parsed output, which make jf2 conversion insert a children element.
Should we be deduping URLs? Or is this a GIGO issue?

<div class="discussion">
* -1 [[User:Kylewm|Kylewm]] I can't necessarily think of a case where two of the same URL values is useful, but it feels like the parser's job to preserve the fidelity of the input. (this has been fixed in Known's markup btw [https://github.com/idno/Known/issues/1372])
* ...
</div>

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] with a caveat.
** Returned JSON SHOULD (not MUST) be UTF8 rather than ASCII with \u encoding because it is easier to read and debug.
** When parsing e- properties, HTML entities should be left escaped in the "html" value. This is important when parsing a reply-context; if the original post contains an escaped HTML code snippet, I want the reply context to show the same code snippet, rather than converting it all into real tags.
** e.g. <code>"content": [{"html": "&lt;b&gt;1&mdash;2&lt;/b&gt;", "value": "<b>1—2</b>"}]</code>.
</div>

=== 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 this twitter markup]

(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
* +1 [[User:Kylewm|Kylewm]] agree with rejecting capital letters (specifically detecting camelCase seems harder to define)
* ...
</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)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 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?

Should "p-name" still be implied if another explicit class is already provided?

Here is a somewhat contrived "u-url" related example, 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)
*** -0 failed consensus, this proposal is rejected. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
** 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
**** though if there is an img with u-featured but not u-photo, it's likely that was an explicit author decision (e.g. for an article) - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** Especially difficult to make a case for name.
**** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
**** Yet over-implied p-names appear to cause problems with many Bridgy webmention consuming use-cases[https://indiewebcamp.com/irc/2016-04-01/line/1459530869915], that's a good case - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
**** may need a broader rule, like any explicit p-* property on an element stops implied p-name. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** ... 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-05-07T06:46:23Z

Kylewm: /* unicode generation in JSON */

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.

=== parsing a dt- property ===
* Should instruct to replace a "T" separator with a single space.
* Value-class-pattern parsing should instruct to use a single space as the separator.
* Value-class-pattern should instruct to keep the authored level of specificity, rather than implying 00 seconds when not present. http://microformats.org/wiki/value-class-pattern##If+by+parsing+the+%22value%22

Log: https://indiewebcamp.com/irc/2016-04-25#t1461606553653

<div class="discussion">
* +0 [[User:Kylewm|Kylewm]] on replacing "T" as the separator. Would you please clarify whether that is only for value class pattern/assembling dates from components, or is it proposing to *always* normalize dt's?
* +1 [[User:Kylewm|Kylewm]] on not implying seconds
</div>

=== implied name when alt="" ===

The implied name rule

* else if .h-x>img:only-child[alt]:not[.h-*] then use that img alt for name

is slightly under-specified for the case where alt is provided but intentionally blank. The desired behavior is to use the img alt tag only if it is non-empty. For example:

<pre>
<a class="h-card" href="https://kylewm.com">
<img src="https://kylewm.com/photo.jpg" alt="">
Kyle
</a>
</pre>

The PHP and JS parsers already seem to return the desired result ("Kyle" in the above example). The Python parser uses the alt text and returns "".

Proposal: modify the spec to explicitly exclude these tags:

* else if .h-x>img:only-child[alt]:not([alt=""]):not[.h-*] then use that img alt for name

And audit the other implied rules for similar cases.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] this makes sense to me, and as far as I can tell, for the other cases too for *implied* properties:
** area[alt], abbr[title], and all other attributes where there is an existence test, there should be a :not[alt=""] empty test, for implied p-name, u-photo, u-url
* +1 [[User:GRegorLove|gRegor]] sounds good to me.
* +1 [[User:Kylewm|Kylewm]] We've added this in mf2py too now, and I'm happy with it.
* ...
</div>

=== img fallback in p- ===
Trying to make an author h-card without too many extra elements I first did:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" >mention.tech</a>
</div></pre>

rather than:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" alt="">mention.tech</a>
</div></pre>

I was surprised that the p-name and p-org took the src and the plaintext and concatenated them giving <code>http://mention-tech.appspot.com/static/logo.jpgmention.tech</code>, though that is the current spec (a separate php-mf2 bug ignored the empty alt when I added it).

While this is what the spec says, I can't think of a scenario where concatenating a string to a URL gives a useful result. Instead, if we fallback on the src of an img due to it having no alt I propose we put a space on beginning and end. As whitespace is stripped from beginning and end of p- values, this should still give the url in the simplest case, but avoid creating nonsensical URLs in cases like this.

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] reasoning given here makes sense
* ...
</div>

=== de-dupe URLs? ===
Currently, Known templates end up linking to the author's url in the h-card twice. This leads to duplicate URLs in the parsed output, which make jf2 conversion insert a children element.
Should we be deduping URLs? Or is this a GIGO issue?

<div class="discussion">
* -1 [[User:Kylewm|Kylewm]] I can't necessarily think of a case where two of the same URL values is useful, but it feels like the parser's job to preserve the fidelity of the input. (this has been fixed in Known's markup btw [https://github.com/idno/Known/issues/1372])
* ...
</div>

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] with a caveat.
** Returned JSON SHOULD (not MUST) be UTF8 rather than ASCII with \u encoding because it is easier to read and debug.
** When parsing e- properties, HTML entities should be left escaped in the "html" value. This is important when parsing a reply-context; if the original post contains an escaped HTML code snippet, I want the reply context to show the same code snippet, rather than converting it all into real tags.
** e.g. <code>"content": [{"html": "&lt;b&gt;1&mdash;2&lt;/b&gt;", "value": "<b>1—2</b>"}]</code>.
</div>

=== 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 this twitter markup]

(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)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 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?

Should "p-name" still be implied if another explicit class is already provided?

Here is a somewhat contrived "u-url" related example, 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)
*** -0 failed consensus, this proposal is rejected. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
** 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
**** though if there is an img with u-featured but not u-photo, it's likely that was an explicit author decision (e.g. for an article) - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** Especially difficult to make a case for name.
**** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
**** Yet over-implied p-names appear to cause problems with many Bridgy webmention consuming use-cases[https://indiewebcamp.com/irc/2016-04-01/line/1459530869915], that's a good case - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
**** may need a broader rule, like any explicit p-* property on an element stops implied p-name. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** ... 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-05-07T06:45:36Z

Kylewm: /* unicode generation in JSON */

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.

=== parsing a dt- property ===
* Should instruct to replace a "T" separator with a single space.
* Value-class-pattern parsing should instruct to use a single space as the separator.
* Value-class-pattern should instruct to keep the authored level of specificity, rather than implying 00 seconds when not present. http://microformats.org/wiki/value-class-pattern##If+by+parsing+the+%22value%22

Log: https://indiewebcamp.com/irc/2016-04-25#t1461606553653

<div class="discussion">
* +0 [[User:Kylewm|Kylewm]] on replacing "T" as the separator. Would you please clarify whether that is only for value class pattern/assembling dates from components, or is it proposing to *always* normalize dt's?
* +1 [[User:Kylewm|Kylewm]] on not implying seconds
</div>

=== implied name when alt="" ===

The implied name rule

* else if .h-x>img:only-child[alt]:not[.h-*] then use that img alt for name

is slightly under-specified for the case where alt is provided but intentionally blank. The desired behavior is to use the img alt tag only if it is non-empty. For example:

<pre>
<a class="h-card" href="https://kylewm.com">
<img src="https://kylewm.com/photo.jpg" alt="">
Kyle
</a>
</pre>

The PHP and JS parsers already seem to return the desired result ("Kyle" in the above example). The Python parser uses the alt text and returns "".

Proposal: modify the spec to explicitly exclude these tags:

* else if .h-x>img:only-child[alt]:not([alt=""]):not[.h-*] then use that img alt for name

And audit the other implied rules for similar cases.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] this makes sense to me, and as far as I can tell, for the other cases too for *implied* properties:
** area[alt], abbr[title], and all other attributes where there is an existence test, there should be a :not[alt=""] empty test, for implied p-name, u-photo, u-url
* +1 [[User:GRegorLove|gRegor]] sounds good to me.
* +1 [[User:Kylewm|Kylewm]] We've added this in mf2py too now, and I'm happy with it.
* ...
</div>

=== img fallback in p- ===
Trying to make an author h-card without too many extra elements I first did:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" >mention.tech</a>
</div></pre>

rather than:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" alt="">mention.tech</a>
</div></pre>

I was surprised that the p-name and p-org took the src and the plaintext and concatenated them giving <code>http://mention-tech.appspot.com/static/logo.jpgmention.tech</code>, though that is the current spec (a separate php-mf2 bug ignored the empty alt when I added it).

While this is what the spec says, I can't think of a scenario where concatenating a string to a URL gives a useful result. Instead, if we fallback on the src of an img due to it having no alt I propose we put a space on beginning and end. As whitespace is stripped from beginning and end of p- values, this should still give the url in the simplest case, but avoid creating nonsensical URLs in cases like this.

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] reasoning given here makes sense
* ...
</div>

=== de-dupe URLs? ===
Currently, Known templates end up linking to the author's url in the h-card twice. This leads to duplicate URLs in the parsed output, which make jf2 conversion insert a children element.
Should we be deduping URLs? Or is this a GIGO issue?

<div class="discussion">
* -1 [[User:Kylewm|Kylewm]] I can't necessarily think of a case where two of the same URL values is useful, but it feels like the parser's job to preserve the fidelity of the input. (this has been fixed in Known's markup btw [https://github.com/idno/Known/issues/1372])
* ...
</div>

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] with a caveat.
** Returned JSON SHOULD (not MUST) be UTF8 rather than ASCII with \u encoding because it is easier to read and debug.
** When parsing e- properties, HTML entities should be left escaped in the "html" value. This is important when parsing a reply-context; if the original post contains an escaped HTML code snippet, I want the reply context to show the same code snippet, rather than converting it all into real tags.
** e.g. <code>"content": [{"html": "&lt;b&gt;1&mdash;2&lt;/b&gt;", "value": "<b> 1—2</b>"}]</code>.
</div>

=== 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 this twitter markup]

(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)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 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?

Should "p-name" still be implied if another explicit class is already provided?

Here is a somewhat contrived "u-url" related example, 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)
*** -0 failed consensus, this proposal is rejected. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
** 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
**** though if there is an img with u-featured but not u-photo, it's likely that was an explicit author decision (e.g. for an article) - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** Especially difficult to make a case for name.
**** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
**** Yet over-implied p-names appear to cause problems with many Bridgy webmention consuming use-cases[https://indiewebcamp.com/irc/2016-04-01/line/1459530869915], that's a good case - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
**** may need a broader rule, like any explicit p-* property on an element stops implied p-name. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** ... 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-05-07T06:42:54Z

Kylewm: /* unicode generation in JSON */ +1

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.

=== parsing a dt- property ===
* Should instruct to replace a "T" separator with a single space.
* Value-class-pattern parsing should instruct to use a single space as the separator.
* Value-class-pattern should instruct to keep the authored level of specificity, rather than implying 00 seconds when not present. http://microformats.org/wiki/value-class-pattern##If+by+parsing+the+%22value%22

Log: https://indiewebcamp.com/irc/2016-04-25#t1461606553653

<div class="discussion">
* +0 [[User:Kylewm|Kylewm]] on replacing "T" as the separator. Would you please clarify whether that is only for value class pattern/assembling dates from components, or is it proposing to *always* normalize dt's?
* +1 [[User:Kylewm|Kylewm]] on not implying seconds
</div>

=== implied name when alt="" ===

The implied name rule

* else if .h-x>img:only-child[alt]:not[.h-*] then use that img alt for name

is slightly under-specified for the case where alt is provided but intentionally blank. The desired behavior is to use the img alt tag only if it is non-empty. For example:

<pre>
<a class="h-card" href="https://kylewm.com">
<img src="https://kylewm.com/photo.jpg" alt="">
Kyle
</a>
</pre>

The PHP and JS parsers already seem to return the desired result ("Kyle" in the above example). The Python parser uses the alt text and returns "".

Proposal: modify the spec to explicitly exclude these tags:

* else if .h-x>img:only-child[alt]:not([alt=""]):not[.h-*] then use that img alt for name

And audit the other implied rules for similar cases.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] this makes sense to me, and as far as I can tell, for the other cases too for *implied* properties:
** area[alt], abbr[title], and all other attributes where there is an existence test, there should be a :not[alt=""] empty test, for implied p-name, u-photo, u-url
* +1 [[User:GRegorLove|gRegor]] sounds good to me.
* +1 [[User:Kylewm|Kylewm]] We've added this in mf2py too now, and I'm happy with it.
* ...
</div>

=== img fallback in p- ===
Trying to make an author h-card without too many extra elements I first did:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" >mention.tech</a>
</div></pre>

rather than:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" alt="">mention.tech</a>
</div></pre>

I was surprised that the p-name and p-org took the src and the plaintext and concatenated them giving <code>http://mention-tech.appspot.com/static/logo.jpgmention.tech</code>, though that is the current spec (a separate php-mf2 bug ignored the empty alt when I added it).

While this is what the spec says, I can't think of a scenario where concatenating a string to a URL gives a useful result. Instead, if we fallback on the src of an img due to it having no alt I propose we put a space on beginning and end. As whitespace is stripped from beginning and end of p- values, this should still give the url in the simplest case, but avoid creating nonsensical URLs in cases like this.

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] reasoning given here makes sense
* ...
</div>

=== de-dupe URLs? ===
Currently, Known templates end up linking to the author's url in the h-card twice. This leads to duplicate URLs in the parsed output, which make jf2 conversion insert a children element.
Should we be deduping URLs? Or is this a GIGO issue?

<div class="discussion">
* -1 [[User:Kylewm|Kylewm]] I can't necessarily think of a case where two of the same URL values is useful, but it feels like the parser's job to preserve the fidelity of the input. (this has been fixed in Known's markup btw [https://github.com/idno/Known/issues/1372])
* ...
</div>

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] with a caveat. Returned JSON SHOULD (not MUST) be UTF8 rather than ASCII with \u encoding because it is much more human friendly when dealing with non-English and especially non-Latin alphabets. However, when parsing e- properties, HTML entities should be left alone in the "html" value, so <code>"content": [{"html": "&lt;b&gt;1&mdash;2&lt;/b&gt; &", "value": "<b> 1—2</b>"}]</code>. This is important, e.g. when parsing/displaying a reply-context; if the original post contains an escaped HTML code snippet, I want the reply context to show the same code snippet, rather than converting it all into real tags.
</div>

=== 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 this twitter markup]

(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)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 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?

Should "p-name" still be implied if another explicit class is already provided?

Here is a somewhat contrived "u-url" related example, 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)
*** -0 failed consensus, this proposal is rejected. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
** 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
**** though if there is an img with u-featured but not u-photo, it's likely that was an explicit author decision (e.g. for an article) - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** Especially difficult to make a case for name.
**** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
**** Yet over-implied p-names appear to cause problems with many Bridgy webmention consuming use-cases[https://indiewebcamp.com/irc/2016-04-01/line/1459530869915], that's a good case - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
**** may need a broader rule, like any explicit p-* property on an element stops implied p-name. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** ... 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-05-07T06:37:32Z

Kylewm: /* unicode generation in JSON */ +1

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.

=== parsing a dt- property ===
* Should instruct to replace a "T" separator with a single space.
* Value-class-pattern parsing should instruct to use a single space as the separator.
* Value-class-pattern should instruct to keep the authored level of specificity, rather than implying 00 seconds when not present. http://microformats.org/wiki/value-class-pattern##If+by+parsing+the+%22value%22

Log: https://indiewebcamp.com/irc/2016-04-25#t1461606553653

<div class="discussion">
* +0 [[User:Kylewm|Kylewm]] on replacing "T" as the separator. Would you please clarify whether that is only for value class pattern/assembling dates from components, or is it proposing to *always* normalize dt's?
* +1 [[User:Kylewm|Kylewm]] on not implying seconds
</div>

=== implied name when alt="" ===

The implied name rule

* else if .h-x>img:only-child[alt]:not[.h-*] then use that img alt for name

is slightly under-specified for the case where alt is provided but intentionally blank. The desired behavior is to use the img alt tag only if it is non-empty. For example:

<pre>
<a class="h-card" href="https://kylewm.com">
<img src="https://kylewm.com/photo.jpg" alt="">
Kyle
</a>
</pre>

The PHP and JS parsers already seem to return the desired result ("Kyle" in the above example). The Python parser uses the alt text and returns "".

Proposal: modify the spec to explicitly exclude these tags:

* else if .h-x>img:only-child[alt]:not([alt=""]):not[.h-*] then use that img alt for name

And audit the other implied rules for similar cases.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] this makes sense to me, and as far as I can tell, for the other cases too for *implied* properties:
** area[alt], abbr[title], and all other attributes where there is an existence test, there should be a :not[alt=""] empty test, for implied p-name, u-photo, u-url
* +1 [[User:GRegorLove|gRegor]] sounds good to me.
* +1 [[User:Kylewm|Kylewm]] We've added this in mf2py too now, and I'm happy with it.
* ...
</div>

=== img fallback in p- ===
Trying to make an author h-card without too many extra elements I first did:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" >mention.tech</a>
</div></pre>

rather than:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" alt="">mention.tech</a>
</div></pre>

I was surprised that the p-name and p-org took the src and the plaintext and concatenated them giving <code>http://mention-tech.appspot.com/static/logo.jpgmention.tech</code>, though that is the current spec (a separate php-mf2 bug ignored the empty alt when I added it).

While this is what the spec says, I can't think of a scenario where concatenating a string to a URL gives a useful result. Instead, if we fallback on the src of an img due to it having no alt I propose we put a space on beginning and end. As whitespace is stripped from beginning and end of p- values, this should still give the url in the simplest case, but avoid creating nonsensical URLs in cases like this.

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] reasoning given here makes sense
* ...
</div>

=== de-dupe URLs? ===
Currently, Known templates end up linking to the author's url in the h-card twice. This leads to duplicate URLs in the parsed output, which make jf2 conversion insert a children element.
Should we be deduping URLs? Or is this a GIGO issue?

<div class="discussion">
* -1 [[User:Kylewm|Kylewm]] I can't necessarily think of a case where two of the same URL values is useful, but it feels like the parser's job to preserve the fidelity of the input. (this has been fixed in Known's markup btw [https://github.com/idno/Known/issues/1372])
* ...
</div>

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] with a caveat. Returned JSON SHOULD (not MUST) be UTF8 rather than ASCII with \u encoding. However, when parsing e- properties, HTML entities should be left alone in the "html" value, so <code>"content": [{"html": "&lt;b&gt; &mdash;", "value": "<b> —"}]</code>.
</div>

=== 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 this twitter markup]

(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)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 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?

Should "p-name" still be implied if another explicit class is already provided?

Here is a somewhat contrived "u-url" related example, 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)
*** -0 failed consensus, this proposal is rejected. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
** 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
**** though if there is an img with u-featured but not u-photo, it's likely that was an explicit author decision (e.g. for an article) - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** Especially difficult to make a case for name.
**** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
**** Yet over-implied p-names appear to cause problems with many Bridgy webmention consuming use-cases[https://indiewebcamp.com/irc/2016-04-01/line/1459530869915], that's a good case - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
**** may need a broader rule, like any explicit p-* property on an element stops implied p-name. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** ... 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-05-07T06:29:01Z

Kylewm: /* de-dupe URLs? */ -1

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.

=== parsing a dt- property ===
* Should instruct to replace a "T" separator with a single space.
* Value-class-pattern parsing should instruct to use a single space as the separator.
* Value-class-pattern should instruct to keep the authored level of specificity, rather than implying 00 seconds when not present. http://microformats.org/wiki/value-class-pattern##If+by+parsing+the+%22value%22

Log: https://indiewebcamp.com/irc/2016-04-25#t1461606553653

<div class="discussion">
* +0 [[User:Kylewm|Kylewm]] on replacing "T" as the separator. Would you please clarify whether that is only for value class pattern/assembling dates from components, or is it proposing to *always* normalize dt's?
* +1 [[User:Kylewm|Kylewm]] on not implying seconds
</div>

=== implied name when alt="" ===

The implied name rule

* else if .h-x>img:only-child[alt]:not[.h-*] then use that img alt for name

is slightly under-specified for the case where alt is provided but intentionally blank. The desired behavior is to use the img alt tag only if it is non-empty. For example:

<pre>
<a class="h-card" href="https://kylewm.com">
<img src="https://kylewm.com/photo.jpg" alt="">
Kyle
</a>
</pre>

The PHP and JS parsers already seem to return the desired result ("Kyle" in the above example). The Python parser uses the alt text and returns "".

Proposal: modify the spec to explicitly exclude these tags:

* else if .h-x>img:only-child[alt]:not([alt=""]):not[.h-*] then use that img alt for name

And audit the other implied rules for similar cases.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] this makes sense to me, and as far as I can tell, for the other cases too for *implied* properties:
** area[alt], abbr[title], and all other attributes where there is an existence test, there should be a :not[alt=""] empty test, for implied p-name, u-photo, u-url
* +1 [[User:GRegorLove|gRegor]] sounds good to me.
* +1 [[User:Kylewm|Kylewm]] We've added this in mf2py too now, and I'm happy with it.
* ...
</div>

=== img fallback in p- ===
Trying to make an author h-card without too many extra elements I first did:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" >mention.tech</a>
</div></pre>

rather than:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" alt="">mention.tech</a>
</div></pre>

I was surprised that the p-name and p-org took the src and the plaintext and concatenated them giving <code>http://mention-tech.appspot.com/static/logo.jpgmention.tech</code>, though that is the current spec (a separate php-mf2 bug ignored the empty alt when I added it).

While this is what the spec says, I can't think of a scenario where concatenating a string to a URL gives a useful result. Instead, if we fallback on the src of an img due to it having no alt I propose we put a space on beginning and end. As whitespace is stripped from beginning and end of p- values, this should still give the url in the simplest case, but avoid creating nonsensical URLs in cases like this.

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] reasoning given here makes sense
* ...
</div>

=== de-dupe URLs? ===
Currently, Known templates end up linking to the author's url in the h-card twice. This leads to duplicate URLs in the parsed output, which make jf2 conversion insert a children element.
Should we be deduping URLs? Or is this a GIGO issue?

<div class="discussion">
* -1 [[User:Kylewm|Kylewm]] I can't necessarily think of a case where two of the same URL values is useful, but it feels like the parser's job to preserve the fidelity of the input. (this has been fixed in Known's markup btw [https://github.com/idno/Known/issues/1372])
* ...
</div>

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

=== 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 this twitter markup]

(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)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 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?

Should "p-name" still be implied if another explicit class is already provided?

Here is a somewhat contrived "u-url" related example, 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)
*** -0 failed consensus, this proposal is rejected. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
** 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
**** though if there is an img with u-featured but not u-photo, it's likely that was an explicit author decision (e.g. for an article) - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** Especially difficult to make a case for name.
**** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
**** Yet over-implied p-names appear to cause problems with many Bridgy webmention consuming use-cases[https://indiewebcamp.com/irc/2016-04-01/line/1459530869915], that's a good case - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
**** may need a broader rule, like any explicit p-* property on an element stops implied p-name. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** ... 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-05-07T06:19:47Z

Kylewm: /* img fallback in p- */ +1 to adding whitespace around images

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.

=== parsing a dt- property ===
* Should instruct to replace a "T" separator with a single space.
* Value-class-pattern parsing should instruct to use a single space as the separator.
* Value-class-pattern should instruct to keep the authored level of specificity, rather than implying 00 seconds when not present. http://microformats.org/wiki/value-class-pattern##If+by+parsing+the+%22value%22

Log: https://indiewebcamp.com/irc/2016-04-25#t1461606553653

<div class="discussion">
* +0 [[User:Kylewm|Kylewm]] on replacing "T" as the separator. Would you please clarify whether that is only for value class pattern/assembling dates from components, or is it proposing to *always* normalize dt's?
* +1 [[User:Kylewm|Kylewm]] on not implying seconds
</div>

=== implied name when alt="" ===

The implied name rule

* else if .h-x>img:only-child[alt]:not[.h-*] then use that img alt for name

is slightly under-specified for the case where alt is provided but intentionally blank. The desired behavior is to use the img alt tag only if it is non-empty. For example:

<pre>
<a class="h-card" href="https://kylewm.com">
<img src="https://kylewm.com/photo.jpg" alt="">
Kyle
</a>
</pre>

The PHP and JS parsers already seem to return the desired result ("Kyle" in the above example). The Python parser uses the alt text and returns "".

Proposal: modify the spec to explicitly exclude these tags:

* else if .h-x>img:only-child[alt]:not([alt=""]):not[.h-*] then use that img alt for name

And audit the other implied rules for similar cases.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] this makes sense to me, and as far as I can tell, for the other cases too for *implied* properties:
** area[alt], abbr[title], and all other attributes where there is an existence test, there should be a :not[alt=""] empty test, for implied p-name, u-photo, u-url
* +1 [[User:GRegorLove|gRegor]] sounds good to me.
* +1 [[User:Kylewm|Kylewm]] We've added this in mf2py too now, and I'm happy with it.
* ...
</div>

=== img fallback in p- ===
Trying to make an author h-card without too many extra elements I first did:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" >mention.tech</a>
</div></pre>

rather than:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" alt="">mention.tech</a>
</div></pre>

I was surprised that the p-name and p-org took the src and the plaintext and concatenated them giving <code>http://mention-tech.appspot.com/static/logo.jpgmention.tech</code>, though that is the current spec (a separate php-mf2 bug ignored the empty alt when I added it).

While this is what the spec says, I can't think of a scenario where concatenating a string to a URL gives a useful result. Instead, if we fallback on the src of an img due to it having no alt I propose we put a space on beginning and end. As whitespace is stripped from beginning and end of p- values, this should still give the url in the simplest case, but avoid creating nonsensical URLs in cases like this.

<div class="discussion">
* +1 [[User:Kylewm|Kylewm]] reasoning given here makes sense
* ...
</div>

=== de-dupe URLs? ===
Currently, Known templates end up linking to the author's url in the h-card twice. This leads to duplicate URLs in the parsed output, which make jf2 conversion insert a children element.
Should we be deduping URLs? Or is this a GIGO issue?

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

=== 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 this twitter markup]

(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)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 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?

Should "p-name" still be implied if another explicit class is already provided?

Here is a somewhat contrived "u-url" related example, 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)
*** -0 failed consensus, this proposal is rejected. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
** 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
**** though if there is an img with u-featured but not u-photo, it's likely that was an explicit author decision (e.g. for an article) - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** Especially difficult to make a case for name.
**** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
**** Yet over-implied p-names appear to cause problems with many Bridgy webmention consuming use-cases[https://indiewebcamp.com/irc/2016-04-01/line/1459530869915], that's a good case - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
**** may need a broader rule, like any explicit p-* property on an element stops implied p-name. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** ... 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-05-07T06:17:44Z

Kylewm: /* implied name when alt="" */ +1

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.

=== parsing a dt- property ===
* Should instruct to replace a "T" separator with a single space.
* Value-class-pattern parsing should instruct to use a single space as the separator.
* Value-class-pattern should instruct to keep the authored level of specificity, rather than implying 00 seconds when not present. http://microformats.org/wiki/value-class-pattern##If+by+parsing+the+%22value%22

Log: https://indiewebcamp.com/irc/2016-04-25#t1461606553653

<div class="discussion">
* +0 [[User:Kylewm|Kylewm]] on replacing "T" as the separator. Would you please clarify whether that is only for value class pattern/assembling dates from components, or is it proposing to *always* normalize dt's?
* +1 [[User:Kylewm|Kylewm]] on not implying seconds
</div>

=== implied name when alt="" ===

The implied name rule

* else if .h-x>img:only-child[alt]:not[.h-*] then use that img alt for name

is slightly under-specified for the case where alt is provided but intentionally blank. The desired behavior is to use the img alt tag only if it is non-empty. For example:

<pre>
<a class="h-card" href="https://kylewm.com">
<img src="https://kylewm.com/photo.jpg" alt="">
Kyle
</a>
</pre>

The PHP and JS parsers already seem to return the desired result ("Kyle" in the above example). The Python parser uses the alt text and returns "".

Proposal: modify the spec to explicitly exclude these tags:

* else if .h-x>img:only-child[alt]:not([alt=""]):not[.h-*] then use that img alt for name

And audit the other implied rules for similar cases.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] this makes sense to me, and as far as I can tell, for the other cases too for *implied* properties:
** area[alt], abbr[title], and all other attributes where there is an existence test, there should be a :not[alt=""] empty test, for implied p-name, u-photo, u-url
* +1 [[User:GRegorLove|gRegor]] sounds good to me.
* +1 [[User:Kylewm|Kylewm]] We've added this in mf2py too now, and I'm happy with it.
* ...
</div>

=== img fallback in p- ===
Trying to make an author h-card without too many extra elements I first did:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" >mention.tech</a>
</div></pre>

rather than:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" alt="">mention.tech</a>
</div></pre>

I was surprised that the p-name and p-org took the src and the plaintext and concatenated them giving <code>http://mention-tech.appspot.com/static/logo.jpgmention.tech</code>, though that is the current spec (a separate php-mf2 bug ignored the empty alt when I added it).

While this is what the spec says, I can't think of a scenario where concatenating a string to a URL gives a useful result. Instead, if we fallback on the src of an img due to it having no alt I propose we put a space on beginning and end. As whitespace is stripped from beginning and end of p- values, this should still give the url in the simplest case, but avoid creating nonsensical URLs in cases like this.

=== de-dupe URLs? ===
Currently, Known templates end up linking to the author's url in the h-card twice. This leads to duplicate URLs in the parsed output, which make jf2 conversion insert a children element.
Should we be deduping URLs? Or is this a GIGO issue?

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

=== 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 this twitter markup]

(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)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 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?

Should "p-name" still be implied if another explicit class is already provided?

Here is a somewhat contrived "u-url" related example, 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)
*** -0 failed consensus, this proposal is rejected. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
** 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
**** though if there is an img with u-featured but not u-photo, it's likely that was an explicit author decision (e.g. for an article) - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** Especially difficult to make a case for name.
**** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
**** Yet over-implied p-names appear to cause problems with many Bridgy webmention consuming use-cases[https://indiewebcamp.com/irc/2016-04-01/line/1459530869915], that's a good case - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
**** may need a broader rule, like any explicit p-* property on an element stops implied p-name. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** ... 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-05-07T06:17:09Z

Kylewm: /* parsing a dt- property */ discussion

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.

=== parsing a dt- property ===
* Should instruct to replace a "T" separator with a single space.
* Value-class-pattern parsing should instruct to use a single space as the separator.
* Value-class-pattern should instruct to keep the authored level of specificity, rather than implying 00 seconds when not present. http://microformats.org/wiki/value-class-pattern##If+by+parsing+the+%22value%22

Log: https://indiewebcamp.com/irc/2016-04-25#t1461606553653

<div class="discussion">
* +0 [[User:Kylewm|Kylewm]] on replacing "T" as the separator. Would you please clarify whether that is only for value class pattern/assembling dates from components, or is it proposing to *always* normalize dt's?
* +1 [[User:Kylewm|Kylewm]] on not implying seconds
</div>

=== implied name when alt="" ===

The implied name rule

* else if .h-x>img:only-child[alt]:not[.h-*] then use that img alt for name

is slightly under-specified for the case where alt is provided but intentionally blank. The desired behavior is to use the img alt tag only if it is non-empty. For example:

<pre>
<a class="h-card" href="https://kylewm.com">
<img src="https://kylewm.com/photo.jpg" alt="">
Kyle
</a>
</pre>

The PHP and JS parsers already seem to return the desired result ("Kyle" in the above example). The Python parser uses the alt text and returns "".

Proposal: modify the spec to explicitly exclude these tags:

* else if .h-x>img:only-child[alt]:not([alt=""]):not[.h-*] then use that img alt for name

And audit the other implied rules for similar cases.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] this makes sense to me, and as far as I can tell, for the other cases too for *implied* properties:
** area[alt], abbr[title], and all other attributes where there is an existence test, there should be a :not[alt=""] empty test, for implied p-name, u-photo, u-url
* +1 [[User:GRegorLove|gRegor]] sounds good to me.
* ...
</div>

=== img fallback in p- ===
Trying to make an author h-card without too many extra elements I first did:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" >mention.tech</a>
</div></pre>

rather than:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" alt="">mention.tech</a>
</div></pre>

I was surprised that the p-name and p-org took the src and the plaintext and concatenated them giving <code>http://mention-tech.appspot.com/static/logo.jpgmention.tech</code>, though that is the current spec (a separate php-mf2 bug ignored the empty alt when I added it).

While this is what the spec says, I can't think of a scenario where concatenating a string to a URL gives a useful result. Instead, if we fallback on the src of an img due to it having no alt I propose we put a space on beginning and end. As whitespace is stripped from beginning and end of p- values, this should still give the url in the simplest case, but avoid creating nonsensical URLs in cases like this.

=== de-dupe URLs? ===
Currently, Known templates end up linking to the author's url in the h-card twice. This leads to duplicate URLs in the parsed output, which make jf2 conversion insert a children element.
Should we be deduping URLs? Or is this a GIGO issue?

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

=== 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 this twitter markup]

(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)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 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?

Should "p-name" still be implied if another explicit class is already provided?

Here is a somewhat contrived "u-url" related example, 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)
*** -0 failed consensus, this proposal is rejected. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
** 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
**** though if there is an img with u-featured but not u-photo, it's likely that was an explicit author decision (e.g. for an article) - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** Especially difficult to make a case for name.
**** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
**** Yet over-implied p-names appear to cause problems with many Bridgy webmention consuming use-cases[https://indiewebcamp.com/irc/2016-04-01/line/1459530869915], that's a good case - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
**** may need a broader rule, like any explicit p-* property on an element stops implied p-name. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** ... 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-04-22T00:45:26Z

Kylewm: /* implied name when alt="" */ proposal

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.

=== implied name when alt="" ===

The implied name rule

* else if .h-x>img:only-child[alt]:not[.h-*] then use that img alt for name

is slightly under-specified for the case where alt is provided but intentionally blank. The desired behavior is to use the img alt tag only if it is non-empty. For example:

<pre>
<a class="h-card" href="https://kylewm.com">
<img src="https://kylewm.com/photo.jpg" alt="">
Kyle
</a>
</pre>

The PHP and JS parsers already seem to return the desired result ("Kyle" in the above example). The Python parser uses the alt text and returns "".

Proposal: modify the spec to explicitly exclude these tags:

* else if .h-x>img:only-child[alt]:not([alt=""]):not[.h-*] then use that img alt for name

And audit the other implied rules for similar cases.

=== img fallback in p- ===
Trying to make an author h-card without too many extra elements I first did:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" >mention.tech</a>
</div></pre>

rather than:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" alt="">mention.tech</a>
</div></pre>

I was surprised that the p-name and p-org took the src and the plaintext and concatenated them giving <code>http://mention-tech.appspot.com/static/logo.jpgmention.tech</code>, though that is the current spec (a separate php-mf2 bug ignored the empty alt when I added it).

While this is what the spec says, I can't think of a scenario where concatenating a string to a URL gives a useful result. Instead, if we fallback on the src of an img due to it having no alt I propose we put a space on beginning and end. As whitespace is stripped from beginning and end of p- values, this should still give the url in the simplest case, but avoid creating nonsensical URLs in cases like this.

=== de-dupe URLs? ===
Currently, Known templates end up linking to the author's url in the h-card twice. This leads to duplicate URLs in the parsed output, which make jf2 conversion insert a children element.
Should we be deduping URLs? Or is this a GIGO issue?

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

=== 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 this twitter markup]

(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)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 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?

Should "p-name" still be implied if another explicit class is already provided?

Here is a somewhat contrived "u-url" related example, 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)
*** -0 failed consensus, this proposal is rejected. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
** 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
**** though if there is an img with u-featured but not u-photo, it's likely that was an explicit author decision (e.g. for an article) - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** Especially difficult to make a case for name.
**** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
**** Yet over-implied p-names appear to cause problems with many Bridgy webmention consuming use-cases[https://indiewebcamp.com/irc/2016-04-01/line/1459530869915], that's a good case - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
**** may need a broader rule, like any explicit p-* property on an element stops implied p-name. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** ... 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-04-22T00:43:24Z

Kylewm: /* implied name when alt="" */ new issue

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.

=== implied name when alt="" ===

The implied name rule

* else if .h-x>img:only-child[alt]:not[.h-*] then use that img alt for name

is slightly under-specified for the case where alt is provided but intentionally blank. The desired behavior is to use the img alt tag only if it is non-empty. For example:

<pre>
<a class="h-card" href="https://kylewm.com">
<img src="https://kylewm.com/photo.jpg" alt="">
Kyle
</a>
</pre>

The PHP and JS parsers already seem to return the desired result ("Kyle" in the above example). The Python parser uses the alt text and returns "".

=== img fallback in p- ===
Trying to make an author h-card without too many extra elements I first did:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" >mention.tech</a>
</div></pre>

rather than:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" alt="">mention.tech</a>
</div></pre>

I was surprised that the p-name and p-org took the src and the plaintext and concatenated them giving <code>http://mention-tech.appspot.com/static/logo.jpgmention.tech</code>, though that is the current spec (a separate php-mf2 bug ignored the empty alt when I added it).

While this is what the spec says, I can't think of a scenario where concatenating a string to a URL gives a useful result. Instead, if we fallback on the src of an img due to it having no alt I propose we put a space on beginning and end. As whitespace is stripped from beginning and end of p- values, this should still give the url in the simplest case, but avoid creating nonsensical URLs in cases like this.

=== de-dupe URLs? ===
Currently, Known templates end up linking to the author's url in the h-card twice. This leads to duplicate URLs in the parsed output, which make jf2 conversion insert a children element.
Should we be deduping URLs? Or is this a GIGO issue?

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

=== 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 this twitter markup]

(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)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 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?

Should "p-name" still be implied if another explicit class is already provided?

Here is a somewhat contrived "u-url" related example, 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)
*** -0 failed consensus, this proposal is rejected. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
** 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
**** though if there is an img with u-featured but not u-photo, it's likely that was an explicit author decision (e.g. for an article) - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** Especially difficult to make a case for name.
**** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
**** Yet over-implied p-names appear to cause problems with many Bridgy webmention consuming use-cases[https://indiewebcamp.com/irc/2016-04-01/line/1459530869915], that's a good case - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
**** may need a broader rule, like any explicit p-* property on an element stops implied p-name. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** ... 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-13T23:40:55Z

Kylewm: /* exclude style elements before parsing */ grammar

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)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 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-13T23:40:28Z

Kylewm: /* exclude style elements before parsing */ +1 barnabywalters narrowed proposal for <script> and <style> tags

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)
** +1 Totally agree with the narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 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]]