microformats2-parsing-faq: Difference between revisions
(which backcompat root classes) |
WillNorris (talk | contribs) (add question about empty attribute values) |
||
| Line 39: | Line 39: | ||
The p- u- dt- e- prefixes are basically parse-time directives that are dropped once parsing is done and you collect the properties/values into your JSON parse tree. | The p- u- dt- e- prefixes are basically parse-time directives that are dropped once parsing is done and you collect the properties/values into your JSON parse tree. | ||
=== empty property values === | |||
Q: [[microformats2-parsing]] lists many selectors of the form "abbr.p-x[title]". Is this intended to also match attributes with empty values? | |||
A: Yes, the assumption is that the inclusion of an empty attribute value was a deliberate action by the author. | |||
=== add another question topic here === | === add another question topic here === | ||
Revision as of 20:26, 19 March 2015
<entry-title>microformats2-parsing-faq</entry-title>
This page documents answers to frequently (or expected to be) asked questions about microformats2-parsing.
For questions about microformats2 in general, see microformats2-faq.
questions
which backcompat root classes
Q: Which backcompat root classes should a microformats2 parser support?
A: The microformats2 specification lists which microformats2 vocabularies are ready for use, and each of those lists their classic microformat (if any) that has sufficiently broad use and support to be included in the set of backcompat root classes that a microformats2 parser should support. Here they are in a list: (each is linked to the backcompat parsing section in its respective microformats2 vocabulary specification)
normalizing u-* property values
Q: In the Parsing u-* section, shouldn't item 5 (if there is a gotten value…) be at the end of the section? Shouldn't normalizing apply wherever the value comes from? (question from IRC, 2012-296).
A: Normalizing u-* property values occurs exactly where necessary and no more. In particular, normalizing only when present in URL attributes follows the semantics of those attributes (normalization to absolute URLs) per the HTML5 specification, whereas when the value is present in a title attribute or in text, the expectation, in both normal usage and in the browser, is that such values are displayed and used as is without any normalization.
checking for explicit properties before implying
Q: When checking for whether or not to look for implied properties, should the parser look for an explicit "p-name" in particular or "*-name" in the list of parsed property names?
A: Before implying a "name" property, look for the unprefixed property, e.g. "name", not "p-name" nor "*-name".
In the JSON set of parsed property names, there are no prefixes (e.g. see the "Parsed JSON" examples in microformats2).
The order of operations in the parsing algorithm is explicit about this: parsers only imply properties after parsing an element for all explicit properties, per parse an element for microformats.
Parsing for implied properties specifically refers to "name", "photo", and "url": parsing for implied properties - all unprefixed versions of the property names.
The p- u- dt- e- prefixes are basically parse-time directives that are dropped once parsing is done and you collect the properties/values into your JSON parse tree.
empty property values
Q: microformats2-parsing lists many selectors of the form "abbr.p-x[title]". Is this intended to also match attributes with empty values?
A: Yes, the assumption is that the inclusion of an empty attribute value was a deliberate action by the author.
add another question topic here
Q: What's the question?
A: We have an answer.