This page documents issues with the microformats2-parsing specification before 2016-06-20.
See https://github.com/microformats/microformats2-parsing/issues for current and new issues!
See change control for how to move issues forward.
Note: all current issues resolved as of 2016-06-04
Open issues in various states of partial resolution from none to nearly resolved.
STATUS: 2016-06-05 apparent implementers consensus at IndieWeb Summit issues resolution session.
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: this case
Should mf parsers skip <noscript> tag in the HTML, like the <template> tag mentioned in http://microformats.org/wiki/microformats2-parsing#note_HTML_parsing_rules ?
mf2py skips <noscript> when using the html5lib DOM parser but no when using lxml parser. Example use of <noscript> https://kartikprabhu.com/ featured images have a no javascript fallback image inside <noscript> with class='u-featured' markup.
As a separate new point we need to consider "exclude tags" lists for parsed text from html. We should consider <noscript>, <noframe> and <template> 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 <video>, <audio> 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 <video> is added to the parse text. 12:56, 25 Septemeber 2015 (UTC)
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.
In this case, http://orig.domain/baz is almost certainly not the u-url, so IMO it would be better to leave it out —Kylewm 15:10, 7 October 2014 (UTC)
2015-01-20 consensus
Proposed resolution:
2015-05-27: (raised by 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: this test shows how extraneous whitespace ends up in the name
give a parsed result of:
The value is a reasonable textual representation of the event, but the implied name is full of spurious whitespace that any consumer would have to strip.
h-review has similar issues
2015-05-28: (Addition by 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.
The output for the name property from the above HTML would be Glenn\r\n Jones 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 <pre> 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 <pre> 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.
2015-06-08 option 2 resolved by consensus and implementation in mf2py.
Somewhat orthogonal:
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). Tantek
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. Kevin Marks 09:07, 11 July 2015 (UTC)
More controversially, what about using an iframe for transclusion? A use case here