microformats2-parsing-faq: Difference between revisions
(checking for explicit properties before implying) |
m (Replace <entry-title> with {{DISPLAYTITLE:}}) |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{DISPLAYTITLE:microformats2-parsing-faq}} | |||
This page documents answers to frequently (or expected to be) asked questions about [[microformats2-parsing]]. | This page documents answers to frequently (or expected to be) asked questions about [[microformats2-parsing]]. | ||
| Line 6: | Line 6: | ||
== questions == | == questions == | ||
=== which backcompat root classes === | |||
Q: Which backcompat root classes should a [[microformats2]] parser support? | |||
A: The microformats2 specification lists [[microformats2#v2_vocabularies|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) | |||
* [[h-adr#Backward_Compatibility|adr]] | |||
* [[h-geo#Backward_Compatibility|geo]] | |||
* [[h-entry#Backward_Compatibility|hentry]] | |||
* [[h-product#Backward_Compatibility|hproduct]] | |||
* [[h-recipe#Backward_Compatibility|hrecipe]] | |||
* [[h-resume#Backward_Compatibility|hresume]] | |||
* [[h-review#Backward_Compatibility|hreview]] | |||
* [[h-review-aggregate#Backward_Compatibility|hreview-aggregate]] | |||
* [[h-card#Backward_Compatibility|vcard]] | |||
* [[h-event#Backward_Compatibility|vevent]] | |||
=== normalizing u-* property values === | === normalizing u-* property values === | ||
This question is historical. | |||
Originally relative URL resolution occurred part way through parsing for a u-* property value (this FAQ asked why), however https://github.com/microformats/microformats2-parsing/issues/10 the spec was updated to always do relative URL resolution for u-* property values. | |||
=== checking for explicit properties before implying === | === checking for explicit properties before implying === | ||
| Line 24: | 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 === | ||
| Line 34: | Line 55: | ||
* [[microformats2-parsing]] | * [[microformats2-parsing]] | ||
* [[microformats2-parsing-brainstorming]] | * [[microformats2-parsing-brainstorming]] | ||
* [[microformats2-faq]] | |||
Latest revision as of 16:30, 18 July 2020
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
This question is historical.
Originally relative URL resolution occurred part way through parsing for a u-* property value (this FAQ asked why), however https://github.com/microformats/microformats2-parsing/issues/10 the spec was updated to always do relative URL resolution for u-* property values.
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.