microformats2-parsing-faq: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (g)
m (Replace <entry-title> with {{DISPLAYTITLE:}})
 
(7 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<entry-title>microformats2-parsing-faq</entry-title>
{{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 ===
Q: In the [[microformats2-parsing#parsing_a_u-_property|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).
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 [[microformats2-parsing#parse_an_element_for_microformats|parse an element for microformats]].
 
Parsing for implied properties specifically refers to "name", "photo", and "url": [[microformats2-parsing#parsing_for_implied_properties|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: 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.
A: We have an answer.


== see also ==
== see also ==
Line 16: 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.

see also