microformats2 parsing specification - Microformats Wiki

microformats2 is a simple, open format for marking up data in HTML. The microformats2 parsing specification describes how to implement a microformats2 parser, independent of any specific vocabularies.
To parse a document for microformats, follow the HTML parsing rules and do the following:
Parsers may simultaneously parse the document for both class and rel microformats (e.g. in a single tree traversal).
To parse an element for class microformats:
The "*" for root (and property) class names consists of an optional vendor prefix (series of 1+ number or lowercase a-z characters i.e. [0-9a-z]+, followed by '-'), then one or more '-' separated lowercase a-z words.
To parse an element for a p-x property value (whether explicit p-* or backcompat equivalent):
To parse an element for a u-x property value (whether explicit u-* or backcompat equivalent):
To parse an element for a dt-x property value (whether explicit dt-* or backcompat equivalent):
To parse an element for a e-x property value (whether explicit "e-*" or backcompat equivalent):
Imply properties only on explicit h-x class name root microformat element (no backcompat roots):
Note: The same markup for a property should not be causing that property to occur in both a microformat and one embedded inside - such a property should only be showing up on one of them. The parsing algorithm has details to prevent that, such as the :not[.h-*] tests above.
To parse a hyperlink element (e.g. a or link) for rel microformats: use the following algorithm or an algorithm that produces equivalent results:
Here are some examples to show how parsed rels may be reflected into the JSON (empty items key).
E.g. parsing this markup:
Would generate this JSON:
To parse an img element for src and alt attributes:
This section is non-normative.
Use SelectORacle to expand any of the above CSS selector expressions into longform English prose.
This section is non-normative.
microformats2 parsers are expected to follow HTML parsing rules, which includes for example:
'spaces' in the algorithm refers to HTML collapsible blank spaces of any kind, whether ' ' or linefeed, carriage return, etc.
The parsing algorithm and details refer to "backcompat root classes" (backcompat roots for short) and "backcompat properties". These conditions and steps in the algorithm document how to parse pre-microformats2 microformats which all defined their own specific root class names and explicit sets of properties.
Some details to be aware of (which are explicitly in the algorithm, this is just an informal summary)
Note: several parser implementations have encoded backward compatible mappings into source and data files. Implementers of parsers may find these useful:
There are open source microformats2 parsers available for Javascript, node.js, PHP, Ruby and Python.
Ports to/for other languages encouraged.
Minor editorial changes (e.g. fixing minor typos or punctuation) that do not change and preferably clarify the structure and existing intended meaning may be done by anyone without filing issues, requiring only a sufficient "Summary" description field entry for the edit. More than minor but still purely editorial changes may be made by an editor. Anyone may question such editorial changes by undoing corresponding edits without filing an issue. Any further reversion or iteration on such an editorial change must be done by filing an issue.
Per the stable status of this document, substantive issue filing, resolution, and edits are done with the following change control steps, which may nearly all be done asynchronously once an issue is filed to reach the required state of "Resolve by implementation verified rough consensus". All steps should be openly documented (e.g. on this wiki or GitHub issues) such that others may later verify the history of an issue, and all steps are encouraged to be announced on #microformats IRC with a link to the issue.
These change control steps are inspired by the tradition of "Rough consensus and running code" as exhibited by example by IETF and W3C processes, and in that regard, seek to be a philosophically compatible approach to specification iteration. They have been in rough practice since 2015-01-21, increasingly strictly applied since then with consensus of issue discussion participants, and explicitly documented based on issue resolving and spec editing experience.