microformats2-parsing-faq - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:30:05Z

Replace <entry-title> with {{DISPLAYTITLE:}}

← Older revision		Revision as of 16:30, 18 July 2020
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]].

Tantek: /* normalizing u-* property values */ question is now historical, resolved in a way that eliminates the original question

2018-12-24T21:53:13Z

normalizing u-* property values: question is now historical, resolved in a way that eliminates the original question

← Older revision		Revision as of 21:53, 24 December 2018
Line 23:		Line 23:

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

	~~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~~.		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 ===

Benthatmustbeme: /* which backcompat root classes */ broken section links

2017-05-01T13:30:18Z

which backcompat root classes: broken section links

← Older revision		Revision as of 13:30, 1 May 2017
Line 11:		Line 11:
	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)		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_Compatiblity~~\|adr]]		* [[h-adr#Backward_Compatibility\|adr]]
	* [[h-geo#~~Backward_Compatiblity~~\|geo]]		* [[h-geo#Backward_Compatibility\|geo]]
	* [[h-entry#~~Backward_Compatiblity~~\|hentry]]		* [[h-entry#Backward_Compatibility\|hentry]]
	* [[h-product#~~Backward_Compatiblity~~\|hproduct]]		* [[h-product#Backward_Compatibility\|hproduct]]
	* [[h-recipe#~~Backward_Compatiblity~~\|hrecipe]]		* [[h-recipe#Backward_Compatibility\|hrecipe]]
	* [[h-resume#~~Backward_Compatiblity~~\|hresume]]		* [[h-resume#Backward_Compatibility\|hresume]]
	* [[h-review#~~Backward_Compatiblity~~\|hreview]]		* [[h-review#Backward_Compatibility\|hreview]]
	* [[h-review-aggregate#~~Backward_Compatiblity~~\|hreview-aggregate]]		* [[h-review-aggregate#Backward_Compatibility\|hreview-aggregate]]
	* [[h-card#~~Backward_Compatiblity~~\|vcard]]		* [[h-card#Backward_Compatibility\|vcard]]
	* [[h-event#~~Backward_Compatiblity~~\|vevent]]		* [[h-event#Backward_Compatibility\|vevent]]

	=== normalizing u-* property values ===		=== normalizing u-* property values ===

WillNorris: add question about empty attribute values

2015-03-19T20:26:26Z

add question about empty attribute values

← Older revision		Revision as of 20:26, 19 March 2015
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 ===

Tantek: which backcompat root classes

2014-04-11T20:41:59Z

which backcompat root classes

← Older revision		Revision as of 20:41, 11 April 2014
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_Compatiblity\|adr]]
			* [[h-geo#Backward_Compatiblity\|geo]]
			* [[h-entry#Backward_Compatiblity\|hentry]]
			* [[h-product#Backward_Compatiblity\|hproduct]]
			* [[h-recipe#Backward_Compatiblity\|hrecipe]]
			* [[h-resume#Backward_Compatiblity\|hresume]]
			* [[h-review#Backward_Compatiblity\|hreview]]
			* [[h-review-aggregate#Backward_Compatiblity\|hreview-aggregate]]
			* [[h-card#Backward_Compatiblity\|vcard]]
			* [[h-event#Backward_Compatiblity\|vevent]]

	=== normalizing u-* property values ===		=== normalizing u-* property values ===

Tantek: /* see also */ see also faq

2012-10-23T20:13:55Z

Tantek: checking for explicit properties before implying

2012-10-23T20:12:28Z

checking for explicit properties before implying

← Older revision		Revision as of 20:12, 23 October 2012
Line 11:		Line 11:

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

	=== add another question topic here ===		=== add another question topic here ===

Tantek: sample Q&A to make the TOC show up

2012-10-23T16:15:46Z

sample Q&A to make the TOC show up

← Older revision		Revision as of 16:15, 23 October 2012
Line 11:		Line 11:

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

			=== add another question topic here ===
			Q: What's the question?

			A: We have an answer.

	== see also ==		== see also ==

Tantek: g

2012-10-23T10:18:15Z

← Older revision		Revision as of 10:18, 23 October 2012
Line 7:		Line 7:
	== questions ==		== questions ==

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

	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 both in normal usage and in the browser, such values are displayed and used as is without any normalization.		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.

	== see also ==		== see also ==

Tantek: drafted

2012-10-23T10:17:14Z

drafted

New page

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

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

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 both in normal usage and in the browser, such values are displayed and used as is without any normalization.

== see also ==
* [[microformats2]]
* [[microformats2-parsing]]
* [[microformats2-parsing-brainstorming]]

← Older revision		Revision as of 13:30, 1 May 2017
Line 11:		Line 11:
	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)		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_Compatiblity~~\|adr]]		* [[h-adr#Backward_Compatibility\|adr]]
	* [[h-geo#~~Backward_Compatiblity~~\|geo]]		* [[h-geo#Backward_Compatibility\|geo]]
	* [[h-entry#~~Backward_Compatiblity~~\|hentry]]		* [[h-entry#Backward_Compatibility\|hentry]]
	* [[h-product#~~Backward_Compatiblity~~\|hproduct]]		* [[h-product#Backward_Compatibility\|hproduct]]
	* [[h-recipe#~~Backward_Compatiblity~~\|hrecipe]]		* [[h-recipe#Backward_Compatibility\|hrecipe]]
	* [[h-resume#~~Backward_Compatiblity~~\|hresume]]		* [[h-resume#Backward_Compatibility\|hresume]]
	* [[h-review#~~Backward_Compatiblity~~\|hreview]]		* [[h-review#Backward_Compatibility\|hreview]]
	* [[h-review-aggregate#~~Backward_Compatiblity~~\|hreview-aggregate]]		* [[h-review-aggregate#Backward_Compatibility\|hreview-aggregate]]
	* [[h-card#~~Backward_Compatiblity~~\|vcard]]		* [[h-card#Backward_Compatibility\|vcard]]
	* [[h-event#~~Backward_Compatiblity~~\|vevent]]		* [[h-event#Backward_Compatibility\|vevent]]

	=== normalizing u-* property values ===		=== normalizing u-* property values ===

← Older revision		Revision as of 20:41, 11 April 2014
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_Compatiblity\|adr]]
			* [[h-geo#Backward_Compatiblity\|geo]]
			* [[h-entry#Backward_Compatiblity\|hentry]]
			* [[h-product#Backward_Compatiblity\|hproduct]]
			* [[h-recipe#Backward_Compatiblity\|hrecipe]]
			* [[h-resume#Backward_Compatiblity\|hresume]]
			* [[h-review#Backward_Compatiblity\|hreview]]
			* [[h-review-aggregate#Backward_Compatiblity\|hreview-aggregate]]
			* [[h-card#Backward_Compatiblity\|vcard]]
			* [[h-event#Backward_Compatiblity\|vevent]]

	=== normalizing u-* property values ===		=== normalizing u-* property values ===

← Older revision		Revision as of 20:13, 23 October 2012
Line 34:		Line 34:
	* [[microformats2-parsing]]		* [[microformats2-parsing]]
	* [[microformats2-parsing-brainstorming]]		* [[microformats2-parsing-brainstorming]]
			* [[microformats2-faq]]