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

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.

+0 willnorris (+1 to saying that microformats parsers should standardize on UTF-8 for e-* text, however I feel like e-* html should be left as unscathed as possible. html encoding may harken to a time before UTF-8, but if the content was authored that way, shouldn't necessary be changing that)

Noscript skip/parse

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.

html5lib actually HTML-escapes the contents of <noscript>, so to mf2py it just looks like plain text with no tags. In Woodwind, I've resorted to using regex to strip out <noscript> tags before parsing (very hacky). Kylewm 15:52, 25 August 2015 (UTC)

-1 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 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 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 <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)

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

+1 in theory to stripping it out for the same reasons Tantek mentioned above. I haven't tested this in go, but would be surprised if it had issues. WillNorris 22:37, 5 June 2016 (UTC)

...

implied properties when an explicit class is provided

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

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. Tantek 06:26, 21 January 2015 (UTC)

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. 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 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. Kylewm 00:46, 1 December 2015 (UTC)

Refined: Or should this be refined by per parsing prefix? 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-*,.u-*]". Kylewm 00:46, 1 December 2015 (UTC)

whitespace collapsing revisited

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

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.

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 though this doesn't solve any of the problems discussed above, it's still worth doing 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 Kylewm 20:45, 8 June 2015 (UTC)

2015-06-08 option 2 resolved by consensus and implementation in mf2py.

Somewhat orthogonal:

make value 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. Tantek 20:45, 27 May 2015 (UTC)

make implied name normalise whitespace.

+0 This is reasonable and already done somewhat in the parsing spec (trim lead/trailing). Tantek 20:45, 27 May 2015 (UTC)

+1 Given the universality of name, this would fix most of the issues we see. Kevin Marks 16:41, 28 May 2015 (UTC)

Put \n in textual forms if there is a <p> tag in the original.

-1 that's a long path to go down with whitespace equivalents for HTML markup. Tantek 20:45, 27 May 2015 (UTC)

would only preserving whitespace if in <pre> be an 80:20 compromise? 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). 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.
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.
Kevin Marks 09:07, 11 July 2015 (UTC)

e- parsing iframe srcdoc

Proposal: addition of a new e-* parsing rule for iframe elements with srcdoc attributes. E.G.

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

'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 'given-name': ['Ben'] and 'family-name': ['Ward']. 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 h-card as having a p-name. But, the parser is generic, so it also treats h-review, h-entry, h-recipe, h-geo as having a ‘p-name’.

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. Tantek 13:48, 4 October 2011 (UTC)

In existing microformats, the closest existing example we have for this is the label property in hCard, which is used to represent the literal address label for a place. It is a corresponding piece of fn, org and adr in combination, but has no structure in and of itself. Possibly, every microformat could have a label form where structured data is unavailable.

However in practice, the hCard label 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, value is used throughout microformats to target a generic value (e.g. in combination with price in hListing.) It has been proposed that when parsing properties that are also themselves microformats, we create native objects of the form:

In this case, an interpreter or implementation is responsible for using value in place of fn, 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: 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. —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'. 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'. 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'. Tantek 13:48, 4 October 2011 (UTC)

0 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. Tantek 20:37, 13 March 2016 (UTC)

+1 I like the revised proposal and am happy to change my vote to this 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) Kylewm 23:40, 13 March 2016 (UTC)

possibly a way to implement a distributed HTTP webcache retrieval protocol

Thoughts?

+1 Tantek I think we should have this, but am open to proposals on specifics!

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

-1 Agree with Kyle above... this sounds like a great tool that someone should build and we could even publish "recommended" markup if you don't already have your own template, but this doesn't really belong in the mf2 spec itself. WillNorris 22:32, 5 June 2016 (UTC)

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

use poster if no src on video for u props

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 u- property parsing to look at the poster attribute of the video element, after it's looked for the src attribute.

de-dupe URLs?

2016-06-05. REJECTED. NO SPEC CHANGE.

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?

-1 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 [2])

-1 Tantek on de-duping for mf2 json. jf2 can do what it prefers, no specific opinion on that.

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:

Proposal:

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.

namespacing for better integrability

2016-06-05. REJECTED.

All the implied class names may conflict with existing stylesheets, because the prefixes used are too short and are not proper namespaces for what follows them ("p-", "u-", "e-", "h-", "dt-", "x-", ...) and too many of these short prefixes are used.

You should add the support for namespacing with arbitrary "MYCARD" name usiong a second class on the same root element that uses class "h-card":

This is important because tools are autogenerating class names and stylesheets for HTML and associate them with other functions not intended for vCards.

In fact this support should be added in ALL microformats, not just for vCards...

And this will reduces a lot the ambiguities in microformat parsers by allowing them to be more selective (in fact the namespace being used as a common prefix for all properties, parsers could be faster, additionally it would allow easier editing on vcards in HTML, for operations like finds/replace, or even for automated replacements using regexp searches.

It would also allow nested vcards created from different tools using their own private extensions, to not conflict each other on these extensions, if they can be properly namespaced.

Note: these defined namespaces are automatically replacable by parsers if they regenerate a new composite document (they could be removed by tools if there are no conflict, or shortened, or made unique by changing them with another arbitrary name).

The other solution would be to use namespaces on the HTML attribute names themselves, notably class:

But this solution will not work reliably in strict XHTML or XML parsers if there's no XML namespace definition, or this could invalidate the document on basic DOM parsers for HTML (e.g. in MediaWiki, unknown HTML attributes are discarded so that MYCARD:class="..." would not appear at all in the final HTML, only class="..." is accepted).

Finally, it woul allow the coexistence of multiple microformats coexisting in the same document (only the root element is distinctive, but the "p-*", "u-*", "dt-*" elements will collide: which microformat should interpret them? It is easy to solve by assigning to the root ("h-<microformat>" element for each microformat a namespace that will be used in their content, such as "h-card-ns-MYCARD" for assigning the "MYCARD" namespace to the "h-card" microformat, or "h-goog-doc-ns-MYDOC" to assign the "MYDOC" namespace to the "h-goog-doc" microformat that google may want to develop for Google Docs, or "h-x-doubleclick-X78954218" for assigning the "X78954218" namespace that would be used in a "x-doubleclick" custom microformat developed by doubleclick with contents using "X78954218-p-*", "X78954218-u-*", "X78954218-e-*", "X78954218-dt-*").

-1 agreed with gRegor above. I would certainly want to see real world parsing problems before adding just a heavyweight "solution". WillNorris 21:16, 5 June 2016 (UTC)

-1 Tantek: historically none of these namespace setting/using proposals have actually survived in the wild on the web, they all get co-opted to treating the shorthands/prefixes in a hardcoded way, e.g. og: etc. All evidence to date is against such proposals, plus there's no concrete examples provided to motivate this change, only theory.

+1: you've stiull not understood the issue: there are too many collisions with the too many short prefixes used by microformats and actual class names needed and already used in many websites. This means that the recommended classnames in this specification are simply unusable as it is in fact imposible to say if what is in the page is actually a microformat or not, without forcinf sites to also change all their existing stylesheets and application code to not collide with the microformats they'd like to support. At least microformats should all have a "root" element with a single distinctive name, required before parsing any other classes in child elements. This root element should then be "h-microformat". I have seem too many examples with "h-card", "h-event", and so on colliding, producing false results when parsing pages, but another way to do that would be to not just use a "h-card" class to recognize it as a root, but match two classes (i.e. "h-card h-uF-2", the second class "h-uF-2" indicating its specification version). This would have the same effect as namespaces and would allow parsers to discriminate the page contents more precisely when there are collisions, by using an additional filter (the presence of the second class gives additional hint about how parsers can validate and use more strict rules when needed, or perform more checks (it would also allow evolution of the specifications while preserving some compatibility (let's forget the old v1 without any prefix and with collisions on almost all sites, as demosntrated by various "web form filler robots" that constantly need to update their database of known websites, each time their design is changed or there's a new page using forms with data fields named "name", "address", "date" to avoid producing false matches...).

Note that this page is an archive of issues and their discussion before 2016-06-20. This specific issue was rejected 2016-06-05. Current and new issue discussion is now at: https://github.com/microformats/microformats2-parsing/issues. You're welcome to open an issue there to discuss further, but I don't expect it will get much traction. If you do open a new issue, I'd recommend adding some example URLs to demonstrate the issue. gRegor 00:32, 26 November 2017 (UTC)

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. Glenn Jones 11:02, 29 July 2015 (UTC)

-1 Tantek we are maintaining whole properties as authored, with authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string, and vcp cases handled in separate issue.

Consensus in room at IWC 2016 session also. Resolving accordingly.

implied date for dt properties both mf2 and backcompat

2016-06-04 (before). ACCEPTED. SPEC UPDATED.

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

+0 Tantek slight pref (but unsure) for replace a "T" separator with a single space in other dt-* parsing.

+1 Glenn happy to move to single space separator for dates built from the value-class pattern.

-1 Glenn I think we should pass through the authored format of a date as default output. We should process the content as little as possible, so it is as authored. We can then add parser options to force one of the date formats such as ISO profiles HTML5 or W3C if we need consistency. This is the approach I have taken.

+1 Glenn on not implying seconds. Authored level of specificity should always be kept in dates.

Consensus resolutions:

Drop value-class-pattern implying 00 seconds. Note: keeping/implying 00 minutes due to common human usage of whole hours to specifically mean "on the hour" which is 00 minutes. The same implied precision does not exist for seconds in practice.

ignore u-camelCase properties

Due to Suit CSS (and others? citations?) recent (2015-?) use of "u-*" class names for so-called "utility classes", we are seeing some false positives in a few very rare instances, e.g.: 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.

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 [3]. The bug with the wordpress mf2 plugin is resolved as of 2013-10-22 --bw 13:38, 22 October 2013 (UTC)

e- and p- escaping levels

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:

input

output

<pclass="h-card"><spanclass="p-name">&lt;tag&gt;</span></p>

{"items":[{"type":["h-card"],"properties":{"name":["<tag>"]}}]}

<pclass="h-card"><spanclass="e-name">&lt;tag&gt;</span></p>

{"items":[{"type":["h-card"],"properties":{"name":["&lt;tag&gt;"]}}]}

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. --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. - 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? - 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 --bw 12:55, 5 July 2013 (UTC)

We should also decide exactly which characters get encoded — just angle brackets, or quotes/ampersands as well? --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. --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 --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.

per 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. - Tantek 18:07, 17 October 2013 (UTC)

Should we not encode e-* as well and the consumer can decode at their own risk --Glenn Jones 18:42, 21 July 2013 (UTC)

Resolved by changes to the parsing spec: all properties are plaintext (non-HTML escaped), e-* properties result in a dictionary with value = plaintext version, html = raw HTML version

br hr empty string

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 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 <span class="p-foo"></span> 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. - Tantek 15:29, 10 February 2013 (UTC)

datetime examples without T delimiter

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

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 " " as a separator between date and time as well as "T", thus we allow it for microformats as well. The " " 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. - Tantek 18:48, 15 July 2013 (UTC)

rel-alternate absent optional attributes

What should rel-alternate parsing do when one of the optional attributes specified (hreflang or media 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. —Tom Morris 15:41, 9 August 2013 (UTC)

rel-alternate and type attribute

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. - Tantek 00:47, 15 September 2013 (UTC)

Extraction vs Interpretation

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, abbr 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 fn pattern in hcard, or the lat;long 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. 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). 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 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). 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 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 format-specificproblems 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. Tantek 12:43, 4 October 2011 (UTC)

This issue can be moved from resolved to closed once the above-mentioned write-ups have occurred.

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 href attribute on <a> and <area> 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. Tantek 07:39, 5 October 2011 (UTC)

Continuing use of the rel 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 bookmark, in place of permalink.

All microformats that use rel-tag would contain a property named… tag. Perfect.

Since rel attributes are not overloaded for other functionality like class is, and other uses of rel 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.

This sounds like it might be workable. Let's try it and see how well authors "get it". - 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). - Tantek

None that I can think of in microformats. There is the case of Google's rel=author and p-author 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:

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

{'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" */}}

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

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.

+1 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 rels and rel-urls 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. Kevin Marks 00:23, 2 June 2015 (UTC)

Empty properties overridden by implied rules against user expectation

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:

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

+1 I believe this is inline with how we parse properties and will meet user/author expectations Glenn Jones 9:22, 3 July 2015 (UTC)

-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. 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) 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. Tantek 05:12, 14 July 2015 (UTC)

2. We should not execute the "implied rules" where there is an author defined "empty" property.

-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. Glenn Jones 9:22, 3 July 2015 (UTC)

+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) 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. 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. Glenn Jones 11:51, 29 July 2015 (UTC)

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.

2. Show up in the children collection of the classic microformats root

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.

any h- root class name overrides and stops backcompat root

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. Tantek 04:55, 21 January 2015 (UTC)

Thoughts?

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? Glenn Jones 12:13, 29 July 2015 (UTC)

added "on that same element" as that was what we were discussing/implying in this issue. Tantek 22:49, 18 September 2015 (UTC)

backcompat classic microformats should only see backcompat properties

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

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. Glenn Jones 11:55, 29 July 2015 (UTC)

++ Consensus at 2015-01-20 - option that presents the least surprises in the most cases.

microformats2 root class names should only see microformats2 properties

2015-020: When parsing a microformats2 root class name, only explicit microformats2 properties should be parsed. Any backcompat property names must be ignored.
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?

+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. Glenn Jones 11:55, 29 July 2015 (UTC)

++ Consensus at 2015-01-20 - option that presents the least surprises in the most cases.

implied properties on backcompat parsing unlikely to be intended

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. Tantek 02:43, 30 December 2014 (UTC)
Examples:

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

link elements and u- parsing

Raised by tantek on 2014-07-08 on irc: should the parsing specification for handling u- properties be modified to include the link element? The potential downside is that invisible-metadata-is-considered-harmful, however all known real world examples of link are semi-visible data (not fully hidden).

There are potential cases for wanting to use link as an alternative to a (and area), such as a whole page where the root html element is an h-card and the properties are included across the page: some in visible data in the body while others are in the head as link elements. Example:

One specific use-case is the semi-visible link rel="shortcut icon" href="..." - 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 u-photo or u-logo of the containing h-* object on the html element.

Another use-case is publishing links to PGP/GPG keys linked from the head which is currently handled by <link rel=pgpkey> which is already supported in existing microformats2 rel parsing of link rel elements. Thus there is a (admittedly weak) argument for consistently parsing both<link rel>and<link class="u-*">.

The slightly stronger argument for consistency of link handling is that it simplifies the publisher (and parser) model:

<a> and <area> work for both rel and class

why does <link> only work for rel ?

it would be simpler if all three tags just worked (in the same way) for both rel and class

Should the parsing spec be modified to handle these cases? —Tom Morris 09:25, 9 July 2014 (UTC)

I'm generally in favour. It'd be good to see what other parser developers think. —Tom Morris 10:16, 9 July 2014 (UTC)

adding this to the parsers won't be an issue. The question is should the door be opened to hidden mf data?Up on further reflection, there seems to be no need to distinguish between rel=property and class=u-property on link elements. So I am in favour for consistency.Kartik 18:30, 2014-07-09 (EST)

drop "alternates" as its no longer needed, and all current consuming code clients like rel-urls better anyway.

+1 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. Tantek 03:42, 6 June 2015 (UTC)