Microformats Wiki - User contributions [en]

microformats2

2017-05-28T11:55:15Z

Myfreeweb: /* Parsers */ Move Haskell parser to the production section

<entry-title>microformats2</entry-title>
Welcome to the microformats2 home page.

== Summary ==
Microformats2 is the simplest way to markup structured information in HTML. Microformats2 improves ease of use and implementation for <em>both</em> authors (publishers) and developers ([[microformats2-parsing|parser]] implementers).

Microformats2 replaces and supersedes both classic microformats, as well as incorporates lessons learned from [[microdata]] and [[RDFa]].

=== simple microformats 2 examples ===
Here are a few simple microformats2 examples along with canonical [[JSON]].

==== person example ====
* Simple person reference:
<source lang=html4strict>
<span class="h-card">Frances Berriman</span>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Frances Berriman"]
}
}]
}
</source>

----

==== hyperlinked person ====
* Simple hyperlinked person reference
<source lang=html4strict>
<a class="h-card" href="http://benward.me">Ben Ward</a>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Ben Ward"],
"url": ["http://benward.me"]
}
}]
}
</source>

----

==== hyperlinked person image ====
* Simple hyperlinked person image
<source lang=html4strict>
<a class="h-card" href="http://rohit.khare.org/">
<img alt="Rohit Khare"
src="https://s3.amazonaws.com/twitter_production/profile_images/53307499/180px-Rohit-sq_bigger.jpg" />
</a>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Rohit Khare"],
"url": ["http://rohit.khare.org/"],
"photo": ["https://s3.amazonaws.com/twitter_production/profile_images/53307499/180px-Rohit-sq_bigger.jpg"]
}
}]
}
</source>

Additional simple cases details in [[microformats-2-implied-properties]].

----

==== detailed person example ====
* More detailed person
<source lang=html4strict>
<div class="h-card">
<img class="u-photo" alt="photo of Mitchell"
src="https://webfwd.org/content/about-experts/300.mitchellbaker/mentor_mbaker.jpg"/>
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="u-url"
href="https://twitter.com/MitchellBaker"
>@MitchellBaker</a>)
<span class="p-org">Mozilla Foundation</span>
<p class="p-note">
Mitchell is responsible for setting the direction and scope of the Mozilla Foundation and its activities.
</p>
<span class="p-category">Strategy</span>
<span class="p-category">Leadership</span>
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"photo": ["https://webfwd.org/content/about-experts/300.mitchellbaker/mentor_mbaker.jpg"],
"name": ["Mitchell Baker"],
"url": [
"http://blog.lizardwrangler.com/",
"https://twitter.com/MitchellBaker"
],
"org": ["Mozilla Foundation"],
"note": ["Mitchell is responsible for setting the direction and scope of the Mozilla Foundation and its activities."],
"category": [
"Strategy",
"Leadership"
]
}
}]
}
</source>

----
Notes:
# The JSON <code>"type"</code> uses the full microformat root class name (e.g. <code>"h-card"</code>) for consistent identification.
# all properties are optional and syntactically plural with parsed values provided in document order; particular microformats (and applications there-of) may apply specific/singular semantics to first value of a property.

=== microformats2 design ===

microformats2 has the following key design aspects:

; Prefixes for class names
: All microformats class names use prefixes. Prefixes are '''syntax independent from vocabularies''', which are developed separately.
* <code>h-*</code> for root class names (e.g. <code>h-card</code>)
* <code>p-*</code> for plain text properties (e.g. <code>p-name</code>)
* <code>u-*</code> for URL properties (e.g. <code>u-photo</code>)
* <code>dt-*</code> for date/time properties (e.g. <code>dt-bday</code>)
* <code>e-*</code> for embedded markup properties (e.g. <code>e-note</code>)<br />

See [[microformats2#naming_conventions_for_generic_parsing|prefix naming conventions]] for more details.

; Flat sets of optional properties
: All microformats consist of a root, and a collection of properties. Hierarchical data is represented with nested microformats, typically as property values themselves. Properties are all optional and potentially multivalued (applications needing a singular semantic may use first instance).

; Single class markup for common uses
: Common simple markup patterns require only a single microformat root class name, which parsers use to find a few generic properties: <code>name</code>, <code>url</code>, <code>photo</code>. The simple microformats2 examples above demonstrate these.

----

Parsing each prefix (including generating canonical JSON) is detailed step-by-step in:
* The '''[[microformats2-parsing|microformats2 parsing specification]]'''

'''Note:''' Most properties are specified and used with a single specific prefix (or occasionally two or three) that is self-evident from context. However, any parsing prefix can be used with any property, especially if you find a good reason to do so!

== v2 vocabularies ==
Status: '''<span id="draft_v2_vocabularies">draft</span>'''. Please review and provide feedback in [[IRC]].
* [[h-adr]]
* [[h-card]]
* [[h-entry]]
* [[h-event]]
* [[h-feed]]
* [[h-geo]]
* [[h-item]]
* [[h-listing]]
* [[h-product]]
* [[h-recipe]]
* [[h-resume]]
* [[h-review]]
* [[h-review-aggregate]]

See below for vocabulary summaries.

=== h-adr ===
{{main|h-adr}}

The '''h-adr''' microformat is for marking up structured locations such as addresses, physical and/or postal. This is an update to [[adr]].

root class name: '''<code>h-adr</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-adr</nowiki>

properties:
* '''<code>p-post-office-box</code>'''
* '''<code>p-extended-address</code>'''
* '''<code>p-street-address</code>'''
* '''<code>p-locality</code>'''
* '''<code>p-region</code>'''
* '''<code>p-postal-code</code>'''
* '''<code>p-country-name</code>'''
* '''<code>p-label</code>''' - new in [[vCard4]] ([[RFC6350]])
* '''<code>p-geo</code>''' (or '''<code>u-geo</code>''' with a RFC 5870 geo: URL) - new in [[vCard4]] ([[RFC6350]])
* '''<code>p-latitude</code>''' - new in [[vCard4]] ([[RFC6350]] from RFC 5870)
* '''<code>p-longitude</code>''' - new in [[vCard4]] ([[RFC6350]] from RFC 5870)
* '''<code>p-altitude</code>''' - new in [[vCard4]] ([[RFC6350]] from RFC 5870)

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-adr" is found, don't look for an "adr" on the same element.

compat root class name: <code id="adr">adr</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>post-office-box</code>
* <code>extended-address</code>
* <code>street-address</code>
* <code>locality</code>
* <code>region</code>
* <code>postal-code</code>
* <code>country-name</code>

=== h-card ===
{{main|h-card}}

The '''h-card''' microformat is for marking up people and organizations. This is an update to [[hCard]].

root class name: '''<code>h-card</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-card</nowiki>

properties:
* '''<code>p-name</code>'''
* '''<code>p-honorific-prefix</code>'''
* '''<code>p-given-name</code>'''
* '''<code>p-additional-name</code>'''
* '''<code>p-family-name</code>'''
* '''<code>p-sort-string</code>'''
* '''<code>p-honorific-suffix</code>'''
* '''<code>p-nickname</code>'''
* '''<code>u-email</code>'''
* '''<code>u-logo</code>'''
* '''<code>u-photo</code>'''
* '''<code>u-url</code>'''
* '''<code>u-uid</code>'''
* '''<code>p-category</code>'''
* '''<code>p-adr</code>'''
* '''<code>p-post-office-box</code>'''
* '''<code>p-extended-address</code>'''
* '''<code>p-street-address</code>'''
* '''<code>p-locality</code>'''
* '''<code>p-region</code>'''
* '''<code>p-postal-code</code>'''
* '''<code>p-country-name</code>'''
* '''<code>p-label</code>'''
* '''<code>p-geo</code>''' or '''<code>u-geo</code>''' with a RFC 5870 geo: URL, new in [[vCard4]] ([[RFC6350]])
* '''<code>p-latitude</code>'''
* '''<code>p-longitude</code>'''
* '''<code>p-altitude</code>''' - new in [[vCard4]] ([[RFC6350]] from RFC 5870)
* '''<code>p-tel</code>'''
* '''<code>p-note</code>'''
* '''<code>dt-bday</code>'''
* '''<code>u-key</code>'''
* '''<code>p-org</code>'''
* '''<code>p-job-title</code>''' - previously 'title' in hCard, disambiguated.
* '''<code>p-role</code>
* '''<code>u-impp</code>''' per RFC 4770, new in [[vCard4]] ([[RFC6350]])
* '''<code>p-sex</code>''' new in [[vCard4]] ([[RFC6350]])
* '''<code>p-gender-identity</code>''' new in [[vCard4]] ([[RFC6350]])
* '''<code>dt-anniversary</code>''' new in [[vCard4]] ([[RFC6350]])
* ...

Reserved properties: (properties not used much (if at all) in practice)
* '''<code>p-organization-name</code>'''
* '''<code>p-organization-unit</code>'''
* '''<code>p-tz</code>'''
* '''<code>dt-rev</code>'''
* ...

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-card" is found, don't look for a "vcard" on the same element.

compat root class name: <code id="vcard">vcard</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>honorific-prefix</code>
* <code>given-name</code>
* <code>additional-name</code>
* <code>family-name</code>
* <code>honorific-suffix</code>
* <code>nickname</code>
* <code>email</code> - parse as '''u-'''
* <code>logo</code> - parse as '''u-'''
* <code>photo</code> - parse as '''u-'''
* <code>url</code> - parse as '''u-'''
* <code>uid</code> - parse as '''u-'''
* <code>category</code>
* <code>adr</code> - parse as '''<code>p-adr h-adr</code>''' including compat root class <code>adr</code>
* <code>extended-address</code>
* <code>street-address</code>
* <code>locality</code>
* <code>region</code>
* <code>postal-code</code>
* <code>country-name</code>
* <code>label</code>
* <code>geo</code> - parse as '''<code>p-geo h-geo</code>''' including compat root class <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* <code>tel</code>
* <code>note</code>
* <code>bday</code> - parse as '''dt-'''
* <code>key</code> - parse as '''u-'''
* <code>org</code>
* <code>organization-name</code>
* <code>organization-unit</code>
* <code>title</code> - parse as '''p-job-title'''
* <code>role</code>
* ...

Reserved: (backward compat properties that parsers {{may}} implement, if they do, they {{must}} implement in this way:
* <code>tz</code>
* <code>rev</code> - parse as '''dt-'''
* ...

Note: use of 'value' within 'tel' should be automatically handled by the support of the [[value-class-pattern]]. And for now, the 'type' subproperty of 'tel' is dropped/ignored. If there is demonstrable documented need for additional tel types (e.g. fax), we can introduce new flat properties as needed (e.g. p-tel-fax).

=== h-entry ===
{{main|h-entry}}

The '''h-entry''' microformat is for marking up syndicatable content such as blog posts, notes, articles, comments, photos and similar. This is an update to [[hAtom]].

root class name: '''<code>h-entry</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-entry</nowiki>

properties:
* '''<code>p-name</code>''' (was p-entry-title, see issues)
* '''<code>p-summary</code>''' (was p-entry-summary, see issues)
* '''<code>e-content</code>''' (was e-entry-content, see issues)
* '''<code>dt-published</code>'''
* '''<code>dt-updated</code>'''
* '''<code>p-author</code>'''
* '''<code>p-category</code>'''
* '''<code>u-url</code>'''
* '''<code>u-uid</code>'''
* '''<code>p-geo</code>'''
* '''<code>p-latitude</code>'''
* '''<code>p-longitude</code>'''

This is an update to [[hAtom]].

Brainstorming:

The following properties are proposed additions to h-entry above and beyond what hAtom (or Atom) provides, based on various existing link preview markup conventions:
* '''<code>u-photo</code>'''
* '''<code>u-audio</code>''' - consider special u- parsing rules for <code><audio></code>
* '''<code>u-video</code>''' - consider special u- parsing rules for <code><video></code>
* '''<code>u-in-reply-to</code>''' - for links to other posts that this post is a reply to (comment regarding, etc.)

Backward compatibility:

(*)hAtom-specific implementations that perform custom display or translation (e.g. to Atom XML) {{should}} prefer <code>p-name</code> over <code>p-entry-title</code>, and use <code>p-entry-title</code> value(s) as a fallback if there is no <code>p-name</code>.

For hAtom backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-entry" is found, don't look for a "hentry" on the same element.

compat root class name: <code id="hentry">hentry</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>entry-title</code> - parse as '''<code>p-name</code>'''
* <code>entry-summary</code>
* <code>entry-content</code> - parse as '''e-'''
* <code>published</code> - parse as '''dt-'''
* <code>updated</code> - parse as '''dt-'''
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>category</code>
* <code>geo</code> - parse as '''<code>p-geo h-geo</code>''' including compat root <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* ...

<span id="h-entry-faq">FAQ:</span>
<div class="discussion">
* '''What is the <code>p-name</code> of a [http://indiewebcamp.com/note note]?'''
** A few options, from simplest to most detailed.
*** '''same as the p-content/e-content''' property.
*** '''same as the <code>title</code> element''' on the note permalink post page. When publishing a note on its own permalink post page, the contents of the note are likely abbreviated for the title of the page. The same abbreviation can be used for the p-name.
*** '''first sentence of the p-content/e-content''' property. It may be better for [http://indiewebcamp.com/syndication syndication] and [[link-preview]] purposes to provide just the first sentence of the note as the <code>p-name</code>. Similarly if only a portion of the content is syndicated to other sites, that portion can be marked up as the <code>p-summary</code>.
* ...
</div>

Resolved Issues:
* 2012-245 Resolved. See [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-120 2012-243 IRC discussion/consensus] for:
** Use '''<code>p-summary</code> instead of <code>p-entry-summary</code>'''. The historical semantic of "entry-summary" is not different from "summary" in any significant (or discernible way). Collapsing the two will simplify the overall microformats2 vocabularies further. In microformats2, entry-summary is no more.
** Use '''<code>e-content</code> instead of <code>e-entry-content</code>'''. Same point and advantage. In microformats2, entry-content is no more.
** '''drop <code>p-entry-title</code>'''. Unnecessary and subsumed by "p-name". Would consider move to backward compat only if cases are presented - known publishing uses are expected to be updated shortly.

=== h-event ===
{{main|h-event}}

The '''h-event''' microformat is for marking up events. This is an update to [[hCalendar]].

root class name: '''<code>h-event</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-event</nowiki>

properties:
* '''<code>p-name</code>'''
* '''<code>p-summary</code>'''(*)
* '''<code>dt-start</code>'''
* '''<code>dt-end</code>'''
* '''<code>dt-duration</code>'''
* '''<code>p-description</code>'''
* '''<code>u-url</code>'''
* '''<code>p-category</code>'''
* '''<code>p-location</code>'''
* '''<code>p-geo</code>'''
* '''<code>p-latitude</code>'''
* '''<code>p-longitude</code>'''
* ...

This is an update to [[hCalendar]].

(*)hCalendar-specific implementations that perform custom display or translation (e.g. to iCalendar .ics) {{should}} prefer <code>p-name</code> over <code>p-summary</code>, and use <code>p-summary</code> value(s) as a fallback if there is no <code>p-name</code>.

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-event" is found, don't look for a "vevent" on the same element.

compat root class name: <code id="vevent">vevent</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>summary</code> - parse as '''<code>p-name</code>'''
* <code>dtstart</code> - parse as '''<code>dt-start</code>'''
* <code>dtend</code> - parse as '''<code>dt-end</code>'''
* <code>duration</code> - parse as '''<code>dt-duration</code>'''
* <code>description</code>
* <code>url</code> - parse as '''u-'''
* <code>category</code>
* <code>location</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>, and compat root <code>adr</code> in the absence of <code>h-adr</code>
* <code>geo</code> - parse as '''<code>p-geo h-geo</code>''' including compat root <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* ...

=== h-geo ===
{{main|h-geo}}

The '''h-geo''' microformat is for marking up WGS84 geophysical coordinates. This is an update to [[geo]].

root class name: '''<code>h-geo</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-geo</nowiki>

properties:
* '''<code>p-latitude</code>'''
* '''<code>p-longitude</code>'''
* '''<code>p-altitude</code>''' - new in [[vCard4]] ([[RFC6350]] from RFC 5870)

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-geo" is found, don't look for an "geo" on the same element.

compat root class name: <code id="geo">geo</code>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>latitude</code>
* <code>longitude</code>

=== h-item ===
{{main|h-item}}

The '''h-item''' microformat is for marking up the item of an [[h-review]] or [[h-product]]. This is an update to part of [[hReview]].

root class name: '''<code>h-item</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-item</nowiki>

properties:
* '''<code>p-name</code>'''
* '''<code>u-photo</code>'''
* '''<code>u-url</code>'''

Note: in practice, due to the microformats2 implied property rules, it is expected that most uses of "h-item" won't require any explicit properties at all (since microformats2 parsers will infer name, photo, and url properties from the structure of the element with "h-item" and its contained content/elements if any).

=== h-product ===
{{main|h-product}}

The '''h-product''' microformat is for marking up products. This is an update to [[hProduct]].

root class name: '''<code>h-product</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-product</nowiki>

properties:
* '''<code>p-name</code>''' - name of the product
* '''<code>u-photo</code>''' - photo of the product
* '''<code>p-brand</code>''' - manufacturer, can also be a nested <code>h-card</code>
* '''<code>p-category</code>''' - freeform categories or tags applied to the item by the reviewer
* '''<code>e-description</code>'''
* '''<code>u-url</code>''' - URL of the product
* '''<code>u-identifier</code>''' - includes type (e.g. mpn, upc, isbn, issn, sn, vin, sku etc.) and value.
* '''<code>p-review</code>''' - a review of the product, can also be a nested <code>h-review</code>
* '''<code>p-price</code>''' - retail price of the product

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-product" is found, don't look for an "hproduct" on the same element.

compat root class name: <code id="hproduct">hproduct</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>photo</code> - parse as '''u-'''
* <code>brand</code>
* <code>category</code>
* <code>description</code>
* <code>identifier</code> - parse as '''u-'''
* <code>url</code> - parse as '''u-'''
* <code>review</code> - including compat root class <code>hreview</code> in the absence of <code>h-review</code>
* <code>price</code>

Note: [[hProduct]] has at least one experimental property which has real world adoption due to [[Google]] and [[Bing]] search support of hProduct. Currently this is: '''price'''

=== h-recipe ===
{{main|h-recipe}}

The '''h-recipe''' microformat is for marking up food recipes. This is an update to [[hRecipe]].

root class name: '''<code>h-recipe</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-recipe</nowiki>

properties:
* '''<code>p-name</code>''' - the name of the recipe
* '''<code>p-ingredient</code>''' - describes one or more ingredients used in the recipe.
* '''<code>p-yield</code>''' - Specifies the quantity produced by the recipe, like how many persons it satisfyies
* '''<code>e-instructions</code>''' - the method of the recipe.
* '''<code>dt-duration</code>''' - the time it takes to prepare the meal described by the recipe.
* '''<code>u-photo</code>''' - an accompanying image

Experimental properties with wide adoption
* '''<code>p-summary</code>''' - provides a short summary or introduction
* '''<code>p-author</code>''' - the person who wrote the recipe with <code>h-card</code>
* '''<code>dt-published</code>''' - the date the recipe was published
* '''<code>p-nutrition</code>''' - nutritional information like calories, fat, dietary fiber etc.
* ...

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-recipe" is found, don't look for an "hrecipe" on the same element.

compat root class name: <code id="hrecipe">hrecipe</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>ingredient</code>
* <code>yield</code>
* <code>instructions</code> - parse as '''e-'''
* <code>duration</code> - parse as '''dt-'''
* <code>photo</code> - parse as '''u-'''
* <code>summary</code>
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>nutrition</code>

Note: [[hRecipe]] has a number of experimental properties which have real world adoption due to [[Google]] recipe search support of hRecipe. These are: summary, author, published and nutrition

=== h-resume ===
{{main|h-resume}}

The '''h-resume''' microformat is for marking up resumes. This is an update to [[hResume]].

root class name: '''<code>h-resume</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-resume</nowiki>

properties:
* '''<code>p-summary</code>''' - overview of qualifications and objectives
* '''<code>p-contact</code>''' - current contact info in an <code>h-card</code>
* '''<code>p-education</code>''' - an education <code>h-calendar</code> event, years, nested <code>h-card</code> of the school, location.
* '''<code>p-experience</code>''' - a job or other professional experience <code>h-calendar</code> event, years, nested <code>h-card</code> of the organization, location, job-title.
* '''<code>p-skill</code>''' - a skill or ability, optionally including level and/or duration of experience
* '''<code>p-affiliation</code>''' - an affiliation with an <code>h-card</code> organization

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-resume" is found, don't look for an "hresume" on the same element.

compat root class name: <code id="hresume">hresume</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>summary</code>
* <code>contact</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>education</code> - including compat root <code>vevent</code> in the absence of <code>h-event</code>
* <code>experience</code> - including compat root <code>vevent</code> in the absence of <code>h-event</code>
* <code>skill</code>
* <code>affiliation</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>

Note: skill has a [[hresume-skill-brainstorm|proposed expansion into competency]] with explicit summary, rating and/or duration components. Based on existing real world adoption, we should consider an h-competency vocabulary with p-summary, p-rating, and dt-duration properties.

=== h-review ===
{{main|h-review}}

The '''h-review''' microformat is for marking up reviews. This is an update to [[hReview]]. See also [[h-item]].

root class name: '''<code>h-review</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-review</nowiki>

properties:
* '''<code>p-name</code>''' - name of the review
* '''<code>p-item</code>''' - thing been reviewed i.e. business or person (h-card), event (h-event), place (h-adr or h-geo), product (h-product), website, url, or other item ([[h-item]]).
* '''<code>p-reviewer</code>''' - person who authored the review
* '''<code>dt-reviewed</code>''' - date time of when the review was written
* '''<code>p-rating</code>''' - value from 1-5 indicating a rating for the item (5 best).
* '''<code>p-best</code>''' - define best rating value. can be numerically lower than worst.
* '''<code>p-worst</code>''' - define worst rating value. can be numerically higher than best.
* '''<code>e-description</code>''' - the full text written evaluation and opinion of the reviewer
* '''<code>p-category</code>''' - freeform categories or tags applied to the item by the reviewer
* '''<code>u-url</code>''' - URL of the review

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-review" is found, don't look for an "hreview" on the same element.

compat root class name: <code id="hreview">hreview</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>summary</code> parse as '''<code>p-name</code>'''
* <code>fn</code> - parse as '''p-name''' of the item being reviewed (p-item h-item p-name)
* <code>photo</code> - parse as '''u-photo''' of the item being reviewed (p-item h-item u-photo)
* <code>url</code> - parse as '''u-url''' of the item being reviewed (p-item h-item u-url)
* <code>reviewer</code> - including compat root vcard in the absence of h-card
* <code>dtreviewed</code> - parse as '''dt-'''
* <code>rating</code>
* <code>best</code>
* <code>worst</code>
* <code>description</code> - parse as '''e-'''
* <code>rel="tag"</code> - parse as '''p-category'''
* <code>rel="self bookmark"</code> - parse as '''u-url'''. note that <code>rel</code> attribute value is treated as a space separated set, thus any presence of "self" and "bookmark" within such a set in a rel value is accepted.

Note: The [[hReview]] format has three properties which make use of <code>rel</code> attribute, these are <code>tag</code>, permalink (via the <code>self</code> and <code>bookmark</code> values) and <code>license</code>. Microformats 2 parsers {{should}} map these URLs into the page scoped rel collection.

=== h-review-aggregate ===
{{main|h-review-aggregate}}

The '''h-review-aggregate''' microformat is for marking up aggregate reviews of a single item. This is an update to [[hreview-aggregate]]. See also [[h-item]].

root class name: '''<code>h-review-aggregate</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-review-aggregate</nowiki>

properties:
* '''<code>p-name</code>''' - name of the review
* '''<code>p-item</code>''' - thing been reviewed i.e. business or person (h-card), event (h-event), place (h-adr or h-geo), product (h-product), website, url, or other item (h-item).
* '''<code>p-rating</code>''' - value from 1-5 indicating average rating for the item (5 best).
* '''<code>p-best</code>''' - define best rating value. can be numerically lower than worst.
* '''<code>p-worst</code>''' - define worst rating value. can be numerically higher than best.
* '''<code>p-count</code>''' - number of reviews aggregated.
* '''<code>p-votes</code>''' - number of reviewers who have rated the product, thus contributing to the average rating.
* '''<code>p-category</code>''' - freeform categories or tags applied to the item by the reviewer
* '''<code>u-url</code>''' - URL of the review

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-review-aggregate" is found, don't look for an "hreview-aggregate" on the same element.

compat root class name: <code id="hreview-aggregate">hreview-aggregate</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>summary</code> parse as '''<code>p-name</code>'''
* <code>fn</code> - parse as '''p-name''' of the item being reviewed (p-item h-item p-name)
* <code>photo</code> - parse as '''u-photo''' of the item being reviewed (p-item h-item u-photo)
* <code>url</code> - parse as '''u-url''' of the item being reviewed (p-item h-item u-url)
* <code>rating</code>
* <code>best</code>
* <code>worst</code>
* <code>count</code>
* <code>votes</code>
* <code>rel="tag"</code> - parse as '''p-category'''
* <code>rel="self bookmark"</code> - parse as '''u-url'''. note that <code>rel</code> attribute value is treated as a space separated set, thus any presence of "self" and "bookmark" within such a set in a rel value is accepted.

=== v2 vocab notes ===
Notes:
* All v2 vocabularies are defined as flat lists of properties of an object/item, and thus can be used in microformats-2 syntax as shown, or in microdata items, or RDFa. The microformats-2 property parsing prefixes "p-", "u-", "dt-", "e-" are omitted when using defined properties in microdata itemprop and RDFa property as those syntaxes have their own element-specific parsing rules.
* Profile URLs are provided for use with the HTML4 <code>profile</code> attribute, microdata <code>itemtype</code> attribute, and RDFa <code>vocab</code> & <code>typeof</code> attributes (though the latter requires slicing off the trailing segment of the profile for the typeof attribute, and leaving the rest in vocab).
* microformats 2 properties may also be explicitly bound as URIs using [[rel-profile]], the [[html5-profile]] attribute proposal, or an HTML5 'vocab' attribute instead. If URI bound terms are important to you, please express interest on [[rel-profile]], [[html5-profile]], or contribute to an [[html5-vocab]] draft.

=== v2 vocab to-do ===
To do:
* write a simple tutorial for creating/getting started with microformats-2 markup for new content
* examples in each h-* spec listed above of how to embed other microformats in them
* actual profile documents at <nowiki>http://microformats.org/profile/h-*</nowiki> URLs mentioned above.
* Provide any necessary microdata-specific language as needed (e.g. to be comparably understandable to the [http://www.whatwg.org/specs/web-apps/current-work/#vcard sample vCard4/hCard1 microdata vocabulary]. Also provide any necessary RDFa-specific language as needed. Both preferably in a generic vocabulary-independent way.
* write a porting guide mapping v1 property -> v2 property
** use-case: simple search/replace in templates (e.g. in case web author doesn't remember existing microformats vocabs and where they used them).
** advise using *both* in existing templates (e.g. in case some CSS depends on the existing microformats)
* analyzie/document how well the microformats2 model and vocabularies satisfy the [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019681.html use-cases used to design/create microdata].

== combining microformats ==
Since microformats 2 uses simple flat sets of properties for each microformat, multiple microformats are combined to indicate additional structure.

=== h-event location h-card ===
Events commonly have venue information with additional structure, like address information. For example:

<source lang=html4strict>
<div class="h-event">
<a class="p-name u-url" href="http://indiewebcamp.com/2012">
IndieWebCamp 2012
</a>
from <time class="dt-start">2012-06-30</time>
to <time class="dt-end">2012-07-01</time> at
<span class="p-location h-card">
<a class="p-name p-org u-url" href="http://geoloqi.com/">
Geoloqi
</a>,
<span class="p-street-address">920 SW 3rd Ave. Suite 400</span>,
<span class="p-locality">Portland</span>,
<abbr class="p-region" title="Oregon">OR</abbr>
</span>
</div>
</source>

The nested h-card used to structure the p-location of the h-event is represented as a structured value for "location" in the JSON, which has an additional key, "value" that represents the plain text version parsed from the p-location.

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-event"],
"properties": {
"name": ["IndieWebCamp 2012"],
"url": ["http://indiewebcamp.com/2012"],
"start": ["2012-06-30"],
"end": ["2012-07-01"],
"location": [{
"value": "Geoloqi",
"type": ["h-card"],
"properties": {
"name": ["Geoloqi"],
"org": ["Geoloqi"],
"url": ["http://geoloqi.com/"],
"street-address": ["920 SW 3rd Ave. Suite 400"],
"locality": ["Portland"],
"region": ["Oregon"]
}
}]
}
}]
}
</source>

Questions:
<div class="discussion">
* Should the nested hCard be present also as a top-level item in the JSON? - [[User:Tantek|Tantek]] 02:02, 19 June 2012 (UTC)
** My current (2012-243) leaning is no. - [[User:Tantek|Tantek]] 18:53, 30 August 2012 (UTC)
** If so, how do we avoid expansion of the JSON geometrically proportional to the depth of microformat nesting? (Or do we not worry about it?)
* Should there be a canonical hierarchical JSON and a canonical flattened JSON? - [[User:Tantek|Tantek]] 02:02, 19 June 2012 (UTC)
** My current (2012-243) leaning is no, we stick with one canonical JSON for uf2 which is hierarchical. - [[User:Tantek|Tantek]] 18:53, 30 August 2012 (UTC)
** If so, should the flattened JSON have references from properties to nested microformats that have been pushed to the top level per flattening? - [[User:Tantek|Tantek]] 02:02, 19 June 2012 (UTC)
*** If so, what convention does/do JSON follow for such synthetic local reference identifiers? - [[User:Tantek|Tantek]] 02:02, 19 June 2012 (UTC)
</div>

Notes:
* The 'location' value reflects the visible text of its element, including spaces and punctuation, as well as the state abbreviation 'OR'. The 'h-card' property values are only what is marked up, and thus include structure values without extra punctuation, and the state takes the expanded form from the <code>title</code> attribute of its <code><abbr></code> element.

=== h-card org h-card ===
People often publish information general to their company rather than specific to them, in which case, they may wish to encapsulate that in separately nested microformat. E.g. here is a simple h-card example with org property:

[http://blog.lizardwrangler.com Mitchell Baker] (Mozilla Foundation)

with source:
<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<span class="p-org">Mozilla Foundation</span>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"],
"org": ["Mozilla Foundation"]
}
}]
}
</source>

Sometimes such organization affiliations are hyperlinked to the website of the organization:

[http://blog.lizardwrangler.com Mitchell Baker] ([http://mozilla.org/ Mozilla Foundation])

You can mark that up with a nested h-card:
<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="p-org h-card"
href="http://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"],
"org": [{
"value": "Mozilla Foundation",
"type": ["h-card"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["http://mozilla.org/"]
}
}]
}
}]
}
</source>

Note: the nested h-card has implied 'name' and 'url' properties, just like any other root-class-name-only h-card on an <code><a href></code> would.

'''FOR PARSERS ONLY:'''

The nested 'h-card' could be marked up as an 'h-org' as well, which adds it to the nested microformat's type array, all as part of the property specified by the 'p-org'.

<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="p-org h-card h-org"
href="http://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"],
"org": [{
"value": "Mozilla Foundation",
"type": ["h-card", "h-org"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["http://mozilla.org/"]
}
}]
}
}]
}
</source>

'''FOR PARSERS ONLY:'''

Without a property class name like 'p-org' holding all the nested objects together, we need to introduce another array for nested children (similar to the existing DOM element notion of children) of a microformat that are not attached to a specific property:

<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="h-org h-card"
href="http://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"]
},
"children": [{
"type": ["h-card","h-org"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["http://mozilla.org/"]
}
}]
}]
}
</source>

Since there's no property class name on the element with classes 'h-card' and 'h-org', the microformat representing that element is collected into the children array.

Such a nested microformat implies some relationship (containment, being related), but is not as useful as if the nested microformat was a specific property of its parent.

For this reason it's recommended that authors should not publish nested microformats without a property class name, and instead, when nesting microformats, authors should always specify a property class name (like 'p-org') on the same element as the root class name(s) of the nested microformat(s) (like 'h-card' and/or 'h-org').

'''FOR PARSERS ONLY:'''

Or the nested object could be only marked up with 'h-card'. Source:

<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="h-card"
href="http://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"]
},
"children": [{
"type": ["h-card"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["http://mozilla.org/"]
}
}]
}]
}
</source>

'''TO DO: Add h-event h-card example and JSON, per real world publishing examples like [http://www.swingtime.co.uk/List/ClSouth.html Swing Time: Classes in Southern England].'''

== authoring ==
=== minimal markup ===
The best way to use microformats-2 is with as little additional markup as possible. This keeps your code cleaner, improves its maintainability, and thus the quality and longevity of your microformats.

One big advantage of microformats-2 over previous microformats (and others) is the ability to add one class name to an existing element to create a structured item.

See the [[microformats-2#simple_microformats_2_examples|simple examples at the top]] for a start, e.g.

Simple hCards work just by adding <code>class="h-card"</code> :
<source lang=html4strict>
<span class="h-card">Frances Berriman</span>

<a class="h-card" href="http://benward.me">Ben Ward</a>

<img class="h-card" alt="Sally Ride"
src="http://upload.wikimedia.org/wikipedia/commons/a/a4/Ride-s.jpg"/>

<a class="h-card" href="http://tantek.com">
<img alt="Tantek Çelik" src="http://ttk.me/logo.jpg"/>
</a>
</source>

* Tip: Inside an open tag, put the <code>class</code> attribute <em>first</em>, then any human text content attributes (e.g. <code>alt</code>), then URL attributes (e.g. <code>href</code> <code>src</code>), and lastly other attributes (e.g. <code>style</code>). Putting the class attribute first ties it closely to the element name/tag itself, makes it more obvious, and thus more likely to be kept up to date.

=== backward compatible ===
If you depend on current microformats [[implementations]], while they're being updated to support [[microformats-2]], you can include both existing microformats and microformats-2 markup.

In short: use both sets of class names simultaneously.

When doing so, use them on the same element, with the microformats-2 class name first, followed immediately by the existing microformats class name.

Here are the microformats-2 hCards from above with current [[hCard]] markup as well, which may require adding a wrapping element (e.g. a <code><span></code>) to separate the root class name element from explicit property class name elements:

<source lang=html4strict>
<span class="h-card vcard">
<span class="p-name fn">Frances Berriman</span>
</span>

<span class="h-card vcard">
<a class="p-name fn u-url url" href="http://benward.me">Ben Ward</a>
</span>

<span class="h-card vcard">
<img class="p-name fn u-photo photo" alt="Sally Ride"
src="http://upload.wikimedia.org/wikipedia/commons/a/a4/Ride-s.jpg"/>
</span>

<span class="h-card vcard">
<a class="u-url url" href="http://tantek.com">
<img class="p-name fn u-photo photo" alt="Tantek Çelik"
src="http://ttk.me/logo.jpg"/>
</a>
</span>
</source>

Tips:
* use the microformats-2 class name first, e.g.
** <code>class="h-card vcard"</code>
** <code>class="u-url url"</code>
* and pair them when using an element for multiple properties, e.g.:
** <code>class="p-name fn u-url url"</code>
** <code>class="p-name fn u-photo photo"</code>
* put microformats classes after classes for CSS (since page authors will likely interact more with their own classes for design than with microformats classes), e.g. as used on individual microformats [[events]] pages:
** <code>class="event-page h-event vevent"</code>

The prefixes (h-, p-, etc.) of microformats2 class names provide easier recognition, and when followed by the similarly named existing class name, they're more easily recognized as related and thus kept together when the markup is maintained over time.

Related FAQ: [[microformats2-faq#when_using_both_h-card_and_vcard_which_should_be_first_and_why|When using both h-card and vcard which should be first and why?]]

== validators ==
microformats2 validators:

{{new}} Test your microformatted web page with:
* https://pin13.net/mf2/

Barnaby Walters has a hosted version of the open source php-mf2 [[parser]] where you can enter your markup into a textarea and see how it's parsed:
* http://waterpigs.co.uk/php-mf2/

See the [[validators]] page for a longer list of validators.

== Examples in the wild ==
Please add new examples in the wild of microformats-2 to the top of this list. When it gets too big we can move it to a separate page like [[microformats-2-examples-in-wild]].

* ...
* David John Mead marks up his profile, blog posts and comments with h-card, h-entry and h-cite on [http://davidjohnmead.com davidjohnmead.com]
* [[User:Brian|Brian Suda]] marks up his blog posts up with h-entry and h-card on [http://optional.is/required/ optional.is]
* Ashton McAllan marks up her blog posts, reposts, comments and likes with h-entry, h-card and h-cite on [https://acegiak.net/ acegiak.net]
* Emma Kuo marks up her blog posts and notes with h-entry and h-card on [http://notenoughneon.com/ notenoughneon.com]
* Scott Jenson marks up his blog posts with h-entry and h-card on [http://jenson.org/ jenson.org]
* Emily McAllen marks up her blog posts with h-entry and h-card on [http://blackwoolholiday.com/ blackwoolholiday.com]
* Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on [https://snarfed.org/ snarfed.org]
* Barry Frost marks up his notes with h-entry, h-card and h-cite on [http://barryfrost.com/ barryfrost.com]
* Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on [http://caseorganic.com/ caseorganic.com]
* Johannes Ernst marks up his blog posts with h-entry on [http://upon2020.com/blog/ upon2020.com]
* Michiel de Jong marks up his profile and notes with h-entry and h-card on [https://michielbdejong.com/ michielbdejong.com]
* Mike Taylor marks up his profile and blog posts with h-card and h-entry on [https://bear.im/bearlog/ bear.im]
* Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on [http://erinjo.is/ erinjo.is]
* Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on [https://jeena.net/ jeena.net]
* Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on [http://andysylvester.com/2014/03/01/howto-setting-up-the-selfoss-feed-reader-with-microformats-support/ andysylvester.com] (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --[[User:Barnabywalters|bw]] 14:44, 13 March 2014 (UTC))
* Hakan Demir marks up his Coupon and Voucher blog posts with h-entry and h-card on [http://www.gutscheinflagge.de/ gutscheinflagge.de]
* Chloe Weil marks up her blog posts with h-entry on [http://chloeweil.com/blog chloeweil.com]
* Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on [http://christopheducamp.com/ christopheducamp.com]
* Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on [http://glennjones.net/ glennjones.net]
* Marcus Povey marks up his blog posts and profile with h-entry and h-card on [http://www.marcus-povey.co.uk/ marcus-povey.co.uk]
* Eugen Busoiu marks up his web profile with h-card on [http://eugenbusoiu.com/#utm_source=microformats2&utm_medium=h-card&utm_campaign=Microformats eugenbusoiu.com]]
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* Kyle Mahan marks up his profile and notes with h-card and h-entry on [http://kylewm.com/ kylewm.com]
* Okinawan-lyrics marks up his blog posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* Emil Björklund marks up his blog posts with h-entry and h-card ([http://thatemil.com/blog/2013/09/16/webmentioning-adactio/ example])
* App.net rolled out support for h-card and h-entry on all profile pages and permalink pages as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* Brett Comnes marks up his posts with h-entry and h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like ([http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his posts up with h-card and h-entry, as well as draft u-in-reply-to and experimental u-like properties ([http://sandeep.io/101 example])
* Laurent Eschenauer marks up his posts with h-entry ([http://eschnou.com/entry/first-autonomous-flight-of-my-nodecopter-62-24992.html example])
* Tom Morris marks up his posts using h-entry ([http://tommorris.org/posts/8417 example])
* Sinolandquality marks up some of their content using h-feed and h-entry on [http://www.sinolandquality.com/Blog/?page_id=3516&utm_content=buffere4d40&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer sinolandquality.com]
* [http://www.w3.org/conf/ W3Conf 2013] uses h-event for the main event, and h-card for all the speakers and notable attendees. The h-cards make particularly good use of implied name, url, and photo properties.
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry and h-as-*
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Tom Morris uses h-card and [[XFN]] to markup [http://tommorris.org/pages/blogroll his blogroll].
* Aaron Parecki uses h-card to markup both authorship and references to people in his notes permalinks, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-card, h-event, and h-entry on his home page, as well as h-entry on all post permalinks, e.g. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], with [[rel-prev]]/[[rel-next]] (if applicable) to indicate prev/next posts, and with [[rel-author]] to his home page with canonical hCard to indicate authorship.
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-card on his home page, h-card, h-entry and XFN markup on his [http://waterpigs.co.uk/notes notes page].
** 2013-01-25 Barnaby Walters: <cite>[http://waterpigs.co.uk/articles/experimental-markup Experimental Markup]</cite> - describes how he's using microformats2 vocabularies: <code>h-adr</code>, <code>h-card</code>, <code>h-entry</code>, <code>h-event</code>, <code>h-geo</code>, <code>h-review</code>, and experimental vocabularies: <code>h-feed</code> (embedded for update histories), [[activity-streams]] objects <code>h-as-article</code>, <code>h-as-collection</code>, <code>h-as-note</code>, <code>h-as-update</code>, as well as experimental properties: <code>u-alternate</code> and <code>u-as-downstream-duplicate</code> (links to POSSE copies), and <code>u-in-reply-to</code> (links to content that the posts are in reply to).
* [http://tantek.com/presentations/2012/06/microformats microformats.org at 7 years] presentation with h-event and h-card markup for people and organizations.
* [http://tantek.com/presentations/2012/06/pdf2012-indieweb.html Rise of the Indie Web hCards] (from Personal Democracy Forum 2012 #pdf12 #pdf2012) has [[microformats-2]] h-calendar and h-card markup
* WebMaker by Mozilla has [[microformats-2]] h-calendar and h-card on event search (e.g. [https://webmaker.org/en-US/events/near/?lat=45.5234515&lng=-122.6762071 search near Portland Oregon]) and event pages (e.g. [https://webmaker.org/en-US/events/192f56eb9/ IndieWebCamp 2012]).[https://twitter.com/microformats/status/212207925643587585]
* WebFWD by Mozilla has [[microformats-2]] h-card markup on [https://webfwd.org/about/experts/ experts] and [https://webfwd.org/about/team/ team] pages
* [http://indiewebcamp.com IndieWebCamp] has [[microformats-2]] h-event markup with nested h-cards for the organizers and the location.
* [https://wiki.mozilla.org/Events Mozilla Events] page has [[microformats-2]] h-event markup with attendees marked up with h-card.
* The [http://pdx.esri.com/blog/2013/10/17/introducing-mapattack/ Esri PDX Blog] has h-entry markup on all blog posts (as of 2013-10-19), and h-product markup on [http://pdx.esri.com/projects/terraformer/ project pages]

=== offline ===
* spreadly marks up share permalink pages with h-entry, as well as minimal h-cards and experimental p-like properties

== Implementations ==
{{new}} Test your microformatted web page with:
=== Live Textarea Input ===
Use any of these to enter HTML+microformats2 markup and see the parsed result!
* http://glennjones.net/tools/microformats/
* https://pin13.net/mf2/ (where it says "Microformats Parser")
* https://kylewm.com/services/mf2

=== Blogging tools ===
* '''Storytlr''' parses the 'target' from [http://indiewebcamp.com/pingback pingbacks] for [https://github.com/storytlr/storytlr/blob/master/protected/application/public/controllers/PingbackController.php#L63 h-entry with properties and nested h-card] for information to automatically display in the [http://eschnou.com/entry/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html comments section on a post].

=== Converters ===
* '''[https://github.com/snarfed/granary granary]''' is a library and REST API that converts between silo APIs, [[ActivityStreams]], [[microformats2]], and Atom (all directions). Supported silos include Facebook, Twitter, Instagram, Google+, and Flickr. Users include [http://brid.gy/ Bridgy], [http://reader.kylewm.com/ Woodwind], and [https://facebook-atom.appspot.com/ facebook-atom] and [https://twitter-atom.appspot.com/ twitter-atom], among others.

* '''[http://pipes.yahoo.com/pipes/pipe.info?_id=afc5568b4e8643bfb05436b1caaf91bc microformats to RSS]''' - a Yahoo! pipe that converts a URL containing an [[h-feed]] containing h-entries, into an [[RSS]] feed ([http://waterpigs.co.uk/notes/4SeNi5/ 2013-10-21 blog post announcing])

* '''[https://xray.p3k.io XRay]''' ([https://github.com/aaronpk/XRay source code]) - Returns a normalized representation of the microformats data at a URL

=== Parsers ===
Parsers, open source libraries, in alphabetical order by programming language:

==== Parsers in production ====
The following parsers are of very high quality, in active development, and use on live sites on the web in production.

===== Java =====
* [[any23]] Apache Any23 (Anything to Triples)] a library, a web service and a command line tool that extracts structured data in RDF format from a variety of Web documents: http://any23.apache.org

===== Javascript =====
* '''microformat-node''' Node.js microformats2 parser
** github open source: https://github.com/glennjones/microformat-node
** test suite: https://github.com/microformats/tests
** blog post: http://glennjones.net/2013/01/brand-new-microformats-2-parser/
** live: http://glennjones.net/tools/microformats/
** command line: https://github.com/JerrySievert/mf2
* '''microformat-shiv''' - cross browser javascript microformats 2 parser which can also be used in browser extensions.
** http://microformatshiv.com/
** github open source: https://github.com/glennjones/microformat-shiv

===== PHP =====
* '''<span id="php-mf2">php-mf2</span>''' - PHP microformats2 parser
** github open source: https://github.com/indieweb/php-mf2
** Packagist: https://packagist.org/packages/mf2/mf2
** live:
*** textarea entry: http://waterpigs.co.uk/php-mf2/
*** URL and textarea entry: https://pin13.net/mf2/
** [https://github.com/barnabywalters/php-mf-cleaner mf-cleaner]: functions for working with the raw mf2 data structure

===== Python =====
* '''mf2py''' Python microformats2 parser
** main entry: [[mf2py]]
** github open source: https://github.com/tommorris/mf2py
** live:
*** URL entry: [https://mf2py.herokuapp.com/ mf2py.herokuapp.com]
*** textarea entry: https://kartikprabhu.com/connection/mfparser
*** another textarea: http://www.unmung.com/?html=
*** URL and/or textarea: https://kylewm.com/services/mf2

===== Ruby =====
* '''indieweb/microformats-ruby''' Ruby microformats parser
** github open source: https://github.com/indieweb/microformats-ruby
** live text entry: https://microformats-parser-ruby.herokuapp.com

===== Haskell =====
* '''myfreeweb/microformats2-parser''' Haskell microformats2 parser
** github open source: https://github.com/myfreeweb/microformats2-parser
** live textarea entry: https://unrelenting.technology/mf2/

==== Development parsers ====
The following parsers are in-development and have key microformats2 functionality yet are incomplete, not fully tested, or have other limitations. Contributions welcome!

===== Erlang =====
* '''hazybluedot/mf2erl''' Erlang microformats2 parser
** github open source: https://github.com/hazybluedot/mf2erl

===== Elixir =====
* '''ckruse/microformats-elixir''' Elixir microformats2 parser
** github open source: https://github.com/ckruse/microformats2-elixir

===== Go =====
* '''andyleap/microformats''' Golang microformats2 parser
** github open source: https://github.com/andyleap/microformats
** live textarea entry: http://mf2.vendaria.net

===== Java =====
* '''Apache Any23''' a library, a web service and a command line tool that extracts structured data in RDF format from a variety of Web documents. Supports Microformats1 and 2.
** Download recent release: http://any23.apache.org/download.html
** live: http://any23-vm.apache.org/
** source: http://any23.apache.org/build-src.html
* '''mf2j''' An early-stage Java microformats2 parser
** github open source: https://github.com/kylewm/mf2j
** live: https://mf2j.herokuapp.com/?url={http://example.com}

==== Experiments ====
Experiments and other proof of concept microformat2 parsing support.
* ...

=== Outreach ===
* [https://github.com/mozilla/fathom/issues/42 Mozilla Fathom: examples with nested classes, e.g. microformats2]

== Presentations ==
Presentations about microformats2:
* 2013-01-24 <cite>[http://waterpigs.co.uk/presentations/microformats-2/ Microformats 2]</cite> presentation by [[User:Barnabywalters|Barnaby Walters]] at the [[events/2013-01-24-exeter-web-meetup|Exeter Web Meetup]] in Devon, UK.
* 2012-09-21 <cite>[http://tantek.com/presentations/2012/09/microformats2/ microformats2 & bits of HTML5: The Evolution Of Web Data]</cite> presentation by [[User:Tantek|Tantek Çelik]] ([http://twitter.com/t @t]) at [[events/2012-09-21-refreshlx|RefreshLX]] in Lisbon, Portugal.
* 2012-07-21 <cite>[http://tantek.com/presentations/2012/07/html5-uf2/ HTML5 and microformats2: The Evolution Of Web Data]</cite> presentation by [[User:Tantek|Tantek Çelik]] ([http://twitter.com/t @t]) at [[events/2012-07-21-cascadesf|Innovators of the Web conference]] in San Francisco, CA.
* 2012-07-14 <cite>[http://tantek.com/presentations/2012/07/html5-microformats2/ HTML5 and microformats2: The Evolution Of Web Data]</cite> presentation by [[User:Tantek|Tantek Çelik]] ([http://twitter.com/t @t]) at [[events/2012-07-14-open-web-camp-4|Open Web Camp IV]] in San Jose, CA.

== Testimonials ==
* <blockquote class="twitter-tweet">To prove the web standards community can come up with better standards than the SE’s, compare this: http://microformats.org/wiki/microformats-2 with schema . org — Joost de Valk (@yoast) [https://twitter.com/yoast/status/298907685452124160 2013-02-05 13:35]</blockquote>
* <blockquote class="twitter-tweet">... I’m hoping SE’s will pick up microformats2. It’s SO much cleaner. — Joost de Valk (@yoast) [https://twitter.com/yoast/status/298911287117758464 2013-02-05 13:49]</blockquote>
* <blockquote class="twitter-tweet">... But damn Microformats2 are sexy. — Joost de Valk (@yoast) [https://twitter.com/yoast/status/298912179292344320 2013-02-05 13:53]</blockquote>

== About This Brainstorm ==
The rest of this page is a brainstorm currently written in narrative / exploratory format, that is, acknowledging the success that microformats have had, why so, and then a walk through of known issues with microformats in general along with iteration of ways to address said issues, ending up with the current microformats 2 design as a conclusion.

The proposals build on each other resulting in a solution that addresses the vast majority of general issues. The proposed changes merit a major version number increment, hence microformats 2.

This mathematical proof/derivation style is used to explicitly encourage understanding (and double-checking) of the rational steps taken in the development of microformats 2. Reasons are documented, sometimes along with alternatives considered (and reasons for rejection of those alternatives).

When the microformats 2 brainstorm has evolved sufficiently to demonstrate some degree of stability, usability, and implementability, it will be rewritten in a more declarative specification style, and this narrative/derivation will be archived to a background development page for historical purposes.

— [[User:Tantek|Tantek]]

== Background ==

2004: In early February microformats were introduced as a concept at eTech, and in September [[hCard]] and [[hCalendar]] were proposed at FOO Camp.

2010:
* 34% of webdevs use microformats ([http://www.webdirections.org/sotw10/markup/#semantics 2010 State of Web Development survey])
* 1.88 billion hCards (per [[Yahoo]] SearchMonkey)
* 36 million hCalendar events (ibid)

* XFN -> Social Graph API -> Web as Social Network / Address Book

== Addressing Issues ==
=== AUTHORS and PUBLISHING ===
Authors and publishers are perhaps the most important constituency in the microformats community. There are more of them than there are developers, programmers, parsers, etc. and they're the ones that solved the chicken-egg problem by publishing microformats even before tools were available for consuming them.

Therefore we must first address author/publisher general issues with microformats.

==== can we make the simplest case simpler ====
Issue: '''How can we make it easier for authors to publish microformats?'''

Currently the simplest hCard:
<source lang=html4strict>
<span class="vcard">
<span class="fn">
Chris Messina
</span>
</span>
</source>

requires 2 elements (nested, with perhaps at least one being pre-existing), and 2 class names.

Web authors/designers are used to the simplicity of most HTML tags, e.g. to mark up a heading:

<source lang=html4strict>
<h1>Chris Messina</h1>
</source>

requires just 1 element.

[http://zeldman.com/ Jeffrey Zeldman] pointed out this apparent perceived incremental complexity (2 elements vs 1) during a microformats workshop in 2009 in New York City.

'''How can we make microformats just as easy?'''

'''Proposal: allow root class name only.'''

This would enable:

<source lang=html4strict>
<h1 class="vcard">Chris Messina</h1>
</source>

requiring only 1 class name for the simplest case.

==== renaming for usability ====
Otherwise known as, choosing one form of consistency over another.

'''Can we do even better?'''

One of the most common questions asked about hCard is:

[[hcard-faq#Why_does_hCard_use_vcard_as_the_root_class_name|Why does hCard use vcard as the root class name?]]

This slight inconsistency between the name of the format and the name of the root class name consistently causes confusion in a large percentage of newcomers to microformats.
* See [[issues#hcard-vs-vcard-name]] for details/links.

Though in microformats we believe very strongly in the [[principle]] of [[reuse]], we have to admit that in this case experience/evidence has shown that this may be a case where we re-used something too far beyond it's original meaning. Thus:

'''Proposal: use root class name "hcard" instead of "vcard" for future hCards.'''

This would result in:

<source lang=html4strict>
<h1 class="hcard">Chris Messina</h1>
</source>

making the simple case even simpler:

Just 1 additional class name, named the same as the format you're adding. Think hCard, markup class="hcard".

At a minimum for compatibility we should document that parsers should accept "hcard" as an alternative to "vcard" as the root class name for hCard 1.0, and similarly for hCalendar 1.0: "hcalendar" in addition to "vcalendar", "hevent" in addition to "vevent".

However, for [[microformats-2]] we are going to distinguish root class names further by using an "h-" prefix (e.g. "h-card"). Read on to understand why.

==== simplifying to only needing one element ====
It's very important for the simple case to be as simple as possible, to enable the maximum number of people to get started with minimum effort. (The idea of using a single class name for a microformat was proposed by Ryan Cannon in 2006 specifically [[hcard-implied|for hCard]], and rediscovered by [[User:Tantek|Tantek]] in 2010 and subsequently generalized to all microformats.)

From there on, it's ok to require incremental effort for incremental return.

E.g. to add any additional information about a person, add explicit property names.

'''How does this simple root-only case work?'''

* root class name reflects name of the microformat
* every microformat must require at most 1 property (preferably 0)
** admit that requiring a field in an application just results in noise (the 90210 problem - apps which require zip code get lots of false 90210 entries), and specify that any application use cases which appear to "require" specific properties must instead define how to imply sensible defaults for them.
* when only a root class name is specified, imply the entire text contents of the element as the value of the primary property of the microformat. e.g.
** "hcard" implies "fn"
** hcalendar event - "hevent" - implies "summary"
** "hreview" implies "summary"
** "hentry" implies "entry-summary" (perhaps collapse into "summary" - in practice they're not sufficiently semantically distinct to require separate property names)
** '''OR''' instead of making the one implied property be vocabulary specific, introduce a new generic (applicable to all vocabularies) 'p-name' property (subsuming hCard's 'fn'). See [[microformats-2-brainstorming#further_simplifications|microformats 2 brainstorming: further simplifications]] for latest thoughts along these lines, including the following specific mark-up implied generic properties across all microformats (based on existing published markup use-cases)
*** 'p-name'
*** 'u-url'
*** 'u-photo'

==== flat sets of properties ====
'''What more can we simplify about microformats?'''

Numerous individuals have provided the feedback that whenever there is more than one level of hierarchy in a microformat, many (most?) developers get confused - in particular Kavi Goel of Google / Rich Snippets provided this feedback at a microformats dinner. Thus depending on multiple levels of hierarchy is likely resulting in a loss of authorability, perhaps even accuracy as confusion undoubtedly leads to more errors. Thus:

'''Proposal: simplify all microformats to flat sets of properties. '''

What this means:
* all microformats are simply an object with a set of properties with values.
* no more subproperties- drop the notion of subproperties.
* use composition of multiple microformats for any further hierarchy, e.g. the "location" of an hCalendar event can be an hCard, or the "agent" of one hCard can be another hCard.

For example for hCard this would mean the following specific changes to keep relevant functionality:
* drop "n", promote all "n" subproperties to full properties
** given-name, family-name, additional-name, honorific-prefix, honorific-suffix
* treat "geo" as a nested microformat
* treat "adr" as a nested microformat (what to do about adr's "type"?)
* treat "org" as a flat string and drop "organization-name" and "organization-unit" (in practice rarely used, also not revealed or ignored in contact management user interfaces - e.g. Address Book)

Example: add a middle initial to the previous example Chris Messina's name, and markup each name component:

<source lang=html4strict>
<h1 class="hcard">
<span class="fn">
<span class="given-name">Chris</span>
<abbr class="additional-name">R.</abbr>
<span class="family-name">Messina</span>
</span>
</h1>
</source>

Note:
# use of an explicit span with "fn" to markup his entire formatted name
# use of the abbr element to explicitly indicate the semantic that "R." is merely an abbreviation for his additional-name.

==== distinguishing properties from other classes ====
Current microformats properties re-use generic terms like "summary", "photo", "updated" both for ease of use and understanding.

However, through longer term experience, we've seen sites that accidentally drop (or break) their microformats support (e.g. Upcoming.org, Facebook) because web authors sometimes rewrite all their class names, and either are unaware that microformats were in the page, or couldn't easily distinguish microformats property class names from other site-specific class names.

This issue has been reported by a number of web authors.
* See: [[issues#class-collisions]]

Thus microformats 2 uses ''prefixes'' for property class names, e.g.:
* '''p-summary''' instead of ''summary''
* '''u-photo''' instead of ''photo''
* '''dt-updated''' instead of ''updated''

Such prefixing of all microformats class names was first suggested by Scott Isaacs of Microsoft to Tantek on a visit to Microsoft sometime in 2006/2007, but specifically aimed at making microformats easier to parse. At the time the suggestion was rejected since microformats were focused on web authors rather than parsers.

However, since experience has shown that distinguishing property class names is an issue for '''both web authors and parser developers''', this is a key change that microformats 2 is adopting. See the next section for details.

=== COMMUNITY and TOOLS ===
The second most important constituency in the microformats community are the developers, programmers, tool-makers.

A non-trivial number of them have been sufficiently frustrated with some general issues with microformats that they've done the significant extra work to support very different and less friendly alternatives (microdata, RDFa). Based on this real-world data (market behavior), it behooves us to address these general issues with microformats for this constituency.

==== existing microformats parsing requirements ====
COMMUNITY and TOOLS (that) USE MICROFORMATS
* parser / parsing
* structured
* getting the data out
* json - 1:1 mapping

[[parsing]] microformats currently requires
# a list of root class names of each microformat to be parsed
# a list of properties for each specific microformats, along with knowledge of the type of each property in order to parse their data from potentially different portions of the HTML markup
# some number of format-specific specific rules (markup/content optimizations)

This has meant that whenever a new microformat is drafted/specificied/adopted, parsers need to updated to handle it correctly, at a minimum to parse them when inside other microformats and avoid errantly implying properties from one to the other (containment, [[mfo]] problem).

==== naming conventions for generic parsing ====
I think there is a fairly simple solution to #1 and #2 from the above list, and we can make progress towards minimizing #3. In short:

'''Proposal: a set of naming conventions for microformat root class names and properties that make it obvious when:'''
* a class name represents a microformat root class name
* a class name represents a microformat property name
* a class name represents a microformat property that needs special parsing (specific type of property).

In particular - derived from the real world examples of existing proven microformats (rather than any abstraction of what a schema should have)
* '''"h-*" for root class names''', e.g. "h-card", "h-event", "h-entry"
** The 'h-' prefix is based on the existing microformats naming pattern of starting with 'h'.
* '''"p-*" for simple (text) properties''', e.g. "p-fn", "p-summary"
** vocabulary generic parsing, element text in general, treat certain HTML element/attribute combination as special and use those first, e.g. img/alt, abbr/title.
** The 'p-' prefix is based on the word "property" starting with 'p'.
* '''"u-*" for URL properties''', e.g. "u-url", "u-photo", "u-logo"
** special parsing required: prefer a/href, img/src, object/data etc. attributes to element contents.
** The 'u-' prefix is based on URL/URI starting with the letter 'u', which is the type of most of these related properties.
* '''"dt-*" for datetime properties''', e.g. "dt-start", "dt-end", "dt-bday"
** special parsing required: [[value-class-pattern]], in particular separate date time value parsing for better human readabillity / DRY balance.
** The 'dt-' prefix is based on "date time" having the initials "dt" and the preponderance of existing date time properties starting with "dt", e.g. dtstart, dtend, dtstamp, dtreviewed.
* '''"e-*" for element tree properties''' where the entire contained element hierarchy is the value, e.g. "e-content" (formerly "entry-content") for [[hAtom]]. The 'e-' prefix can also be mnemonically remembered as "element tree", "embedded markup", or "encapsulated markup".
** special parsing required: follow the [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#serializing-html-fragments HTML spec: Serializing HTML Fragments algorithm] to create a serialization.

This provides a simpler transition/education story for existing microformats authors/publishers:
* "h*" to "h-*", "dt*" to "dt-*", url-like properties to "u-*", entire embedded markup to "e-*", and "p-*" for all "plain text" properties.

See [[microformats-2-prefixes]] for further thoughts and discussions on these and other class prefixes.

Example: taking that simple heading hCard example forward:

<source lang=html4strict>
<h1 class="h-card">Chris Messina</h1>
</source>

As part of microformats 2 we would immediately define root class names and property names for all existing microformats and drafts consistent with this naming convention, and require support thereof from all new implementations, as well as strongly encouraging existing implementations to adopt the simplified microformats 2 syntax and mechanism. Question: which microformats deserve explicit backward compatibility?

As a community we would continue to use the microformats [[process]] both for researching and determining the need for new microformats, and for naming new microformat property names for maximum re-use and interoperability of a shared vocabulary.

If it turns out we need a new property type in the future, we can use one of the remaining single-letter-prefixes to add it to microformats 2. This would require updating of parsers of course, but in practice the number of different types of properties has grown very slowly, and we know from other schema/programming languages that there's always some small limited number of scalar/atomic property types that you need, and using those you can create compound types/objects that represent richer / more complicated types of data. See [[microformats-2-prefixes]] for documentation of existing single-letter class name prefixes in practice.

=== ADVANTAGES ===
This has numerous advantages:
* '''better maintainability''' - much more obvious to web authors/designers/publishers which class names are for/from microformats.
* '''no chance of collision''' - for all practical purposes with existing class names and thus avoiding any need to add more complex CSS style rules to prevent unintended styling effects.
* '''simpler parsing''' - parsers can now do a simple stream-parse (or in-order DOM tree walk) and parse out '''all''' microformat objects, properties, and values, without having to know anything about any specific microformats.
* '''separation of syntax and vocabulary''' - by abstracting microformats 2 syntax independent of any vocabulary, it allows and encourages development of shared vocabularies that can work in alternative syntaxes.

More examples: here is that same heading example with name components:

<source lang=html4strict>
<h1 class="h-card">
<span class="p-fn">
<span class="p-given-name">Chris</span>
<abbr class="p-additional-name">R.</abbr>
<span class="p-family-name">Messina</span>
</span>
</h1>
</source>

with a hyperlink to Chris's URL:

<source lang=html4strict>
<h1 class="h-card">
<a class="p-fn u-url" href="http://factoryjoe.com/">
<span class="p-given-name">Chris</span>
<abbr class="p-additional-name">R.</abbr>
<span class="p-family-name">Messina</span>
</a>
</h1>
</source>

=== COMPATIBILITY ===

microformats 2 is backwards compatible in that in permits content authors to markup with both old and new class names for compatibility with old tools.

Here is a simple example:

<source lang=html4strict>
<h1 class="h-card vcard">
<span class="fn">Chris Messina</span>
</h1>
</source>

a microformats 2 parser would see the class name "h-card" and imply the one required property from the contents, while a microformats 1.0 parser would find the class name "vcard" and then look for the class name "fn". no data duplication is required. this is a very important continuing application of the <abbr title="don't repeat yourself">DRY</abbr> [[principle]].

And the above hyperlinked example with both sets of class names:

<source lang=html4strict>
<h1 class="h-card vcard">
<a class="p-fn u-url n fn url" href="http://factoryjoe.com/">
<span class="p-given-name given-name">Chris</span>
<abbr class="p-additional-name additional-name">R.</abbr>
<span class="p-family-name family-name">Messina</span>
</a>
</h1>
</source>

=== VENDOR EXTENSIONS ===

(this section was only discussed verbally and not written up during discussions - capturing here as it is topical)

Proprietary extensions to formats have typically been shortlived experimental failures with one big recent exception.

Proprietary or experimental CSS3 property implementations have been very successful.

There has been much use of border radius properties and animations/transitions which use CSS properties with vendor-specific prefixes like:

* -moz-border-radius
* -webkit-border-radius

etc.

Note that these are merely string '''prefixes''', not bound to any URL, and thus not namespaces in any practical sense of the word. This is quite an important distinction, as avoiding the need to bind to a URL has made them easier to support and use.

This use of vendor specific CSS properties has in recent years allowed the larger web design/development/implementor communities to experiment and iterate on new CSS features while the features were being developed and standardized.

The benefits have been two-fold:
* designers have been able to make more attractive sites sooner (at least in some browsers)
* features have been market / real-world tested before being fully standardized, thus resulting in better features

Implementers have used/introduced "x-" prefixes for IETF MIME/content-types for experimental content-types, MIME parameter extensions, and HTTP header extensions, per RFC 2045 Section 6.3, RFC 3798 section 3.3, and [https://secure.wikimedia.org/wikipedia/en/wiki/List_of_HTTP_header_fields#Common_non-standard_headers Wikipedia: HTTP header fields - non-standard headers] (could use RFC reference instead) respectively, like:

* application/x-latex (per [https://secure.wikimedia.org/wikipedia/en/wiki/Internet_media_type#Type_x Wikipedia Internet media type: Type x])
* x-spam-score (in email headers)
* X-Pingback (per [http://en.wikipedia.org/wiki/Pingback Wikipedia:Pingback])

Some standard types started as experimental "x-" types, thus demonstrating this experiment first, standardize later approach has worked for at least some cases:

* image/x-png (standardized as image/png, both per [http://tools.ietf.org/html/rfc2083 RFC2083])

There have been times when specific sites have wanted to extend microformats beyond what the set of properties in the microformat, and currently lack any '''experimental''' way to do so - to try and see if a feature (or even a whole format) is interesting in the real world before bothering to pursue researching and walking it through the microformats process. Thus:

'''Proposal:'''
* '*-x-' + '-' + meaningful name for root and property class names
** where "*" indicates the single-character-prefix as defined above
** where "x" indicates a literal 'x' for an experimental extension OR
** OR "x" indicates a vendor prefix (more than one character, e.g. like CSS vendor extension abbreviations, or some stock symbols, avoiding first words/phrases/abbreviations of microformats properties like dt-)
** e.g.
** "h-bigco-one-ring" - a hypothetical "bigco" vendor-specific "one-ring" microformat root class name.
** "p-goog-preptime" - to represent [http://www.google.com/support/webmasters/bin/answer.py?answer=173379 Google's "preptime" property extension] to [[hRecipe]] (aside: "duration" may be another property type to consider separate from "datetime" as it may be subject to different parsing rules.)
** "p-x-prep-time" - a possible experimental property name to be added to hRecipe upon consideration/documentation of real-world usage/uptake.

Background - this proposal is a composition of the following (at least somewhat) successful vendor extension syntaxes
* [http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords CSS 2.1 4.1.2.1 Vendor-specific extensions]
* IETF MIME/content-type "x-*" extensions per RFC 2045 Section 6.3. [http://en.wikipedia.org/wiki/Internet_media_type]
* IETF MIME experimental fields (e.g. x-spam-score)
* HTTP header extensions (e.g. x-pingback)
* note also [http://www.mnot.net/blog/2009/02/18/x- some critical thoughts from mnot]

=== USERS ===
Need more tools and interfaces that:
* publish
* copy/paste
* right-click on a microformat
* share
* search results

discussed some existing like: [[H2VX]] converts hCard to vCard, hCalendar to iCalendar

how would we re-implement Live Clipboard today, making it easier for publishers and developers?

=== SEE ALSO ===
* [[microformats2]]
* [[microformats2-brainstorming]] - moving more experimental / undeveloped / and rejected thoughts ideas here to simplify/progress *this* page further.
* [[microformats2-experimental-properties]] - listing experimental (-x- prefixed) properties and their use
* [[microformats2-prefixes]]
* [[microformats2-faq]]
* [[microformats2-parsing]]
* 2010-05-02 [[events/2010-05-02-microformats-2-0|microformats 2.0 discussion session at FOO East]]

microformats2

2016-03-01T12:56:50Z

Myfreeweb: fix acegiak's name and pronouns

<entry-title>microformats 2</entry-title>
Welcome to the microformats2 home page.

== Summary ==
Microformats2 is the simplest way to markup structured information in HTML. Microformats2 improves ease of use and implementation for <em>both</em> authors (publishers) and developers ([[microformats2-parsing|parser]] implementers).

Microformats2 replaces and supersedes both classic microformats, as well as incorporates lessons learned from [[microdata]] and [[RDFa]].

=== simple microformats 2 examples ===
Here are a few simple microformats2 examples along with canonical [[JSON]].

==== person example ====
* Simple person reference:
<source lang=html4strict>
<span class="h-card">Frances Berriman</span>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Frances Berriman"]
}
}]
}
</source>

----

==== hyperlinked person ====
* Simple hyperlinked person reference
<source lang=html4strict>
<a class="h-card" href="http://benward.me">Ben Ward</a>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Ben Ward"],
"url": ["http://benward.me"]
}
}]
}
</source>

----

==== hyperlinked person image ====
* Simple hyperlinked person image
<source lang=html4strict>
<a class="h-card" href="http://rohit.khare.org/">
<img alt="Rohit Khare"
src="https://s3.amazonaws.com/twitter_production/profile_images/53307499/180px-Rohit-sq_bigger.jpg" />
</a>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Rohit Khare"],
"url": ["http://rohit.khare.org/"],
"photo": ["https://s3.amazonaws.com/twitter_production/profile_images/53307499/180px-Rohit-sq_bigger.jpg"]
}
}]
}
</source>

Additional simple cases details in [[microformats-2-implied-properties]].

----

==== detailed person example ====
* More detailed person
<source lang=html4strict>
<div class="h-card">
<img class="u-photo" alt="photo of Mitchell"
src="https://webfwd.org/content/about-experts/300.mitchellbaker/mentor_mbaker.jpg"/>
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="u-url"
href="https://twitter.com/MitchellBaker"
>@MitchellBaker</a>)
<span class="p-org">Mozilla Foundation</span>
<p class="p-note">
Mitchell is responsible for setting the direction and scope of the Mozilla Foundation and its activities.
</p>
<span class="p-category">Strategy</span>
<span class="p-category">Leadership</span>
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"photo": ["https://webfwd.org/content/about-experts/300.mitchellbaker/mentor_mbaker.jpg"],
"name": ["Mitchell Baker"],
"url": [
"http://blog.lizardwrangler.com/",
"https://twitter.com/MitchellBaker"
],
"org": ["Mozilla Foundation"],
"note": ["Mitchell is responsible for setting the direction and scope of the Mozilla Foundation and its activities."],
"category": [
"Strategy",
"Leadership"
]
}
}]
}
</source>

----
Notes:
# The JSON <code>"type"</code> uses the full microformat root class name (e.g. <code>"h-card"</code>) for consistent identification.
# all properties are optional and syntactically plural with parsed values provided in document order; particular microformats (and applications there-of) may apply specific/singular semantics to first value of a property.

=== microformats2 design ===
microformats2 has the following key design aspects:
# '''Prefixes for class names.''' Class names used for microformats use prefixes that start with with <code>'h-' 'p-' 'u-' 'dt-', 'e-'</code>. These are '''syntax independent from vocabularies''', which can then be developed separately.
#* 'h-*' for root class names, e.g. 'h-card'
#* 'p-*' for simple (text) properties, e.g. 'p-name'
#* 'u-*' for URL properties, e.g. 'u-photo'
#* 'dt-*' for date/time properties, e.g. 'dt-bday'
#* 'e-*' for embedded markup properties, e.g. 'e-note'.<br/>See [[microformats2#naming_conventions_for_generic_parsing|prefix naming conventions]] for more details.
# '''Flat sets of optional properties.''' All microformats consist of a root, and a collection of properties. Hierarchical data is represented with nested microformats, typically as property values themselves. Properties are all optional and potentially multivalued (applications needing a singular semantic may use first instance).
# '''Single class markup for common uses.''' Common simple markup patterns require only a single microformat root class name, which parsers use to find a few generic properties: <code>name, url, photo</code>. The simple microformats2 examples above demonstrate these.

Parsing details for each of these prefixes (including how to generate canonical JSON) are specified step-by-step in the:
* '''[[microformats2-parsing|microformats2 parsing specification]]'''

Note: most properties are specified and used with a single specific prefix (or occasionally two or three) that is self-evident from context. However any parsing prefix can be used with any property, especially if you find a good reason to do so!

== v2 vocabularies ==
Status: '''<span id="draft_v2_vocabularies">draft</span>'''. Please review and provide feedback in [[IRC]].
* [[h-adr]]
* [[h-card]]
* [[h-entry]]
* [[h-event]]
* [[h-feed]]
* [[h-geo]]
* [[h-item]]
* [[h-listing]]
* [[h-product]]
* [[h-recipe]]
* [[h-resume]]
* [[h-review]]
* [[h-review-aggregate]]

See below for vocabulary summaries.

=== h-adr ===
{{main|h-adr}}

The '''h-adr''' microformat is for marking up structured locations such as addresses, physical and/or postal. This is an update to [[adr]].

root class name: '''<code>h-adr</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-adr</nowiki>

properties:
* '''<code>p-post-office-box</code>'''
* '''<code>p-extended-address</code>'''
* '''<code>p-street-address</code>'''
* '''<code>p-locality</code>'''
* '''<code>p-region</code>'''
* '''<code>p-postal-code</code>'''
* '''<code>p-country-name</code>'''
* '''<code>p-label</code>''' - new in [[vCard4]] ([[RFC6350]])
* '''<code>p-geo</code>''' (or '''<code>u-geo</code>''' with a RFC 5870 geo: URL) - new in [[vCard4]] ([[RFC6350]])
* '''<code>p-latitude</code>''' - new in [[vCard4]] ([[RFC6350]] from RFC 5870)
* '''<code>p-longitude</code>''' - new in [[vCard4]] ([[RFC6350]] from RFC 5870)
* '''<code>p-altitude</code>''' - new in [[vCard4]] ([[RFC6350]] from RFC 5870)

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-adr" is found, don't look for an "adr" on the same element.

compat root class name: <code id="adr">adr</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>post-office-box</code>
* <code>extended-address</code>
* <code>street-address</code>
* <code>locality</code>
* <code>region</code>
* <code>postal-code</code>
* <code>country-name</code>

=== h-card ===
{{main|h-card}}

The '''h-card''' microformat is for marking up people and organizations. This is an update to [[hCard]].

root class name: '''<code>h-card</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-card</nowiki>

properties:
* '''<code>p-name</code>'''
* '''<code>p-honorific-prefix</code>'''
* '''<code>p-given-name</code>'''
* '''<code>p-additional-name</code>'''
* '''<code>p-family-name</code>'''
* '''<code>p-sort-string</code>'''
* '''<code>p-honorific-suffix</code>'''
* '''<code>p-nickname</code>'''
* '''<code>u-email</code>'''
* '''<code>u-logo</code>'''
* '''<code>u-photo</code>'''
* '''<code>u-url</code>'''
* '''<code>u-uid</code>'''
* '''<code>p-category</code>'''
* '''<code>p-adr</code>'''
* '''<code>p-post-office-box</code>'''
* '''<code>p-extended-address</code>'''
* '''<code>p-street-address</code>'''
* '''<code>p-locality</code>'''
* '''<code>p-region</code>'''
* '''<code>p-postal-code</code>'''
* '''<code>p-country-name</code>'''
* '''<code>p-label</code>'''
* '''<code>p-geo</code>''' or '''<code>u-geo</code>''' with a RFC 5870 geo: URL, new in [[vCard4]] ([[RFC6350]])
* '''<code>p-latitude</code>'''
* '''<code>p-longitude</code>'''
* '''<code>p-altitude</code>''' - new in [[vCard4]] ([[RFC6350]] from RFC 5870)
* '''<code>p-tel</code>'''
* '''<code>p-note</code>'''
* '''<code>dt-bday</code>'''
* '''<code>u-key</code>'''
* '''<code>p-org</code>'''
* '''<code>p-job-title</code>''' - previously 'title' in hCard, disambiguated.
* '''<code>p-role</code>
* '''<code>u-impp</code>''' per RFC 4770, new in [[vCard4]] ([[RFC6350]])
* '''<code>p-sex</code>''' new in [[vCard4]] ([[RFC6350]])
* '''<code>p-gender-identity</code>''' new in [[vCard4]] ([[RFC6350]])
* '''<code>dt-anniversary</code>''' new in [[vCard4]] ([[RFC6350]])
* ...

Reserved properties: (properties not used much (if at all) in practice)
* '''<code>p-organization-name</code>'''
* '''<code>p-organization-unit</code>'''
* '''<code>p-tz</code>'''
* '''<code>dt-rev</code>'''
* ...

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-card" is found, don't look for a "vcard" on the same element.

compat root class name: <code id="vcard">vcard</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>honorific-prefix</code>
* <code>given-name</code>
* <code>additional-name</code>
* <code>family-name</code>
* <code>honorific-suffix</code>
* <code>nickname</code>
* <code>email</code> - parse as '''u-'''
* <code>logo</code> - parse as '''u-'''
* <code>photo</code> - parse as '''u-'''
* <code>url</code> - parse as '''u-'''
* <code>uid</code> - parse as '''u-'''
* <code>category</code>
* <code>adr</code> - parse as '''<code>p-adr h-adr</code>''' including compat root class <code>adr</code>
* <code>extended-address</code>
* <code>street-address</code>
* <code>locality</code>
* <code>region</code>
* <code>postal-code</code>
* <code>country-name</code>
* <code>label</code>
* <code>geo</code> - parse as '''<code>p-geo h-geo</code>''' including compat root class <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* <code>tel</code>
* <code>note</code>
* <code>bday</code> - parse as '''dt-'''
* <code>key</code> - parse as '''u-'''
* <code>org</code>
* <code>organization-name</code>
* <code>organization-unit</code>
* <code>title</code> - parse as '''p-job-title'''
* <code>role</code>
* ...

Reserved: (backward compat properties that parsers {{may}} implement, if they do, they {{must}} implement in this way:
* <code>tz</code>
* <code>rev</code> - parse as '''dt-'''
* ...

Note: use of 'value' within 'tel' should be automatically handled by the support of the [[value-class-pattern]]. And for now, the 'type' subproperty of 'tel' is dropped/ignored. If there is demonstrable documented need for additional tel types (e.g. fax), we can introduce new flat properties as needed (e.g. p-tel-fax).

=== h-entry ===
{{main|h-entry}}

The '''h-entry''' microformat is for marking up syndicatable content such as blog posts, notes, articles, comments, photos and similar. This is an update to [[hAtom]].

root class name: '''<code>h-entry</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-entry</nowiki>

properties:
* '''<code>p-name</code>''' (was p-entry-title, see issues)
* '''<code>p-summary</code>''' (was p-entry-summary, see issues)
* '''<code>e-content</code>''' (was e-entry-content, see issues)
* '''<code>dt-published</code>'''
* '''<code>dt-updated</code>'''
* '''<code>p-author</code>'''
* '''<code>p-category</code>'''
* '''<code>u-url</code>'''
* '''<code>u-uid</code>'''
* '''<code>p-geo</code>'''
* '''<code>p-latitude</code>'''
* '''<code>p-longitude</code>'''

This is an update to [[hAtom]].

Brainstorming:

The following properties are proposed additions to h-entry above and beyond what hAtom (or Atom) provides, based on various existing link preview markup conventions:
* '''<code>u-photo</code>'''
* '''<code>u-audio</code>''' - consider special u- parsing rules for <code><audio></code>
* '''<code>u-video</code>''' - consider special u- parsing rules for <code><video></code>
* '''<code>u-in-reply-to</code>''' - for links to other posts that this post is a reply to (comment regarding, etc.)

Backward compatibility:

(*)hAtom-specific implementations that perform custom display or translation (e.g. to Atom XML) {{should}} prefer <code>p-name</code> over <code>p-entry-title</code>, and use <code>p-entry-title</code> value(s) as a fallback if there is no <code>p-name</code>.

For hAtom backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-entry" is found, don't look for a "hentry" on the same element.

compat root class name: <code id="hentry">hentry</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>entry-title</code> - parse as '''<code>p-name</code>'''
* <code>entry-summary</code>
* <code>entry-content</code> - parse as '''e-'''
* <code>published</code> - parse as '''dt-'''
* <code>updated</code> - parse as '''dt-'''
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>category</code>
* <code>geo</code> - parse as '''<code>p-geo h-geo</code>''' including compat root <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* ...

<span id="h-entry-faq">FAQ:</span>
<div class="discussion">
* '''What is the <code>p-name</code> of a [http://indiewebcamp.com/note note]?'''
** A few options, from simplest to most detailed.
*** '''same as the p-content/e-content''' property.
*** '''same as the <code>title</code> element''' on the note permalink post page. When publishing a note on its own permalink post page, the contents of the note are likely abbreviated for the title of the page. The same abbreviation can be used for the p-name.
*** '''first sentence of the p-content/e-content''' property. It may be better for [http://indiewebcamp.com/syndication syndication] and [[link-preview]] purposes to provide just the first sentence of the note as the <code>p-name</code>. Similarly if only a portion of the content is syndicated to other sites, that portion can be marked up as the <code>p-summary</code>.
* ...
</div>

Resolved Issues:
* 2012-245 Resolved. See [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-120 2012-243 IRC discussion/consensus] for:
** Use '''<code>p-summary</code> instead of <code>p-entry-summary</code>'''. The historical semantic of "entry-summary" is not different from "summary" in any significant (or discernible way). Collapsing the two will simplify the overall microformats2 vocabularies further. In microformats2, entry-summary is no more.
** Use '''<code>e-content</code> instead of <code>e-entry-content</code>'''. Same point and advantage. In microformats2, entry-content is no more.
** '''drop <code>p-entry-title</code>'''. Unnecessary and subsumed by "p-name". Would consider move to backward compat only if cases are presented - known publishing uses are expected to be updated shortly.

=== h-event ===
{{main|h-event}}

The '''h-event''' microformat is for marking up events. This is an update to [[hCalendar]].

root class name: '''<code>h-event</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-event</nowiki>

properties:
* '''<code>p-name</code>'''
* '''<code>p-summary</code>'''(*)
* '''<code>dt-start</code>'''
* '''<code>dt-end</code>'''
* '''<code>dt-duration</code>'''
* '''<code>p-description</code>'''
* '''<code>u-url</code>'''
* '''<code>p-category</code>'''
* '''<code>p-location</code>'''
* '''<code>p-geo</code>'''
* '''<code>p-latitude</code>'''
* '''<code>p-longitude</code>'''
* ...

This is an update to [[hCalendar]].

(*)hCalendar-specific implementations that perform custom display or translation (e.g. to iCalendar .ics) {{should}} prefer <code>p-name</code> over <code>p-summary</code>, and use <code>p-summary</code> value(s) as a fallback if there is no <code>p-name</code>.

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-event" is found, don't look for a "vevent" on the same element.

compat root class name: <code id="vevent">vevent</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>summary</code> - parse as '''<code>p-name</code>'''
* <code>dtstart</code> - parse as '''<code>dt-start</code>'''
* <code>dtend</code> - parse as '''<code>dt-end</code>'''
* <code>duration</code> - parse as '''<code>dt-duration</code>'''
* <code>description</code>
* <code>url</code> - parse as '''u-'''
* <code>category</code>
* <code>location</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>, and compat root <code>adr</code> in the absence of <code>h-adr</code>
* <code>geo</code> - parse as '''<code>p-geo h-geo</code>''' including compat root <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* ...

=== h-geo ===
{{main|h-geo}}

The '''h-geo''' microformat is for marking up WGS84 geophysical coordinates. This is an update to [[geo]].

root class name: '''<code>h-geo</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-geo</nowiki>

properties:
* '''<code>p-latitude</code>'''
* '''<code>p-longitude</code>'''
* '''<code>p-altitude</code>''' - new in [[vCard4]] ([[RFC6350]] from RFC 5870)

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-geo" is found, don't look for an "geo" on the same element.

compat root class name: <code id="geo">geo</code>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>latitude</code>
* <code>longitude</code>

=== h-item ===
{{main|h-item}}

The '''h-item''' microformat is for marking up the item of an [[h-review]] or [[h-product]]. This is an update to part of [[hReview]].

root class name: '''<code>h-item</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-item</nowiki>

properties:
* '''<code>p-name</code>'''
* '''<code>u-photo</code>'''
* '''<code>u-url</code>'''

Note: in practice, due to the microformats2 implied property rules, it is expected that most uses of "h-item" won't require any explicit properties at all (since microformats2 parsers will infer name, photo, and url properties from the structure of the element with "h-item" and its contained content/elements if any).

=== h-product ===
{{main|h-product}}

The '''h-product''' microformat is for marking up products. This is an update to [[hProduct]].

root class name: '''<code>h-product</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-product</nowiki>

properties:
* '''<code>p-name</code>''' - name of the product
* '''<code>u-photo</code>''' - photo of the product
* '''<code>p-brand</code>''' - manufacturer, can also be a nested <code>h-card</code>
* '''<code>p-category</code>''' - freeform categories or tags applied to the item by the reviewer
* '''<code>e-description</code>'''
* '''<code>u-url</code>''' - URL of the product
* '''<code>u-identifier</code>''' - includes type (e.g. mpn, upc, isbn, issn, sn, vin, sku etc.) and value.
* '''<code>p-review</code>''' - a review of the product, can also be a nested <code>h-review</code>
* '''<code>p-price</code>''' - retail price of the product

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-product" is found, don't look for an "hproduct" on the same element.

compat root class name: <code id="hproduct">hproduct</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>photo</code> - parse as '''u-'''
* <code>brand</code>
* <code>category</code>
* <code>description</code>
* <code>identifier</code> - parse as '''u-'''
* <code>url</code> - parse as '''u-'''
* <code>review</code> - including compat root class <code>hreview</code> in the absence of <code>h-review</code>
* <code>price</code>

Note: [[hProduct]] has at least one experimental property which has real world adoption due to [[Google]] and [[Bing]] search support of hProduct. Currently this is: '''price'''

=== h-recipe ===
{{main|h-recipe}}

The '''h-recipe''' microformat is for marking up food recipes. This is an update to [[hRecipe]].

root class name: '''<code>h-recipe</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-recipe</nowiki>

properties:
* '''<code>p-name</code>''' - the name of the recipe
* '''<code>p-ingredient</code>''' - describes one or more ingredients used in the recipe.
* '''<code>p-yield</code>''' - Specifies the quantity produced by the recipe, like how many persons it satisfyies
* '''<code>e-instructions</code>''' - the method of the recipe.
* '''<code>dt-duration</code>''' - the time it takes to prepare the meal described by the recipe.
* '''<code>u-photo</code>''' - an accompanying image

Experimental properties with wide adoption
* '''<code>p-summary</code>''' - provides a short summary or introduction
* '''<code>p-author</code>''' - the person who wrote the recipe with <code>h-card</code>
* '''<code>dt-published</code>''' - the date the recipe was published
* '''<code>p-nutrition</code>''' - nutritional information like calories, fat, dietary fiber etc.
* ...

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-recipe" is found, don't look for an "hrecipe" on the same element.

compat root class name: <code id="hrecipe">hrecipe</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>ingredient</code>
* <code>yield</code>
* <code>instructions</code> - parse as '''e-'''
* <code>duration</code> - parse as '''dt-'''
* <code>photo</code> - parse as '''u-'''
* <code>summary</code>
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>nutrition</code>

Note: [[hRecipe]] has a number of experimental properties which have real world adoption due to [[Google]] recipe search support of hRecipe. These are: summary, author, published and nutrition

=== h-resume ===
{{main|h-resume}}

The '''h-resume''' microformat is for marking up resumes. This is an update to [[hResume]].

root class name: '''<code>h-resume</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-resume</nowiki>

properties:
* '''<code>p-summary</code>''' - overview of qualifications and objectives
* '''<code>p-contact</code>''' - current contact info in an <code>h-card</code>
* '''<code>p-education</code>''' - an education <code>h-calendar</code> event, years, nested <code>h-card</code> of the school, location.
* '''<code>p-experience</code>''' - a job or other professional experience <code>h-calendar</code> event, years, nested <code>h-card</code> of the organization, location, job-title.
* '''<code>p-skill</code>''' - a skill or ability, optionally including level and/or duration of experience
* '''<code>p-affiliation</code>''' - an affiliation with an <code>h-card</code> organization

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-resume" is found, don't look for an "hresume" on the same element.

compat root class name: <code id="hresume">hresume</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>summary</code>
* <code>contact</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>education</code> - including compat root <code>vevent</code> in the absence of <code>h-event</code>
* <code>experience</code> - including compat root <code>vevent</code> in the absence of <code>h-event</code>
* <code>skill</code>
* <code>affiliation</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>

Note: skill has a [[hresume-skill-brainstorm|proposed expansion into competency]] with explicit summary, rating and/or duration components. Based on existing real world adoption, we should consider an h-competency vocabulary with p-summary, p-rating, and dt-duration properties.

=== h-review ===
{{main|h-review}}

The '''h-review''' microformat is for marking up reviews. This is an update to [[hReview]]. See also [[h-item]].

root class name: '''<code>h-review</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-review</nowiki>

properties:
* '''<code>p-name</code>''' - name of the review
* '''<code>p-item</code>''' - thing been reviewed i.e. business or person (h-card), event (h-event), place (h-adr or h-geo), product (h-product), website, url, or other item ([[h-item]]).
* '''<code>p-reviewer</code>''' - person who authored the review
* '''<code>dt-reviewed</code>''' - date time of when the review was written
* '''<code>p-rating</code>''' - value from 1-5 indicating a rating for the item (5 best).
* '''<code>p-best</code>''' - define best rating value. can be numerically lower than worst.
* '''<code>p-worst</code>''' - define worst rating value. can be numerically higher than best.
* '''<code>e-description</code>''' - the full text written evaluation and opinion of the reviewer
* '''<code>p-category</code>''' - freeform categories or tags applied to the item by the reviewer
* '''<code>u-url</code>''' - URL of the review

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-review" is found, don't look for an "hreview" on the same element.

compat root class name: <code id="hreview">hreview</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>summary</code> parse as '''<code>p-name</code>'''
* <code>fn</code> - parse as '''p-name''' of the item being reviewed (p-item h-item p-name)
* <code>photo</code> - parse as '''u-photo''' of the item being reviewed (p-item h-item u-photo)
* <code>url</code> - parse as '''u-url''' of the item being reviewed (p-item h-item u-url)
* <code>reviewer</code> - including compat root vcard in the absence of h-card
* <code>dtreviewed</code> - parse as '''dt-'''
* <code>rating</code>
* <code>best</code>
* <code>worst</code>
* <code>description</code> - parse as '''e-'''
* <code>rel="tag"</code> - parse as '''p-category'''
* <code>rel="self bookmark"</code> - parse as '''u-url'''. note that <code>rel</code> attribute value is treated as a space separated set, thus any presence of "self" and "bookmark" within such a set in a rel value is accepted.

Note: The [[hReview]] format has three properties which make use of <code>rel</code> attribute, these are <code>tag</code>, permalink (via the <code>self</code> and <code>bookmark</code> values) and <code>license</code>. Microformats 2 parsers {{should}} map these URLs into the page scoped rel collection.

=== h-review-aggregate ===
{{main|h-review-aggregate}}

The '''h-review-aggregate''' microformat is for marking up aggregate reviews of a single item. This is an update to [[hreview-aggregate]]. See also [[h-item]].

root class name: '''<code>h-review-aggregate</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-review-aggregate</nowiki>

properties:
* '''<code>p-name</code>''' - name of the review
* '''<code>p-item</code>''' - thing been reviewed i.e. business or person (h-card), event (h-event), place (h-adr or h-geo), product (h-product), website, url, or other item (h-item).
* '''<code>p-rating</code>''' - value from 1-5 indicating average rating for the item (5 best).
* '''<code>p-best</code>''' - define best rating value. can be numerically lower than worst.
* '''<code>p-worst</code>''' - define worst rating value. can be numerically higher than best.
* '''<code>p-count</code>''' - number of reviews aggregated.
* '''<code>p-votes</code>''' - number of reviewers who have rated the product, thus contributing to the average rating.
* '''<code>p-category</code>''' - freeform categories or tags applied to the item by the reviewer
* '''<code>u-url</code>''' - URL of the review

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-review-aggregate" is found, don't look for an "hreview-aggregate" on the same element.

compat root class name: <code id="hreview-aggregate">hreview-aggregate</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>summary</code> parse as '''<code>p-name</code>'''
* <code>fn</code> - parse as '''p-name''' of the item being reviewed (p-item h-item p-name)
* <code>photo</code> - parse as '''u-photo''' of the item being reviewed (p-item h-item u-photo)
* <code>url</code> - parse as '''u-url''' of the item being reviewed (p-item h-item u-url)
* <code>rating</code>
* <code>best</code>
* <code>worst</code>
* <code>count</code>
* <code>votes</code>
* <code>rel="tag"</code> - parse as '''p-category'''
* <code>rel="self bookmark"</code> - parse as '''u-url'''. note that <code>rel</code> attribute value is treated as a space separated set, thus any presence of "self" and "bookmark" within such a set in a rel value is accepted.

=== v2 vocab notes ===
Notes:
* All v2 vocabularies are defined as flat lists of properties of an object/item, and thus can be used in microformats-2 syntax as shown, or in microdata items, or RDFa. The microformats-2 property parsing prefixes "p-", "u-", "dt-", "e-" are omitted when using defined properties in microdata itemprop and RDFa property as those syntaxes have their own element-specific parsing rules.
* Profile URLs are provided for use with the HTML4 <code>profile</code> attribute, microdata <code>itemtype</code> attribute, and RDFa <code>vocab</code> & <code>typeof</code> attributes (though the latter requires slicing off the trailing segment of the profile for the typeof attribute, and leaving the rest in vocab).
* microformats 2 properties may also be explicitly bound as URIs using [[rel-profile]], the [[html5-profile]] attribute proposal, or an HTML5 'vocab' attribute instead. If URI bound terms are important to you, please express interest on [[rel-profile]], [[html5-profile]], or contribute to an [[html5-vocab]] draft.

=== v2 vocab to-do ===
To do:
* write a simple tutorial for creating/getting started with microformats-2 markup for new content
* examples in each h-* spec listed above of how to embed other microformats in them
* actual profile documents at <nowiki>http://microformats.org/profile/h-*</nowiki> URLs mentioned above.
* Provide any necessary microdata-specific language as needed (e.g. to be comparably understandable to the [http://www.whatwg.org/specs/web-apps/current-work/#vcard sample vCard4/hCard1 microdata vocabulary]. Also provide any necessary RDFa-specific language as needed. Both preferably in a generic vocabulary-independent way.
* write a porting guide mapping v1 property -> v2 property
** use-case: simple search/replace in templates (e.g. in case web author doesn't remember existing microformats vocabs and where they used them).
** advise using *both* in existing templates (e.g. in case some CSS depends on the existing microformats)
* analyzie/document how well the microformats2 model and vocabularies satisfy the [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019681.html use-cases used to design/create microdata].

== combining microformats ==
Since microformats 2 uses simple flat sets of properties for each microformat, multiple microformats are combined to indicate additional structure.

=== h-event location h-card ===
Events commonly have venue information with additional structure, like address information. For example:

<source lang=html4strict>
<div class="h-event">
<a class="p-name u-url" href="http://indiewebcamp.com/2012">
IndieWebCamp 2012
</a>
from <time class="dt-start">2012-06-30</time>
to <time class="dt-end">2012-07-01</time> at
<span class="p-location h-card">
<a class="p-name p-org u-url" href="http://geoloqi.com/">
Geoloqi
</a>,
<span class="p-street-address">920 SW 3rd Ave. Suite 400</span>,
<span class="p-locality">Portland</span>,
<abbr class="p-region" title="Oregon">OR</abbr>
</span>
</div>
</source>

The nested h-card used to structure the p-location of the h-event is represented as a structured value for "location" in the JSON, which has an additional key, "value" that represents the plain text version parsed from the p-location.

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-event"],
"properties": {
"name": ["IndieWebCamp 2012"],
"url": ["http://indiewebcamp.com/2012"],
"start": ["2012-06-30"],
"end": ["2012-07-01"],
"location": [{
"value": "Geoloqi",
"type": ["h-card"],
"properties": {
"name": ["Geoloqi"],
"org": ["Geoloqi"],
"url": ["http://geoloqi.com/"],
"street-address": ["920 SW 3rd Ave. Suite 400"],
"locality": ["Portland"],
"region": ["Oregon"]
}
}]
}
}]
}
</source>

Questions:
<div class="discussion">
* Should the nested hCard be present also as a top-level item in the JSON? - [[User:Tantek|Tantek]] 02:02, 19 June 2012 (UTC)
** My current (2012-243) leaning is no. - [[User:Tantek|Tantek]] 18:53, 30 August 2012 (UTC)
** If so, how do we avoid expansion of the JSON geometrically proportional to the depth of microformat nesting? (Or do we not worry about it?)
* Should there be a canonical hierarchical JSON and a canonical flattened JSON? - [[User:Tantek|Tantek]] 02:02, 19 June 2012 (UTC)
** My current (2012-243) leaning is no, we stick with one canonical JSON for uf2 which is hierarchical. - [[User:Tantek|Tantek]] 18:53, 30 August 2012 (UTC)
** If so, should the flattened JSON have references from properties to nested microformats that have been pushed to the top level per flattening? - [[User:Tantek|Tantek]] 02:02, 19 June 2012 (UTC)
*** If so, what convention does/do JSON follow for such synthetic local reference identifiers? - [[User:Tantek|Tantek]] 02:02, 19 June 2012 (UTC)
</div>

Notes:
* The 'location' value reflects the visible text of its element, including spaces and punctuation, as well as the state abbreviation 'OR'. The 'h-card' property values are only what is marked up, and thus include structure values without extra punctuation, and the state takes the expanded form from the <code>title</code> attribute of its <code><abbr></code> element.

=== h-card org h-card ===
People often publish information general to their company rather than specific to them, in which case, they may wish to encapsulate that in separately nested microformat. E.g. here is a simple h-card example with org property:

[http://blog.lizardwrangler.com Mitchell Baker] (Mozilla Foundation)

with source:
<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<span class="p-org">Mozilla Foundation</span>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"],
"org": ["Mozilla Foundation"]
}
}]
}
</source>

Sometimes such organization affiliations are hyperlinked to the website of the organization:

[http://blog.lizardwrangler.com Mitchell Baker] ([http://mozilla.org/ Mozilla Foundation])

You can mark that up with a nested h-card:
<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="p-org h-card"
href="http://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"],
"org": [{
"value": "Mozilla Foundation",
"type": ["h-card"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["http://mozilla.org/"]
}
}]
}
}]
}
</source>

Note: the nested h-card has implied 'name' and 'url' properties, just like any other root-class-name-only h-card on an <code><a href></code> would.

'''FOR PARSERS ONLY:'''

The nested 'h-card' could be marked up as an 'h-org' as well, which adds it to the nested microformat's type array, all as part of the property specified by the 'p-org'.

<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="p-org h-card h-org"
href="http://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"],
"org": [{
"value": "Mozilla Foundation",
"type": ["h-card", "h-org"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["http://mozilla.org/"]
}
}]
}
}]
}
</source>

'''FOR PARSERS ONLY:'''

Without a property class name like 'p-org' holding all the nested objects together, we need to introduce another array for nested children (similar to the existing DOM element notion of children) of a microformat that are not attached to a specific property:

<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="h-org h-card"
href="http://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"]
},
"children": [{
"type": ["h-card","h-org"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["http://mozilla.org/"]
}
}]
}]
}
</source>

Since there's no property class name on the element with classes 'h-card' and 'h-org', the microformat representing that element is collected into the children array.

Such a nested microformat implies some relationship (containment, being related), but is not as useful as if the nested microformat was a specific property of its parent.

For this reason it's recommended that authors should not publish nested microformats without a property class name, and instead, when nesting microformats, authors should always specify a property class name (like 'p-org') on the same element as the root class name(s) of the nested microformat(s) (like 'h-card' and/or 'h-org').

'''FOR PARSERS ONLY:'''

Or the nested object could be only marked up with 'h-card'. Source:

<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="h-card"
href="http://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"]
},
"children": [{
"type": ["h-card"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["http://mozilla.org/"]
}
}]
}]
}
</source>

'''TO DO: Add h-event h-card example and JSON, per real world publishing examples like [http://www.swingtime.co.uk/List/ClSouth.html Swing Time: Classes in Southern England].'''

== authoring ==
=== minimal markup ===
The best way to use microformats-2 is with as little additional markup as possible. This keeps your code cleaner, improves its maintainability, and thus the quality and longevity of your microformats.

One big advantage of microformats-2 over previous microformats (and others) is the ability to add one class name to an existing element to create a structured item.

See the [[microformats-2#simple_microformats_2_examples|simple examples at the top]] for a start, e.g.

Simple hCards work just by adding <code>class="h-card"</code> :
<source lang=html4strict>
<span class="h-card">Frances Berriman</span>

<a class="h-card" href="http://benward.me">Ben Ward</a>

<img class="h-card" alt="Sally Ride"
src="http://upload.wikimedia.org/wikipedia/commons/a/a4/Ride-s.jpg"/>

<a class="h-card" href="http://tantek.com">
<img alt="Tantek Çelik" src="http://ttk.me/logo.jpg"/>
</a>
</source>

* Tip: Inside an open tag, put the <code>class</code> attribute <em>first</em>, then any human text content attributes (e.g. <code>alt</code>), then URL attributes (e.g. <code>href</code> <code>src</code>), and lastly other attributes (e.g. <code>style</code>). Putting the class attribute first ties it closely to the element name/tag itself, makes it more obvious, and thus more likely to be kept up to date.

=== backward compatible ===
If you depend on current microformats [[implementations]], while they're being updated to support [[microformats-2]], you can include both existing microformats and microformats-2 markup.

In short: use both sets of class names simultaneously.

When doing so, use them on the same element, with the microformats-2 class name first, followed immediately by the existing microformats class name.

Here are the microformats-2 hCards from above with current [[hCard]] markup as well, which may require adding a wrapping element (e.g. a <code><span></code>) to separate the root class name element from explicit property class name elements:

<source lang=html4strict>
<span class="h-card vcard">
<span class="p-name fn">Frances Berriman</span>
</span>

<span class="h-card vcard">
<a class="p-name fn u-url url" href="http://benward.me">Ben Ward</a>
</span>

<span class="h-card vcard">
<img class="p-name fn u-photo photo" alt="Sally Ride"
src="http://upload.wikimedia.org/wikipedia/commons/a/a4/Ride-s.jpg"/>
</span>

<span class="h-card vcard">
<a class="u-url url" href="http://tantek.com">
<img class="p-name fn u-photo photo" alt="Tantek Çelik"
src="http://ttk.me/logo.jpg"/>
</a>
</span>
</source>

Tips:
* use the microformats-2 class name first, e.g.
** <code>class="h-card vcard"</code>
** <code>class="u-url url"</code>
* and pair them when using an element for multiple properties, e.g.:
** <code>class="p-name fn u-url url"</code>
** <code>class="p-name fn u-photo photo"</code>
* put microformats classes after classes for CSS (since page authors will likely interact more with their own classes for design than with microformats classes), e.g. as used on individual microformats [[events]] pages:
** <code>class="event-page h-event vevent"</code>

The prefixes (h-, p-, etc.) of microformats2 class names provide easier recognition, and when followed by the similarly named existing class name, they're more easily recognized as related and thus kept together when the markup is maintained over time.

Related FAQ: [[microformats2-faq#when_using_both_h-card_and_vcard_which_should_be_first_and_why|When using both h-card and vcard which should be first and why?]]

== validators ==
microformats2 validators:

{{new}} Test your microformatted web page with:
* https://pin13.net/mf2/

Barnaby Walters has a hosted version of the open source php-mf2 [[parser]] where you can enter your markup into a textarea and see how it's parsed:
* http://waterpigs.co.uk/php-mf2/

See the [[validators]] page for a longer list of validators.

== Examples in the wild ==
Please add new examples in the wild of microformats-2 to the top of this list. When it gets too big we can move it to a separate page like [[microformats-2-examples-in-wild]].

* ...
* David John Mead marks up his profile, blog posts and comments with h-card, h-entry and h-cite on [http://davidjohnmead.com davidjohnmead.com]
* [[User:Brian|Brian Suda]] marks up his blog posts up with h-entry and h-card on [http://optional.is/required/ optional.is]
* Ashton McAllan marks up her blog posts, reposts, comments and likes with h-entry, h-card and h-cite on [https://acegiak.net/ acegiak.net]
* Emma Kuo marks up her blog posts and notes with h-entry and h-card on [http://notenoughneon.com/ notenoughneon.com]
* Scott Jenson marks up his blog posts with h-entry and h-card on [http://jenson.org/ jenson.org]
* Emily McAllen marks up her blog posts with h-entry and h-card on [http://blackwoolholiday.com/ blackwoolholiday.com]
* Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on [https://snarfed.org/ snarfed.org]
* Barry Frost marks up his notes with h-entry, h-card and h-cite on [http://barryfrost.com/ barryfrost.com]
* Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on [http://caseorganic.com/ caseorganic.com]
* Johannes Ernst marks up his blog posts with h-entry on [http://upon2020.com/blog/ upon2020.com]
* Michiel de Jong marks up his profile and notes with h-entry and h-card on [https://michielbdejong.com/ michielbdejong.com]
* Mike Taylor marks up his profile and blog posts with h-card and h-entry on [https://bear.im/bearlog/ bear.im]
* Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on [http://erinjo.is/ erinjo.is]
* Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on [https://jeena.net/ jeena.net]
* Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on [http://andysylvester.com/2014/03/01/howto-setting-up-the-selfoss-feed-reader-with-microformats-support/ andysylvester.com] (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --[[User:Barnabywalters|bw]] 14:44, 13 March 2014 (UTC))
* Hakan Demir marks up his Coupon and Voucher blog posts with h-entry and h-card on [http://www.gutscheinflagge.de/ gutscheinflagge.de]
* Chloe Weil marks up her blog posts with h-entry on [http://chloeweil.com/blog chloeweil.com]
* Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on [http://christopheducamp.com/ christopheducamp.com]
* Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on [http://glennjones.net/ glennjones.net]
* Marcus Povey marks up his blog posts and profile with h-entry and h-card on [http://www.marcus-povey.co.uk/ marcus-povey.co.uk]
* Eugen Busoiu marks up his web profile with h-card on [http://eugenbusoiu.com/#utm_source=microformats2&utm_medium=h-card&utm_campaign=Microformats eugenbusoiu.com]]
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* Kyle Mahan marks up his profile and notes with h-card and h-entry on [http://kylewm.com/ kylewm.com]
* Okinawan-lyrics marks up his blog posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* Emil Björklund marks up his blog posts with h-entry and h-card ([http://thatemil.com/blog/2013/09/16/webmentioning-adactio/ example])
* App.net rolled out support for h-card and h-entry on all profile pages and permalink pages as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* Brett Comnes marks up his posts with h-entry and h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like ([http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his posts up with h-card and h-entry, as well as draft u-in-reply-to and experimental u-like properties ([http://sandeep.io/101 example])
* Laurent Eschenauer marks up his posts with h-entry ([http://eschnou.com/entry/first-autonomous-flight-of-my-nodecopter-62-24992.html example])
* Tom Morris marks up his posts using h-entry ([http://tommorris.org/posts/8417 example])
* Sinolandquality marks up some of their content using h-feed and h-entry on [http://www.sinolandquality.com/Blog/?page_id=3516&utm_content=buffere4d40&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer sinolandquality.com]
* [http://www.w3.org/conf/ W3Conf 2013] uses h-event for the main event, and h-card for all the speakers and notable attendees. The h-cards make particularly good use of implied name, url, and photo properties.
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry and h-as-*
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Tom Morris uses h-card and [[XFN]] to markup [http://tommorris.org/pages/blogroll his blogroll].
* Aaron Parecki uses h-card to markup both authorship and references to people in his notes permalinks, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-card, h-event, and h-entry on his home page, as well as h-entry on all post permalinks, e.g. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], with [[rel-prev]]/[[rel-next]] (if applicable) to indicate prev/next posts, and with [[rel-author]] to his home page with canonical hCard to indicate authorship.
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-card on his home page, h-card, h-entry and XFN markup on his [http://waterpigs.co.uk/notes notes page].
** 2013-01-25 Barnaby Walters: <cite>[http://waterpigs.co.uk/articles/experimental-markup Experimental Markup]</cite> - describes how he's using microformats2 vocabularies: <code>h-adr</code>, <code>h-card</code>, <code>h-entry</code>, <code>h-event</code>, <code>h-geo</code>, <code>h-review</code>, and experimental vocabularies: <code>h-feed</code> (embedded for update histories), [[activity-streams]] objects <code>h-as-article</code>, <code>h-as-collection</code>, <code>h-as-note</code>, <code>h-as-update</code>, as well as experimental properties: <code>u-alternate</code> and <code>u-as-downstream-duplicate</code> (links to POSSE copies), and <code>u-in-reply-to</code> (links to content that the posts are in reply to).
* [http://tantek.com/presentations/2012/06/microformats microformats.org at 7 years] presentation with h-event and h-card markup for people and organizations.
* [http://tantek.com/presentations/2012/06/pdf2012-indieweb.html Rise of the Indie Web hCards] (from Personal Democracy Forum 2012 #pdf12 #pdf2012) has [[microformats-2]] h-calendar and h-card markup
* WebMaker by Mozilla has [[microformats-2]] h-calendar and h-card on event search (e.g. [https://webmaker.org/en-US/events/near/?lat=45.5234515&lng=-122.6762071 search near Portland Oregon]) and event pages (e.g. [https://webmaker.org/en-US/events/192f56eb9/ IndieWebCamp 2012]).[https://twitter.com/microformats/status/212207925643587585]
* WebFWD by Mozilla has [[microformats-2]] h-card markup on [https://webfwd.org/about/experts/ experts] and [https://webfwd.org/about/team/ team] pages
* [http://indiewebcamp.com IndieWebCamp] has [[microformats-2]] h-event markup with nested h-cards for the organizers and the location.
* [https://wiki.mozilla.org/Events Mozilla Events] page has [[microformats-2]] h-event markup with attendees marked up with h-card.
* The [http://pdx.esri.com/blog/2013/10/17/introducing-mapattack/ Esri PDX Blog] has h-entry markup on all blog posts (as of 2013-10-19), and h-product markup on [http://pdx.esri.com/projects/terraformer/ project pages]

=== offline ===
* spreadly marks up share permalink pages with h-entry, as well as minimal h-cards and experimental p-like properties ([http://my.spread.ly/share/51d570bc09e9486562000002 example])

== Implementations ==
{{new}} Test your microformatted web page with:
=== Live Textarea Input ===
Use any of these to enter HTML+microformats2 markup and see the parsed result!
* http://glennjones.net/tools/microformats/
* https://pin13.net/mf2/ (where it says "Microformats Parser")
* https://kylewm.com/services/mf2

=== Blogging tools ===
* '''Storytlr''' parses the 'target' from [http://indiewebcamp.com/pingback pingbacks] for [https://github.com/storytlr/storytlr/blob/master/protected/application/public/controllers/PingbackController.php#L63 h-entry with properties and nested h-card] for information to automatically display in the [http://eschnou.com/entry/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html comments section on a post].

=== Converters ===

* '''[https://github.com/snarfed/granary granary]''' is a library and REST API that converts between silo APIs, [[ActivityStreams]], [[microformats2]], and Atom (all directions). Supported silos include Facebook, Twitter, Instagram, Google+, and Flickr. Users include [http://brid.gy/ Bridgy], [http://reader.kylewm.com/ Woodwind], and [https://facebook-atom.appspot.com/ facebook-atom] and [https://twitter-atom.appspot.com/ twitter-atom], among others.

* '''[http://pipes.yahoo.com/pipes/pipe.info?_id=afc5568b4e8643bfb05436b1caaf91bc microformats to RSS]''' - a Yahoo! pipe that converts a URL containing an [[h-feed]] containing h-entries, into an [[RSS]] feed ([http://waterpigs.co.uk/notes/4SeNi5/ 2013-10-21 blog post announcing])

=== Parsers ===
Parsers, open source libraries, in alphabetical order by programming language:

==== Parsers in production ====
The following parsers are of very high quality, in active development, and use on live sites on the web in production.

===== Javascript =====
* '''microformat-node''' Node.js microformats2 parser
** github open source: https://github.com/glennjones/microformat-node
** test suite: https://github.com/microformats/tests
** blog post: http://glennjones.net/2013/01/brand-new-microformats-2-parser/
** live: http://glennjones.net/tools/microformats/
* '''microformat-shiv''' - cross browser javascript microformats 2 parser which can also be used in browser extensions.
** http://microformatshiv.com/
** github open source: https://github.com/glennjones/microformat-shiv

===== PHP =====
* '''<span id="php-mf2">php-mf2</span>''' - PHP microformats2 parser
** github open source: https://github.com/indieweb/php-mf2
** Packagist: https://packagist.org/packages/mf2/mf2
** live:
*** textarea entry: http://waterpigs.co.uk/php-mf2/
*** URL and textarea entry: https://pin13.net/mf2/

===== Python =====
* '''mf2py''' Python microformats2 parser
** main entry: [[mf2py]]
** github open source: https://github.com/tommorris/mf2py
** live:
*** URL entry: [https://mf2py.herokuapp.com/ mf2py.herokuapp.com]
*** textarea entry: https://kartikprabhu.com/connection/mfparser
*** another textarea: http://www.unmung.com/?html=
*** URL and/or textarea: https://kylewm.com/services/mf2

==== Development parsers ====
The following parsers are in-development and have key microformats2 functionality yet are incomplete, not fully tested, or have other limitations. Contributions welcome!

===== Elixir =====
* '''ckruse/microformats-elixir''' Elixir microformats2 parser
** github open source: https://github.com/ckruse/microformats2-elixir

===== Go =====
* '''andyleap/microformats''' Golang microformats2 parser
** github open source: https://github.com/andyleap/microformats
** live textarea entry: http://mf2.vendaria.net

===== Haskell =====
* '''myfreeweb/microformats2-parser''' Haskell microformats2 parser
** github open source: https://github.com/myfreeweb/microformats2-parser
** live textarea entry: https://unrelenting.technology/mf2/

===== Java =====
* '''Apache Any23''' a library, a web service and a command line tool that extracts structured data in RDF format from a variety of Web documents. Supports Microformats1 and 2.
** Download recent release: http://any23.apache.org/download.html
** live: http://any23-vm.apache.org/
** source: http://any23.apache.org/build-src.html
* '''mf2j''' An early-stage Java microformats2 parser
** github open source: https://github.com/kylewm/mf2j
** live: https://mf2j.herokuapp.com/?url={http://example.com}

===== Ruby =====
* '''G5/microformats2''' Ruby microformats2 parser
** github open source: https://github.com/G5/microformats2

== Presentations ==
Presentations about microformats2:
* 2013-01-24 <cite>[http://waterpigs.co.uk/presentations/microformats-2/ Microformats 2]</cite> presentation by [[User:Barnabywalters|Barnaby Walters]] at the [[events/2013-01-24-exeter-web-meetup|Exeter Web Meetup]] in Devon, UK.
* 2012-09-21 <cite>[http://tantek.com/presentations/2012/09/microformats2/ microformats2 & bits of HTML5: The Evolution Of Web Data]</cite> presentation by [[User:Tantek|Tantek Çelik]] ([http://twitter.com/t @t]) at [[events/2012-09-21-refreshlx|RefreshLX]] in Lisbon, Portugal.
* 2012-07-21 <cite>[http://tantek.com/presentations/2012/07/html5-uf2/ HTML5 and microformats2: The Evolution Of Web Data]</cite> presentation by [[User:Tantek|Tantek Çelik]] ([http://twitter.com/t @t]) at [[events/2012-07-21-cascadesf|Innovators of the Web conference]] in San Francisco, CA.
* 2012-07-14 <cite>[http://tantek.com/presentations/2012/07/html5-microformats2/ HTML5 and microformats2: The Evolution Of Web Data]</cite> presentation by [[User:Tantek|Tantek Çelik]] ([http://twitter.com/t @t]) at [[events/2012-07-14-open-web-camp-4|Open Web Camp IV]] in San Jose, CA.

== Testimonials ==
* <blockquote class="twitter-tweet">To prove the web standards community can come up with better standards than the SE’s, compare this: http://microformats.org/wiki/microformats-2 with schema . org — Joost de Valk (@yoast) [https://twitter.com/yoast/status/298907685452124160 2013-02-05 13:35]</blockquote>
* <blockquote class="twitter-tweet">... I’m hoping SE’s will pick up microformats2. It’s SO much cleaner. — Joost de Valk (@yoast) [https://twitter.com/yoast/status/298911287117758464 2013-02-05 13:49]</blockquote>
* <blockquote class="twitter-tweet">... But damn Microformats2 are sexy. — Joost de Valk (@yoast) [https://twitter.com/yoast/status/298912179292344320 2013-02-05 13:53]</blockquote>

== About This Brainstorm ==
The rest of this page is a brainstorm currently written in narrative / exploratory format, that is, acknowledging the success that microformats have had, why so, and then a walk through of known issues with microformats in general along with iteration of ways to address said issues, ending up with the current microformats 2 design as a conclusion.

The proposals build on each other resulting in a solution that addresses the vast majority of general issues. The proposed changes merit a major version number increment, hence microformats 2.

This mathematical proof/derivation style is used to explicitly encourage understanding (and double-checking) of the rational steps taken in the development of microformats 2. Reasons are documented, sometimes along with alternatives considered (and reasons for rejection of those alternatives).

When the microformats 2 brainstorm has evolved sufficiently to demonstrate some degree of stability, usability, and implementability, it will be rewritten in a more declarative specification style, and this narrative/derivation will be archived to a background development page for historical purposes.

— [[User:Tantek|Tantek]]

== Background ==

2004: In early February microformats were introduced as a concept at eTech, and in September [[hCard]] and [[hCalendar]] were proposed at FOO Camp.

2010:
* 34% of webdevs use microformats ([http://www.webdirections.org/sotw10/markup/#semantics 2010 State of Web Development survey])
* 1.88 billion hCards (per [[Yahoo]] SearchMonkey)
* 36 million hCalendar events (ibid)

* XFN -> Social Graph API -> Web as Social Network / Address Book

== Addressing Issues ==
=== AUTHORS and PUBLISHING ===
Authors and publishers are perhaps the most important constituency in the microformats community. There are more of them than there are developers, programmers, parsers, etc. and they're the ones that solved the chicken-egg problem by publishing microformats even before tools were available for consuming them.

Therefore we must first address author/publisher general issues with microformats.

==== can we make the simplest case simpler ====
Issue: '''How can we make it easier for authors to publish microformats?'''

Currently the simplest hCard:
<source lang=html4strict>
<span class="vcard">
<span class="fn">
Chris Messina
</span>
</span>
</source>

requires 2 elements (nested, with perhaps at least one being pre-existing), and 2 class names.

Web authors/designers are used to the simplicity of most HTML tags, e.g. to mark up a heading:

<source lang=html4strict>
<h1>Chris Messina</h1>
</source>

requires just 1 element.

[http://zeldman.com/ Jeffrey Zeldman] pointed out this apparent perceived incremental complexity (2 elements vs 1) during a microformats workshop in 2009 in New York City.

'''How can we make microformats just as easy?'''

'''Proposal: allow root class name only.'''

This would enable:

<source lang=html4strict>
<h1 class="vcard">Chris Messina</h1>
</source>

requiring only 1 class name for the simplest case.

==== renaming for usability ====
Otherwise known as, choosing one form of consistency over another.

'''Can we do even better?'''

One of the most common questions asked about hCard is:

[[hcard-faq#Why_does_hCard_use_vcard_as_the_root_class_name|Why does hCard use vcard as the root class name?]]

This slight inconsistency between the name of the format and the name of the root class name consistently causes confusion in a large percentage of newcomers to microformats.
* See [[issues#hcard-vs-vcard-name]] for details/links.

Though in microformats we believe very strongly in the [[principle]] of [[reuse]], we have to admit that in this case experience/evidence has shown that this may be a case where we re-used something too far beyond it's original meaning. Thus:

'''Proposal: use root class name "hcard" instead of "vcard" for future hCards.'''

This would result in:

<source lang=html4strict>
<h1 class="hcard">Chris Messina</h1>
</source>

making the simple case even simpler:

Just 1 additional class name, named the same as the format you're adding. Think hCard, markup class="hcard".

At a minimum for compatibility we should document that parsers should accept "hcard" as an alternative to "vcard" as the root class name for hCard 1.0, and similarly for hCalendar 1.0: "hcalendar" in addition to "vcalendar", "hevent" in addition to "vevent".

However, for [[microformats-2]] we are going to distinguish root class names further by using an "h-" prefix (e.g. "h-card"). Read on to understand why.

==== simplifying to only needing one element ====
It's very important for the simple case to be as simple as possible, to enable the maximum number of people to get started with minimum effort. (The idea of using a single class name for a microformat was proposed by Ryan Cannon in 2006 specifically [[hcard-implied|for hCard]], and rediscovered by [[User:Tantek|Tantek]] in 2010 and subsequently generalized to all microformats.)

From there on, it's ok to require incremental effort for incremental return.

E.g. to add any additional information about a person, add explicit property names.

'''How does this simple root-only case work?'''

* root class name reflects name of the microformat
* every microformat must require at most 1 property (preferably 0)
** admit that requiring a field in an application just results in noise (the 90210 problem - apps which require zip code get lots of false 90210 entries), and specify that any application use cases which appear to "require" specific properties must instead define how to imply sensible defaults for them.
* when only a root class name is specified, imply the entire text contents of the element as the value of the primary property of the microformat. e.g.
** "hcard" implies "fn"
** hcalendar event - "hevent" - implies "summary"
** "hreview" implies "summary"
** "hentry" implies "entry-summary" (perhaps collapse into "summary" - in practice they're not sufficiently semantically distinct to require separate property names)
** '''OR''' instead of making the one implied property be vocabulary specific, introduce a new generic (applicable to all vocabularies) 'p-name' property (subsuming hCard's 'fn'). See [[microformats-2-brainstorming#further_simplifications|microformats 2 brainstorming: further simplifications]] for latest thoughts along these lines, including the following specific mark-up implied generic properties across all microformats (based on existing published markup use-cases)
*** 'p-name'
*** 'u-url'
*** 'u-photo'

==== flat sets of properties ====
'''What more can we simplify about microformats?'''

Numerous individuals have provided the feedback that whenever there is more than one level of hierarchy in a microformat, many (most?) developers get confused - in particular Kavi Goel of Google / Rich Snippets provided this feedback at a microformats dinner. Thus depending on multiple levels of hierarchy is likely resulting in a loss of authorability, perhaps even accuracy as confusion undoubtedly leads to more errors. Thus:

'''Proposal: simplify all microformats to flat sets of properties. '''

What this means:
* all microformats are simply an object with a set of properties with values.
* no more subproperties- drop the notion of subproperties.
* use composition of multiple microformats for any further hierarchy, e.g. the "location" of an hCalendar event can be an hCard, or the "agent" of one hCard can be another hCard.

For example for hCard this would mean the following specific changes to keep relevant functionality:
* drop "n", promote all "n" subproperties to full properties
** given-name, family-name, additional-name, honorific-prefix, honorific-suffix
* treat "geo" as a nested microformat
* treat "adr" as a nested microformat (what to do about adr's "type"?)
* treat "org" as a flat string and drop "organization-name" and "organization-unit" (in practice rarely used, also not revealed or ignored in contact management user interfaces - e.g. Address Book)

Example: add a middle initial to the previous example Chris Messina's name, and markup each name component:

<source lang=html4strict>
<h1 class="hcard">
<span class="fn">
<span class="given-name">Chris</span>
<abbr class="additional-name">R.</abbr>
<span class="family-name">Messina</span>
</span>
</h1>
</source>

Note:
# use of an explicit span with "fn" to markup his entire formatted name
# use of the abbr element to explicitly indicate the semantic that "R." is merely an abbreviation for his additional-name.

==== distinguishing properties from other classes ====
Current microformats properties re-use generic terms like "summary", "photo", "updated" both for ease of use and understanding.

However, through longer term experience, we've seen sites that accidentally drop (or break) their microformats support (e.g. Upcoming.org, Facebook) because web authors sometimes rewrite all their class names, and either are unaware that microformats were in the page, or couldn't easily distinguish microformats property class names from other site-specific class names.

This issue has been reported by a number of web authors.
* See: [[issues#class-collisions]]

Thus microformats 2 uses ''prefixes'' for property class names, e.g.:
* '''p-summary''' instead of ''summary''
* '''u-photo''' instead of ''photo''
* '''dt-updated''' instead of ''updated''

Such prefixing of all microformats class names was first suggested by Scott Isaacs of Microsoft to Tantek on a visit to Microsoft sometime in 2006/2007, but specifically aimed at making microformats easier to parse. At the time the suggestion was rejected since microformats were focused on web authors rather than parsers.

However, since experience has shown that distinguishing property class names is an issue for '''both web authors and parser developers''', this is a key change that microformats 2 is adopting. See the next section for details.

=== COMMUNITY and TOOLS ===
The second most important constituency in the microformats community are the developers, programmers, tool-makers.

A non-trivial number of them have been sufficiently frustrated with some general issues with microformats that they've done the significant extra work to support very different and less friendly alternatives (microdata, RDFa). Based on this real-world data (market behavior), it behooves us to address these general issues with microformats for this constituency.

==== existing microformats parsing requirements ====
COMMUNITY and TOOLS (that) USE MICROFORMATS
* parser / parsing
* structured
* getting the data out
* json - 1:1 mapping

[[parsing]] microformats currently requires
# a list of root class names of each microformat to be parsed
# a list of properties for each specific microformats, along with knowledge of the type of each property in order to parse their data from potentially different portions of the HTML markup
# some number of format-specific specific rules (markup/content optimizations)

This has meant that whenever a new microformat is drafted/specificied/adopted, parsers need to updated to handle it correctly, at a minimum to parse them when inside other microformats and avoid errantly implying properties from one to the other (containment, [[mfo]] problem).

==== naming conventions for generic parsing ====
I think there is a fairly simple solution to #1 and #2 from the above list, and we can make progress towards minimizing #3. In short:

'''Proposal: a set of naming conventions for microformat root class names and properties that make it obvious when:'''
* a class name represents a microformat root class name
* a class name represents a microformat property name
* a class name represents a microformat property that needs special parsing (specific type of property).

In particular - derived from the real world examples of existing proven microformats (rather than any abstraction of what a schema should have)
* '''"h-*" for root class names''', e.g. "h-card", "h-event", "h-entry"
** The 'h-' prefix is based on the existing microformats naming pattern of starting with 'h'.
* '''"p-*" for simple (text) properties''', e.g. "p-fn", "p-summary"
** vocabulary generic parsing, element text in general, treat certain HTML element/attribute combination as special and use those first, e.g. img/alt, abbr/title.
** The 'p-' prefix is based on the word "property" starting with 'p'.
* '''"u-*" for URL properties''', e.g. "u-url", "u-photo", "u-logo"
** special parsing required: prefer a/href, img/src, object/data etc. attributes to element contents.
** The 'u-' prefix is based on URL/URI starting with the letter 'u', which is the type of most of these related properties.
* '''"dt-*" for datetime properties''', e.g. "dt-start", "dt-end", "dt-bday"
** special parsing required: [[value-class-pattern]], in particular separate date time value parsing for better human readabillity / DRY balance.
** The 'dt-' prefix is based on "date time" having the initials "dt" and the preponderance of existing date time properties starting with "dt", e.g. dtstart, dtend, dtstamp, dtreviewed.
* '''"e-*" for element tree properties''' where the entire contained element hierarchy is the value, e.g. "e-content" (formerly "entry-content") for [[hAtom]]. The 'e-' prefix can also be mnemonically remembered as "element tree", "embedded markup", or "encapsulated markup".
** special parsing required: follow the [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#serializing-html-fragments HTML spec: Serializing HTML Fragments algorithm] to create a serialization.

This provides a simpler transition/education story for existing microformats authors/publishers:
* "h*" to "h-*", "dt*" to "dt-*", url-like properties to "u-*", entire embedded markup to "e-*", and "p-*" for all "plain text" properties.

See [[microformats-2-prefixes]] for further thoughts and discussions on these and other class prefixes.

Example: taking that simple heading hCard example forward:

<source lang=html4strict>
<h1 class="h-card">Chris Messina</h1>
</source>

As part of microformats 2 we would immediately define root class names and property names for all existing microformats and drafts consistent with this naming convention, and require support thereof from all new implementations, as well as strongly encouraging existing implementations to adopt the simplified microformats 2 syntax and mechanism. Question: which microformats deserve explicit backward compatibility?

As a community we would continue to use the microformats [[process]] both for researching and determining the need for new microformats, and for naming new microformat property names for maximum re-use and interoperability of a shared vocabulary.

If it turns out we need a new property type in the future, we can use one of the remaining single-letter-prefixes to add it to microformats 2. This would require updating of parsers of course, but in practice the number of different types of properties has grown very slowly, and we know from other schema/programming languages that there's always some small limited number of scalar/atomic property types that you need, and using those you can create compound types/objects that represent richer / more complicated types of data. See [[microformats-2-prefixes]] for documentation of existing single-letter class name prefixes in practice.

=== ADVANTAGES ===
This has numerous advantages:
* '''better maintainability''' - much more obvious to web authors/designers/publishers which class names are for/from microformats.
* '''no chance of collision''' - for all practical purposes with existing class names and thus avoiding any need to add more complex CSS style rules to prevent unintended styling effects.
* '''simpler parsing''' - parsers can now do a simple stream-parse (or in-order DOM tree walk) and parse out '''all''' microformat objects, properties, and values, without having to know anything about any specific microformats.
* '''separation of syntax and vocabulary''' - by abstracting microformats 2 syntax independent of any vocabulary, it allows and encourages development of shared vocabularies that can work in alternative syntaxes.

More examples: here is that same heading example with name components:

<source lang=html4strict>
<h1 class="h-card">
<span class="p-fn">
<span class="p-given-name">Chris</span>
<abbr class="p-additional-name">R.</abbr>
<span class="p-family-name">Messina</span>
</span>
</h1>
</source>

with a hyperlink to Chris's URL:

<source lang=html4strict>
<h1 class="h-card">
<a class="p-fn u-url" href="http://factoryjoe.com/">
<span class="p-given-name">Chris</span>
<abbr class="p-additional-name">R.</abbr>
<span class="p-family-name">Messina</span>
</a>
</h1>
</source>

=== COMPATIBILITY ===

microformats 2 is backwards compatible in that in permits content authors to markup with both old and new class names for compatibility with old tools.

Here is a simple example:

<source lang=html4strict>
<h1 class="h-card vcard">
<span class="fn">Chris Messina</span>
</h1>
</source>

a microformats 2 parser would see the class name "h-card" and imply the one required property from the contents, while a microformats 1.0 parser would find the class name "vcard" and then look for the class name "fn". no data duplication is required. this is a very important continuing application of the <abbr title="don't repeat yourself">DRY</abbr> [[principle]].

And the above hyperlinked example with both sets of class names:

<source lang=html4strict>
<h1 class="h-card vcard">
<a class="p-fn u-url n fn url" href="http://factoryjoe.com/">
<span class="p-given-name given-name">Chris</span>
<abbr class="p-additional-name additional-name">R.</abbr>
<span class="p-family-name family-name">Messina</span>
</a>
</h1>
</source>

=== VENDOR EXTENSIONS ===

(this section was only discussed verbally and not written up during discussions - capturing here as it is topical)

Proprietary extensions to formats have typically been shortlived experimental failures with one big recent exception.

Proprietary or experimental CSS3 property implementations have been very successful.

There has been much use of border radius properties and animations/transitions which use CSS properties with vendor-specific prefixes like:

* -moz-border-radius
* -webkit-border-radius

etc.

Note that these are merely string '''prefixes''', not bound to any URL, and thus not namespaces in any practical sense of the word. This is quite an important distinction, as avoiding the need to bind to a URL has made them easier to support and use.

This use of vendor specific CSS properties has in recent years allowed the larger web design/development/implementor communities to experiment and iterate on new CSS features while the features were being developed and standardized.

The benefits have been two-fold:
* designers have been able to make more attractive sites sooner (at least in some browsers)
* features have been market / real-world tested before being fully standardized, thus resulting in better features

Implementers have used/introduced "x-" prefixes for IETF MIME/content-types for experimental content-types, MIME parameter extensions, and HTTP header extensions, per RFC 2045 Section 6.3, RFC 3798 section 3.3, and [https://secure.wikimedia.org/wikipedia/en/wiki/List_of_HTTP_header_fields#Common_non-standard_headers Wikipedia: HTTP header fields - non-standard headers] (could use RFC reference instead) respectively, like:

* application/x-latex (per [https://secure.wikimedia.org/wikipedia/en/wiki/Internet_media_type#Type_x Wikipedia Internet media type: Type x])
* x-spam-score (in email headers)
* X-Pingback (per [http://en.wikipedia.org/wiki/Pingback Wikipedia:Pingback])

Some standard types started as experimental "x-" types, thus demonstrating this experiment first, standardize later approach has worked for at least some cases:

* image/x-png (standardized as image/png, both per [http://tools.ietf.org/html/rfc2083 RFC2083])

There have been times when specific sites have wanted to extend microformats beyond what the set of properties in the microformat, and currently lack any '''experimental''' way to do so - to try and see if a feature (or even a whole format) is interesting in the real world before bothering to pursue researching and walking it through the microformats process. Thus:

'''Proposal:'''
* '*-x-' + '-' + meaningful name for root and property class names
** where "*" indicates the single-character-prefix as defined above
** where "x" indicates a literal 'x' for an experimental extension OR
** OR "x" indicates a vendor prefix (more than one character, e.g. like CSS vendor extension abbreviations, or some stock symbols, avoiding first words/phrases/abbreviations of microformats properties like dt-)
** e.g.
** "h-bigco-one-ring" - a hypothetical "bigco" vendor-specific "one-ring" microformat root class name.
** "p-goog-preptime" - to represent [http://www.google.com/support/webmasters/bin/answer.py?answer=173379 Google's "preptime" property extension] to [[hRecipe]] (aside: "duration" may be another property type to consider separate from "datetime" as it may be subject to different parsing rules.)
** "p-x-prep-time" - a possible experimental property name to be added to hRecipe upon consideration/documentation of real-world usage/uptake.

Background - this proposal is a composition of the following (at least somewhat) successful vendor extension syntaxes
* [http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords CSS 2.1 4.1.2.1 Vendor-specific extensions]
* IETF MIME/content-type "x-*" extensions per RFC 2045 Section 6.3. [http://en.wikipedia.org/wiki/Internet_media_type]
* IETF MIME experimental fields (e.g. x-spam-score)
* HTTP header extensions (e.g. x-pingback)
* note also [http://www.mnot.net/blog/2009/02/18/x- some critical thoughts from mnot]

=== USERS ===
Need more tools and interfaces that:
* publish
* copy/paste
* right-click on a microformat
* share
* search results

discussed some existing like: [[H2VX]] converts hCard to vCard, hCalendar to iCalendar

how would we re-implement Live Clipboard today, making it easier for publishers and developers?

=== SEE ALSO ===
* [[microformats2]]
* [[microformats2-brainstorming]] - moving more experimental / undeveloped / and rejected thoughts ideas here to simplify/progress *this* page further.
* [[microformats2-experimental-properties]] - listing experimental (-x- prefixed) properties and their use
* [[microformats2-prefixes]]
* [[microformats2-faq]]
* [[microformats2-parsing]]
* 2010-05-02 [[events/2010-05-02-microformats-2-0|microformats 2.0 discussion session at FOO East]]

parsers

2015-08-23T12:31:50Z

Myfreeweb: /* microformats2 parsers */ add the Haskell parser

<entry-title>Microformats Parsers</entry-title>
;shortlink
:http://ufs.cc/w/ufprs
This page lists libraries that consume, transform or convert microformats. This is only a partial list. If you know of other such tools for microformats, please add them and list what specific microformats they support. There is a separate page for [[validators]].

Alphabetical listing by programming language:

= microformats2 parsers =
{{main|microformats2#Parsers}}

These are modern and maintained [[microformats2]] parsers and are suitable for use in modern web applications.

== Go ==
* [https://github.com/andyleap/microformats andyleap/microformats] - Golang microformats2 parser
** live textarea entry: http://mf2.vendaria.net

== Haskell ==
* [https://github.com/myfreeweb/microformats2-parser myfreeweb/microformats2-parser] - Haskell microformats2 parser
** live textarea entry: https://unrelenting.technology/mf2/

== Java ==
* [https://github.com/kylewm/mf2j mf2j] - An early-stage Java microformats2 parser
* live: https://mf2j.herokuapp.com/?url={http://example.com}

== Javascript ==
=== Microformat Node ===
* [http://github.com/glennjones/microformat-node microformat-node] microformat-node is a microformat parser for node.js. It is built using a well tested JavaScript parsing engine which already powers a number of browser extensions. Supports microformat v1 and v2. Try it out at http://glennjones.net/tools/microformats/

=== Microformat Shiv ===
* [http://microformatshiv.com/ Microformat Shiv] The microformat shiv provides a simple to use JavaScript microformats parsing library. It can also be used in browser extensions and the web site has example code for Chrome, Firefox and Opera. Try it out http://microformatshiv.com/editor.html

== PHP ==
=== php-mf2 ===
* PHP generic microformats2 parser
** source: https://github.com/indieweb/php-mf2

== Ruby ==
* '''G5/microformats2''' Ruby microformats2 parser
** github open source: https://github.com/G5/microformats2

== Python ==
* [[mf2py]]
** on PyPI: [https://pypi.python.org/pypi/mf2py/]
** source: [https://github.com/tommorris/mf2py github.com/tommorris/mf2py]
** bleeding edge development: [https://github.com/kartikprabhu/mf2py github.com/kartikprabhu/mf2py]

= past parsers =
These are past parsers of classic microformats some of which have not been maintained.

They may be useful as starting points for developing additional microformats2 parsers.

== .Net ==
[http://ufxtract.com/ UfXtract] is an open source .Net microformats parser. It can parse microformats from URLs or HTML strings. The extracted data can be used directly in .Net or converted into JSON, JSON-P or XML. Currently Supports 16 microformats and can easily be extended with new definitions.

== More Java ==
* [[any23]] (Anything to Triples)] parses microformats into RDF triples: http://any23.apache.org
** '''MAINTAINED''' but '''[https://issues.apache.org/jira/browse/ANY23-207 not yet supporting Microformats2]''' (<-- help welcome! comment there.)

* [http://zwitserloot.com/org.microformats.hCard/ org.microformats.hCard] by Reinier Zwitserloot

== More Javascript ==
=== Sumo ===
* [http://www.danwebb.net/2007/2/9/sumo-a-generic-microformats-parser-for-javascript Sumo! A Generic Microformats Parser For JavaScript]

== Perl ==
=== Data::Microformat ===
* [http://search.cpan.org/~ussjoin/Data-Microformat-0.01/lib/Data/Microformat/hCard.pm Data::Microformat] is a CPAN module to parse and create hCard, adr, and geo.
** By Brendan O'Connor / Six Apart

=== HTML::Microformats ===
Perhaps we can capture and update this info on a page like [[perl-html-microformats-parser]].
[http://search.cpan.org/~tobyink/HTML-Microformats/ HTML::Microformats] is a CPAN module that has support for:
* input:
** rel: [[rel-enclosure]], [[rel-license]], [[rel-tag]], [[VoteLinks]], [[XFN]].
** class: [[adr]], [[figure]], [[geo]], [[hAtom]], [[hAudio]], [[User:TobyInk/hcalendar-1.1|hCalendar]], [[hCard]], [[hListing]], [[hNews]], [[hProduct]], [[hRecipe]], [[hResume]], [[hReview]], [[hReview-aggregate]], [[xFolk]], [[XMDP]], [[XOXO]].
*** highly experimental: [[measure]], [[species]].
** poshformats: [http://ocoins.info/ OpenURL COinS].
* output:
** RDF: RDF/XML, Turtle, N-Triples, RDF/JSON, etc.
** JSON
** domain specific: vCard (3.0, 4.0 and XML), iCalendar, Atom, KML.
* By [[User:TobyInk|Toby Inkster]].

Versions and releases notes:
* 2011-02-05 [http://microformats.org/discuss/mail/microformats-dev/2011-February/000667.html 0.102]
* 2010-12-22 0.101
* 2010-12-16 [http://microformats.org/discuss/mail/microformats-discuss/2010-December/013363.html 0.100]
* 2010-10-18 0.00_13
* 2010-06-25 0.00_12
* 2010-06-23 0.00_11
* 2010-05-13 0.00_10
* 2010-05-12 0.00_09
* 2010-04-29 0.00_08
* 2010-04-28 0.00_07
* 2010-04-16 [http://microformats.org/discuss/mail/microformats-dev/2010-April/000651.html 0.00_06]
* 2010-04-16 0.00_05
* 2010-03-20 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000647.html 0.00_04]
* 2010-03-09 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000642.html 0.00_03]
* 2010-02-28 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000641.html 0.00_02]
* 2010-02-24 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000640.html 0.00_01]
* 2010-02-20 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000639.html 0.00_00]
* see also the "Changes" file included in the CPAN distribution.

==== XML::Atom::Microformats ====

[http://search.cpan.org/~tobyink/XML-Atom-Microformats/ XML::Atom::Microformats] provides the same functionality for Atom. It finds microformats in Atom entry content elements.

===Swignition ===
* [http://buzzword.org.uk/swignition/ Swignition] is a parser for both “upper case Semantic Web” (RDF, RDFa) and “lower case semantic web” (microformats) technologies. It includes modules for exporting parsed data in a variety of formats, including RDF, vCard, iCalendar, Atom and KML.
** By Toby Inkster
** Active development has moved to HTML::Microformats (see above).

=== Text::Microformat ===
* Text::Microformat is a microformats parser hosted on [http://code.google.com/p/ufperl/ Google Code] that supports:
** [[hCard]], [[hCalendar]], [[rel-tag]]

== More PHP ==
=== XMFP ===
<span id="xmfp">[http://code.google.com/p/xmfp/ XMFP]</span> (eXtensible MicroFormats Parser for PHP 5) by [http://www.metonymie.com Emiliano Martínez Luque] is a set of PHP 5 classes providing a simple API for extracting Microformated Content either from a URI or a String representing HTML/XML. It can return the results as a PHP associative array, a JSON definition or an XML representation of the data. It supports most of the currently accepted microformats and can be easily extended to add new ones, it also has full support of the include pattern and provides basic validation of microformated data.

=== hKit Microformats Toolkit for PHP5 ===
[http://allinthehead.com/hkit hKit Microformats Toolkit for PHP5] as [http://allinthehead.com/retro/291/hkit-microformats-toolkit-for-php announced by Drew McLellan]. See also [[hkit|hKit on this wiki]].

===PHP Microformats parser===
[http://www.phpclasses.org/browse/package/3597.html Microformats parser] is a PHP package for extracting the microformats data embedded into HTML. The gathered data is stored as an xArray of objects - one for each microformat type container found. [http://malatestapunk-stuff.blogspot.com/2007/01/php-microformats-parser.html Announcement]. The parser supports most of the hCard (missing SOUND), hCalendar, hReview (missing item info; spec really needs some clarification) and rel elements, according to their respective specification on microformats Wiki.

===Transformr===
A Simple set of XSLT and PHP tools for Transforming Microformats Source [http://github.com/WebOrganics/TransFormr available from github] Live webservice available at [http://microform.at/ microform.at].

=== hCard Validator ===
[http://code.google.com/p/hcardvalidator/ Source code] of the [http://hcard.geekhood.net/ hCard Validator] contains XSLT and PHP code for hCard and include microformats.

=== ARC2 ===
[http://arc.semsol.org/ ARC2] is a semantic web toolkit which includes support for hCard, adr, geo, XFN, hCalendar, hAtom, hResume, hReview, xFolk, rel-license and rel-tag. It's tri-licensed under the GPL 2 and 3, and the W3C Software licence.

== Python ==
===AUMP===
* [http://aump.googlecode.com AUMP] is a parser written by David Janes. It supports hCard, hCalendar, hAtom, hReview and hListing.
** Uses Python's [http://docs.python.org/library/xml.dom.minidom.html xml.dom.minidom] after cleaning input through [http://www.w3.org/People/Raggett/tidy/ HTML Tidy].

===Microtron===
{{main|Microtron}}
* [[Microtron]] is a general-purpose microformat parser/transformer.

It can operate on the definition file included in [[Optimus]], making it a close replacement for certain tasks, and can easily be extended with new formats without modifying the source. The primary advantages are speed (> 100x faster that [[Optimus]] for some operations), simplicity (single file) and small code size (currently < 150 lines).

=== python-hcalendar ===
[http://pypi.python.org/pypi/python-hcalendar/0.1dev python-hcalendar] is a basic hCalendar parser.

== More Ruby ==
===Prism ===
* [[Prism]]
** by [[implementors#Mark_Wunsch|Mark Wunsch]]
** Library and command line tool for parsing POSH/Microformats
** Uses the [http://nokogiri.org/ Nokogiri] HTML, XML, SAX, and Reader parser

=== mofo ruby microformats parser===
* [http://mofo.rubyforge.org/ mofo], [http://groups.google.com/group/mofo-rb mofo Google Group], [http://github.com/defunkt/mofo/tree/master GitHub repository]
** by [[implementors#Chris Wanstrath|Chris Wanstrath]]
** Uses the [http://wiki.github.com/why/hpricot Hpricot] HTML/XML parser

=== Microformat Parser for Ruby ===
* [http://blog.labnotes.org/2005/11/20/microformat-parser-for-ruby/ Microformat Parser for Ruby]
** by [[implementors#Assaf Arkin|Assaf Arkin]]

=== uformats ===
* [http://rubyforge.org/projects/uformats uformats]

=== scrAPI ===
* [http://rubyforge.org/projects/scrapi scrAPI]

== XSLT ==
===Optimus===
* [[Optimus]] is open source XSLT that parses microformats, converts them into JSON or XML, and validates them too.

===X2V===
* [[X2V]] is [http://hg.microformats.org/ open source XSLT for extracting microformats].
** by Brian Suda

== editing this page ==
For now, this page ''copies'' (rather than ''moves'') information from the existing [[implementations | Implementations]] page.

== see also ==
* [[implementations]]
* [[implementors]]
* [[open-source]]
* [[user-interface]]
* [[validators]]

microformats2-experimental-properties

2015-08-22T20:31:28Z

Myfreeweb: /* Usage */ add unrelenting.technology to pronoun usage

== h-as-* ==
ActivityStreams-based post types, usually done in combination with h-entry.

=== Usage ===

* [http://glennjones.net/ glennjones.net] ([http://glennjones.net/notes/2015-07-11 example: h-as-note])

Formerly:
* tantek.com - used to (~2014) use h-as-article and h-as-note but decided this type of explicit typing was unnecessary from a format perspective so dropped them. [[User:Tantek|Tantek]] 19:52, 11 July 2015 (UTC)

== h-x-username ==

=== Usage ===

* [http://glennjones.net/ glennjones.net] ([http://glennjones.net/notes/2015-07-11 example])
* [http://tantek.com/ tantek.com] ([http://tantek.com/2015/191/t1/indiewebcamp-pre-party example])

how is this different from [[h-card]]'s p-nickname ? [[User:Kevin Marks|Kevin Marks]]

== p-x-dietary-preference ==

For dietary preferences (vegetarian, vegan etc.) - the intention is to help event organisers organise catering by aggregating together the dietary preferences of attendees.

=== Suggested values ===
* ovo-lacto vegetarian
* lacto vegetarian
* ovo vegetarian
* vegan
* pescatarian
* omnivore
* gluten-free
* lactose-free

=== Usage ===
* [https://tommorris.org/ tommorris.org]

== p-x-pronoun-* ==

Properties to identify a user's preferred pronouns

; p-x-pronoun-nominative: the user's preferred nominative pronoun (e.g. he, she, they)
; p-x-pronoun-oblique: the user's preferred oblique pronoun (e.g. him, her, them)
; p-x-pronoun-possessive: the user's preferred possessive pronoun (e.g. his, hers, theirs)

=== Usage ===

* [https://waterpigs.co.uk/ waterpigs.co.uk]
* [https://unrelenting.technology/ unrelenting.technology]

== p-x-sexual-orientation ==

For when we eventually build the open web dating service.

;Suggested values:
:* straight or heterosexual
:* bisexual
:* pansexual
:* gay or lesbian or homosexual
:* asexual

=== Usage ===
* [https://tommorris.org/ tommorris.org]

microformats2

2015-08-22T20:17:39Z

Myfreeweb: /* Haskell */ add link to live textarea entry

<entry-title>microformats 2</entry-title>
Welcome to the microformats2 home page.

== Summary ==
Microformats2 is the simplest way to markup structured information in HTML. Microformats2 improves ease of use and implementation for <em>both</em> authors (publishers) and developers ([[microformats2-parsing|parser]] implementers).

Microformats2 replaces and supersedes both classic microformats, as well as incorporates lessons learned from [[microdata]] and [[RDFa]].

=== simple microformats 2 examples ===
Here are a few simple microformats2 examples along with canonical [[JSON]].

==== person example ====
* Simple person reference:
<source lang=html4strict>
<span class="h-card">Frances Berriman</span>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Frances Berriman"]
}
}]
}
</source>

----

==== hyperlinked person ====
* Simple hyperlinked person reference
<source lang=html4strict>
<a class="h-card" href="http://benward.me">Ben Ward</a>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Ben Ward"],
"url": ["http://benward.me"]
}
}]
}
</source>

----

==== hyperlinked person image ====
* Simple hyperlinked person image
<source lang=html4strict>
<a class="h-card" href="http://rohit.khare.org/">
<img alt="Rohit Khare"
src="https://s3.amazonaws.com/twitter_production/profile_images/53307499/180px-Rohit-sq_bigger.jpg" />
</a>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Rohit Khare"],
"url": ["http://rohit.khare.org"],
"photo": ["https://s3.amazonaws.com/twitter_production/profile_images/53307499/180px-Rohit-sq_bigger.jpg"]
}
}]
}
</source>

Additional simple cases details in [[microformats-2-implied-properties]].

----

==== detailed person example ====
* More detailed person
<source lang=html4strict>
<div class="h-card">
<img class="u-photo" alt="photo of Mitchell"
src="https://webfwd.org/content/about-experts/300.mitchellbaker/mentor_mbaker.jpg"/>
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="u-url"
href="https://twitter.com/MitchellBaker"
>@MitchellBaker</a>)
<span class="p-org">Mozilla Foundation</span>
<p class="p-note">
Mitchell is responsible for setting the direction and scope of the Mozilla Foundation and its activities.
</p>
<span class="p-category">Strategy</span>
<span class="p-category">Leadership</span>
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"photo": ["https://webfwd.org/content/about-experts/300.mitchellbaker/mentor_mbaker.jpg"],
"name": ["Mitchell Baker"],
"url": [
"http://blog.lizardwrangler.com/",
"https://twitter.com/MitchellBaker"
],
"org": ["Mozilla Foundation"],
"note": ["Mitchell is responsible for setting the direction and scope of the Mozilla Foundation and its activities."],
"category": [
"Strategy",
"Leadership"
]
}
}]
}
</source>

----
Notes:
# The JSON <code>"type"</code> uses the full microformat root class name (e.g. <code>"h-card"</code>) for consistent identification.
# all properties are optional and syntactically plural with parsed values provided in document order; particular microformats (and applications there-of) may apply specific/singular semantics to first value of a property.

=== microformats2 design ===
microformats2 has the following key design aspects:
# '''Prefixes for class names.''' Class names used for microformats use prefixes that start with with <code>'h-' 'p-' 'u-' 'dt-', 'e-'</code>. These are '''syntax independent from vocabularies''', which can then be developed separately.
#* 'h-*' for root class names, e.g. 'h-card'
#* 'p-*' for simple (text) properties, e.g. 'p-name'
#* 'u-*' for URL properties, e.g. 'u-photo'
#* 'dt-*' for date/time properties, e.g. 'dt-bday'
#* 'e-*' for embedded markup properties, e.g. 'e-note'. See [[microformats2#naming_conventions_for_generic_parsing|prefix naming conventions]] for more details.
# '''Flat sets of optional properties.''' All microformats consist of a root, and a collection of properties. Hierarchical data is represented with nested microformats, typically as property values themselves. Properties are all optional and potentially multivalued (applications needing a singular semantic may use first instance).
# '''Single class markup for common uses.''' Common simple markup patterns require only a single microformat root class name, which parsers use to find a few generic properties: <code>name, url, photo</code>. The simple microformats2 examples above demonstrate these.

Parsing details for each of these (including how to generate canonical JSON) are specified step-by-step in the:
* '''[[microformats2-parsing|microformats2 parsing specification]]'''

== v2 vocabularies ==
Status: '''<span id="draft_v2_vocabularies">draft</span>'''. Please review and provide feedback in [[IRC]].
* [[h-adr]]
* [[h-card]]
* [[h-entry]]
* [[h-event]]
* [[h-feed]]
* [[h-geo]]
* [[h-item]]
* [[h-listing]]
* [[h-product]]
* [[h-recipe]]
* [[h-resume]]
* [[h-review]]
* [[h-review-aggregate]]

See below for vocabulary summaries.

=== h-adr ===
{{main|h-adr}}

The '''h-adr''' microformat is for marking up structured locations such as addresses, physical and/or postal. This is an update to [[adr]].

root class name: '''<code>h-adr</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-adr</nowiki>

properties:
* '''<code>p-post-office-box</code>'''
* '''<code>p-extended-address</code>'''
* '''<code>p-street-address</code>'''
* '''<code>p-locality</code>'''
* '''<code>p-region</code>'''
* '''<code>p-postal-code</code>'''
* '''<code>p-country-name</code>'''
* '''<code>p-label</code>''' - new in [[vCard4]] ([[RFC6350]])
* '''<code>p-geo</code>''' (or '''<code>u-geo</code>''' with a RFC 5870 geo: URL) - new in [[vCard4]] ([[RFC6350]])
* '''<code>p-latitude</code>''' - new in [[vCard4]] ([[RFC6350]] from RFC 5870)
* '''<code>p-longitude</code>''' - new in [[vCard4]] ([[RFC6350]] from RFC 5870)
* '''<code>p-altitude</code>''' - new in [[vCard4]] ([[RFC6350]] from RFC 5870)

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-adr" is found, don't look for an "adr" on the same element.

compat root class name: <code id="adr">adr</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>post-office-box</code>
* <code>extended-address</code>
* <code>street-address</code>
* <code>locality</code>
* <code>region</code>
* <code>postal-code</code>
* <code>country-name</code>

=== h-card ===
{{main|h-card}}

The '''h-card''' microformat is for marking up people and organizations. This is an update to [[hCard]].

root class name: '''<code>h-card</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-card</nowiki>

properties:
* '''<code>p-name</code>'''
* '''<code>p-honorific-prefix</code>'''
* '''<code>p-given-name</code>'''
* '''<code>p-additional-name</code>'''
* '''<code>p-family-name</code>'''
* '''<code>p-sort-string</code>'''
* '''<code>p-honorific-suffix</code>'''
* '''<code>p-nickname</code>'''
* '''<code>u-email</code>'''
* '''<code>u-logo</code>'''
* '''<code>u-photo</code>'''
* '''<code>u-url</code>'''
* '''<code>u-uid</code>'''
* '''<code>p-category</code>'''
* '''<code>p-adr</code>'''
* '''<code>p-post-office-box</code>'''
* '''<code>p-extended-address</code>'''
* '''<code>p-street-address</code>'''
* '''<code>p-locality</code>'''
* '''<code>p-region</code>'''
* '''<code>p-postal-code</code>'''
* '''<code>p-country-name</code>'''
* '''<code>p-label</code>'''
* '''<code>p-geo</code>''' or '''<code>u-geo</code>''' with a RFC 5870 geo: URL, new in [[vCard4]] ([[RFC6350]])
* '''<code>p-latitude</code>'''
* '''<code>p-longitude</code>'''
* '''<code>p-altitude</code>''' - new in [[vCard4]] ([[RFC6350]] from RFC 5870)
* '''<code>p-tel</code>'''
* '''<code>p-note</code>'''
* '''<code>dt-bday</code>'''
* '''<code>u-key</code>'''
* '''<code>p-org</code>'''
* '''<code>p-job-title</code>''' - previously 'title' in hCard, disambiguated.
* '''<code>p-role</code>
* '''<code>u-impp</code>''' per RFC 4770, new in [[vCard4]] ([[RFC6350]])
* '''<code>p-sex</code>''' new in [[vCard4]] ([[RFC6350]])
* '''<code>p-gender-identity</code>''' new in [[vCard4]] ([[RFC6350]])
* '''<code>dt-anniversary</code>''' new in [[vCard4]] ([[RFC6350]])
* ...

Reserved properties: (properties not used much (if at all) in practice)
* '''<code>p-organization-name</code>'''
* '''<code>p-organization-unit</code>'''
* '''<code>p-tz</code>'''
* '''<code>dt-rev</code>'''
* ...

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-card" is found, don't look for a "vcard" on the same element.

compat root class name: <code id="vcard">vcard</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>honorific-prefix</code>
* <code>given-name</code>
* <code>additional-name</code>
* <code>family-name</code>
* <code>honorific-suffix</code>
* <code>nickname</code>
* <code>email</code> - parse as '''u-'''
* <code>logo</code> - parse as '''u-'''
* <code>photo</code> - parse as '''u-'''
* <code>url</code> - parse as '''u-'''
* <code>uid</code> - parse as '''u-'''
* <code>category</code>
* <code>adr</code> - parse as '''<code>p-adr h-adr</code>''' including compat root class <code>adr</code>
* <code>extended-address</code>
* <code>street-address</code>
* <code>locality</code>
* <code>region</code>
* <code>postal-code</code>
* <code>country-name</code>
* <code>label</code>
* <code>geo</code> - parse as '''<code>p-geo h-geo</code>''' including compat root class <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* <code>tel</code>
* <code>note</code>
* <code>bday</code> - parse as '''dt-'''
* <code>key</code> - parse as '''u-'''
* <code>org</code>
* <code>organization-name</code>
* <code>organization-unit</code>
* <code>title</code> - parse as '''p-job-title'''
* <code>role</code>
* ...

Reserved: (backward compat properties that parsers {{may}} implement, if they do, they {{must}} implement in this way:
* <code>tz</code>
* <code>rev</code> - parse as '''dt-'''
* ...

Note: use of 'value' within 'tel' should be automatically handled by the support of the [[value-class-pattern]]. And for now, the 'type' subproperty of 'tel' is dropped/ignored. If there is demonstrable documented need for additional tel types (e.g. fax), we can introduce new flat properties as needed (e.g. p-tel-fax).

=== h-entry ===
{{main|h-entry}}

The '''h-entry''' microformat is for marking up syndicatable content such as blog posts, notes, articles, comments, photos and similar. This is an update to [[hAtom]].

root class name: '''<code>h-entry</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-entry</nowiki>

properties:
* '''<code>p-name</code>''' (was p-entry-title, see issues)
* '''<code>p-summary</code>''' (was p-entry-summary, see issues)
* '''<code>e-content</code>''' (was e-entry-content, see issues)
* '''<code>dt-published</code>'''
* '''<code>dt-updated</code>'''
* '''<code>p-author</code>'''
* '''<code>p-category</code>'''
* '''<code>u-url</code>'''
* '''<code>u-uid</code>'''
* '''<code>p-geo</code>'''
* '''<code>p-latitude</code>'''
* '''<code>p-longitude</code>'''

This is an update to [[hAtom]].

Brainstorming:

The following properties are proposed additions to h-entry above and beyond what hAtom (or Atom) provides, based on various existing link preview markup conventions:
* '''<code>u-photo</code>'''
* '''<code>u-audio</code>''' - consider special u- parsing rules for <code><audio></code>
* '''<code>u-video</code>''' - consider special u- parsing rules for <code><video></code>
* '''<code>u-in-reply-to</code>''' - for links to other posts that this post is a reply to (comment regarding, etc.)

Backward compatibility:

(*)hAtom-specific implementations that perform custom display or translation (e.g. to Atom XML) {{should}} prefer <code>p-name</code> over <code>p-entry-title</code>, and use <code>p-entry-title</code> value(s) as a fallback if there is no <code>p-name</code>.

For hAtom backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-entry" is found, don't look for a "hentry" on the same element.

compat root class name: <code id="hentry">hentry</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>entry-title</code> - parse as '''<code>p-name</code>'''
* <code>entry-summary</code>
* <code>entry-content</code> - parse as '''e-'''
* <code>published</code> - parse as '''dt-'''
* <code>updated</code> - parse as '''dt-'''
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>category</code>
* <code>geo</code> - parse as '''<code>p-geo h-geo</code>''' including compat root <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* ...

<span id="h-entry-faq">FAQ:</span>
<div class="discussion">
* '''What is the <code>p-name</code> of a [http://indiewebcamp.com/note note]?'''
** A few options, from simplest to most detailed.
*** '''same as the p-content/e-content''' property.
*** '''same as the <code>title</code> element''' on the note permalink post page. When publishing a note on its own permalink post page, the contents of the note are likely abbreviated for the title of the page. The same abbreviation can be used for the p-name.
*** '''first sentence of the p-content/e-content''' property. It may be better for [http://indiewebcamp.com/syndication syndication] and [[link-preview]] purposes to provide just the first sentence of the note as the <code>p-name</code>. Similarly if only a portion of the content is syndicated to other sites, that portion can be marked up as the <code>p-summary</code>.
* ...
</div>

Resolved Issues:
* 2012-245 Resolved. See [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-120 2012-243 IRC discussion/consensus] for:
** Use '''<code>p-summary</code> instead of <code>p-entry-summary</code>'''. The historical semantic of "entry-summary" is not different from "summary" in any significant (or discernible way). Collapsing the two will simplify the overall microformats2 vocabularies further. In microformats2, entry-summary is no more.
** Use '''<code>e-content</code> instead of <code>e-entry-content</code>'''. Same point and advantage. In microformats2, entry-content is no more.
** '''drop <code>p-entry-title</code>'''. Unnecessary and subsumed by "p-name". Would consider move to backward compat only if cases are presented - known publishing uses are expected to be updated shortly.

=== h-event ===
{{main|h-event}}

The '''h-event''' microformat is for marking up events. This is an update to [[hCalendar]].

root class name: '''<code>h-event</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-event</nowiki>

properties:
* '''<code>p-name</code>'''
* '''<code>p-summary</code>'''(*)
* '''<code>dt-start</code>'''
* '''<code>dt-end</code>'''
* '''<code>dt-duration</code>'''
* '''<code>p-description</code>'''
* '''<code>u-url</code>'''
* '''<code>p-category</code>'''
* '''<code>p-location</code>'''
* '''<code>p-geo</code>'''
* '''<code>p-latitude</code>'''
* '''<code>p-longitude</code>'''
* ...

This is an update to [[hCalendar]].

(*)hCalendar-specific implementations that perform custom display or translation (e.g. to iCalendar .ics) {{should}} prefer <code>p-name</code> over <code>p-summary</code>, and use <code>p-summary</code> value(s) as a fallback if there is no <code>p-name</code>.

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-event" is found, don't look for a "vevent" on the same element.

compat root class name: <code id="vevent">vevent</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>summary</code> - parse as '''<code>p-name</code>'''
* <code>dtstart</code> - parse as '''<code>dt-start</code>'''
* <code>dtend</code> - parse as '''<code>dt-end</code>'''
* <code>duration</code> - parse as '''<code>dt-duration</code>'''
* <code>description</code>
* <code>url</code> - parse as '''u-'''
* <code>category</code>
* <code>location</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>, and compat root <code>adr</code> in the absence of <code>h-adr</code>
* <code>geo</code> - parse as '''<code>p-geo h-geo</code>''' including compat root <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* ...

=== h-geo ===
{{main|h-geo}}

The '''h-geo''' microformat is for marking up WGS84 geophysical coordinates. This is an update to [[geo]].

root class name: '''<code>h-geo</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-geo</nowiki>

properties:
* '''<code>p-latitude</code>'''
* '''<code>p-longitude</code>'''
* '''<code>p-altitude</code>''' - new in [[vCard4]] ([[RFC6350]] from RFC 5870)

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-geo" is found, don't look for an "geo" on the same element.

compat root class name: <code id="geo">geo</code>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>latitude</code>
* <code>longitude</code>

=== h-item ===
{{main|h-item}}

The '''h-item''' microformat is for marking up the item of an [[h-review]] or [[h-product]]. This is an update to part of [[hReview]].

root class name: '''<code>h-item</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-item</nowiki>

properties:
* '''<code>p-name</code>'''
* '''<code>u-photo</code>'''
* '''<code>u-url</code>'''

Note: in practice, due to the microformats2 implied property rules, it is expected that most uses of "h-item" won't require any explicit properties at all (since microformats2 parsers will infer name, photo, and url properties from the structure of the element with "h-item" and its contained content/elements if any).

=== h-product ===
{{main|h-product}}

The '''h-product''' microformat is for marking up products. This is an update to [[hProduct]].

root class name: '''<code>h-product</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-product</nowiki>

properties:
* '''<code>p-name</code>''' - name of the product
* '''<code>u-photo</code>''' - photo of the product
* '''<code>p-brand</code>''' - manufacturer, can also be a nested <code>h-card</code>
* '''<code>p-category</code>''' - freeform categories or tags applied to the item by the reviewer
* '''<code>e-description</code>'''
* '''<code>u-url</code>''' - URL of the product
* '''<code>u-identifier</code>''' - includes type (e.g. mpn, upc, isbn, issn, sn, vin, sku etc.) and value.
* '''<code>p-review</code>''' - a review of the product, can also be a nested <code>h-review</code>
* '''<code>p-price</code>''' - retail price of the product

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-product" is found, don't look for an "hproduct" on the same element.

compat root class name: <code id="hproduct">hproduct</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>photo</code> - parse as '''u-'''
* <code>brand</code>
* <code>category</code>
* <code>description</code>
* <code>identifier</code> - parse as '''u-'''
* <code>url</code> - parse as '''u-'''
* <code>review</code> - including compat root class <code>hreview</code> in the absence of <code>h-review</code>
* <code>price</code>

Note: [[hProduct]] has at least one experimental property which has real world adoption due to [[Google]] and [[Bing]] search support of hProduct. Currently this is: '''price'''

=== h-recipe ===
{{main|h-recipe}}

The '''h-recipe''' microformat is for marking up food recipes. This is an update to [[hRecipe]].

root class name: '''<code>h-recipe</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-recipe</nowiki>

properties:
* '''<code>p-name</code>''' - the name of the recipe
* '''<code>p-ingredient</code>''' - describes one or more ingredients used in the recipe.
* '''<code>p-yield</code>''' - Specifies the quantity produced by the recipe, like how many persons it satisfyies
* '''<code>e-instructions</code>''' - the method of the recipe.
* '''<code>dt-duration</code>''' - the time it takes to prepare the meal described by the recipe.
* '''<code>u-photo</code>''' - an accompanying image

Experimental properties with wide adoption
* '''<code>p-summary</code>''' - provides a short summary or introduction
* '''<code>p-author</code>''' - the person who wrote the recipe with <code>h-card</code>
* '''<code>dt-published</code>''' - the date the recipe was published
* '''<code>p-nutrition</code>''' - nutritional information like calories, fat, dietary fiber etc.
* ...

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-recipe" is found, don't look for an "hrecipe" on the same element.

compat root class name: <code id="hrecipe">hrecipe</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>ingredient</code>
* <code>yield</code>
* <code>instructions</code> - parse as '''e-'''
* <code>duration</code> - parse as '''dt-'''
* <code>photo</code> - parse as '''u-'''
* <code>summary</code>
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>nutrition</code>

Note: [[hRecipe]] has a number of experimental properties which have real world adoption due to [[Google]] recipe search support of hRecipe. These are: summary, author, published and nutrition

=== h-resume ===
{{main|h-resume}}

The '''h-resume''' microformat is for marking up resumes. This is an update to [[hResume]].

root class name: '''<code>h-resume</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-resume</nowiki>

properties:
* '''<code>p-summary</code>''' - overview of qualifications and objectives
* '''<code>p-contact</code>''' - current contact info in an <code>h-card</code>
* '''<code>p-education</code>''' - an education <code>h-calendar</code> event, years, nested <code>h-card</code> of the school, location.
* '''<code>p-experience</code>''' - a job or other professional experience <code>h-calendar</code> event, years, nested <code>h-card</code> of the organization, location, job-title.
* '''<code>p-skill</code>''' - a skill or ability, optionally including level and/or duration of experience
* '''<code>p-affiliation</code>''' - an affiliation with an <code>h-card</code> organization

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-resume" is found, don't look for an "hresume" on the same element.

compat root class name: <code id="hresume">hresume</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>summary</code>
* <code>contact</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>education</code> - including compat root <code>vevent</code> in the absence of <code>h-event</code>
* <code>experience</code> - including compat root <code>vevent</code> in the absence of <code>h-event</code>
* <code>skill</code>
* <code>affiliation</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>

Note: skill has a [[hresume-skill-brainstorm|proposed expansion into competency]] with explicit summary, rating and/or duration components. Based on existing real world adoption, we should consider an h-competency vocabulary with p-summary, p-rating, and dt-duration properties.

=== h-review ===
{{main|h-review}}

The '''h-review''' microformat is for marking up reviews. This is an update to [[hReview]]. See also [[h-item]].

root class name: '''<code>h-review</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-review</nowiki>

properties:
* '''<code>p-name</code>''' - name of the review
* '''<code>p-item</code>''' - thing been reviewed i.e. business or person (h-card), event (h-event), place (h-adr or h-geo), product (h-product), website, url, or other item ([[h-item]]).
* '''<code>p-reviewer</code>''' - person who authored the review
* '''<code>dt-reviewed</code>''' - date time of when the review was written
* '''<code>p-rating</code>''' - value from 1-5 indicating a rating for the item (5 best).
* '''<code>p-best</code>''' - define best rating value. can be numerically lower than worst.
* '''<code>p-worst</code>''' - define worst rating value. can be numerically higher than best.
* '''<code>e-description</code>''' - the full text written evaluation and opinion of the reviewer
* '''<code>p-category</code>''' - freeform categories or tags applied to the item by the reviewer
* '''<code>u-url</code>''' - URL of the review

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-review" is found, don't look for an "hreview" on the same element.

compat root class name: <code id="hreview">hreview</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>summary</code> parse as '''<code>p-name</code>'''
* <code>fn</code> - parse as '''p-name''' of the item being reviewed (p-item h-item p-name)
* <code>photo</code> - parse as '''u-photo''' of the item being reviewed (p-item h-item u-photo)
* <code>url</code> - parse as '''u-url''' of the item being reviewed (p-item h-item u-url)
* <code>reviewer</code> - including compat root vcard in the absence of h-card
* <code>dtreviewed</code> - parse as '''dt-'''
* <code>rating</code>
* <code>best</code>
* <code>worst</code>
* <code>description</code> - parse as '''e-'''
* <code>rel="tag"</code> - parse as '''p-category'''
* <code>rel="self bookmark"</code> - parse as '''u-url'''. note that <code>rel</code> attribute value is treated as a space separated set, thus any presence of "self" and "bookmark" within such a set in a rel value is accepted.

Note: The [[hReview]] format has three properties which make use of <code>rel</code> attribute, these are <code>tag</code>, permalink (via the <code>self</code> and <code>bookmark</code> values) and <code>license</code>. Microformats 2 parsers {{should}} map these URLs into the page scoped rel collection.

=== h-review-aggregate ===
{{main|h-review-aggregate}}

The '''h-review-aggregate''' microformat is for marking up aggregate reviews of a single item. This is an update to [[hreview-aggregate]]. See also [[h-item]].

root class name: '''<code>h-review-aggregate</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-review-aggregate</nowiki>

properties:
* '''<code>p-name</code>''' - name of the review
* '''<code>p-item</code>''' - thing been reviewed i.e. business or person (h-card), event (h-event), place (h-adr or h-geo), product (h-product), website, url, or other item (h-item).
* '''<code>p-rating</code>''' - value from 1-5 indicating average rating for the item (5 best).
* '''<code>p-best</code>''' - define best rating value. can be numerically lower than worst.
* '''<code>p-worst</code>''' - define worst rating value. can be numerically higher than best.
* '''<code>p-count</code>''' - number of reviews aggregated.
* '''<code>p-votes</code>''' - number of reviewers who have rated the product, thus contributing to the average rating.
* '''<code>p-category</code>''' - freeform categories or tags applied to the item by the reviewer
* '''<code>u-url</code>''' - URL of the review

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-review-aggregate" is found, don't look for an "hreview-aggregate" on the same element.

compat root class name: <code id="hreview-aggregate">hreview-aggregate</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>summary</code> parse as '''<code>p-name</code>'''
* <code>fn</code> - parse as '''p-name''' of the item being reviewed (p-item h-item p-name)
* <code>photo</code> - parse as '''u-photo''' of the item being reviewed (p-item h-item u-photo)
* <code>url</code> - parse as '''u-url''' of the item being reviewed (p-item h-item u-url)
* <code>rating</code>
* <code>best</code>
* <code>worst</code>
* <code>count</code>
* <code>votes</code>
* <code>rel="tag"</code> - parse as '''p-category'''
* <code>rel="self bookmark"</code> - parse as '''u-url'''. note that <code>rel</code> attribute value is treated as a space separated set, thus any presence of "self" and "bookmark" within such a set in a rel value is accepted.

=== v2 vocab notes ===
Notes:
* All v2 vocabularies are defined as flat lists of properties of an object/item, and thus can be used in microformats-2 syntax as shown, or in microdata items, or RDFa. The microformats-2 property parsing prefixes "p-", "u-", "dt-", "e-" are omitted when using defined properties in microdata itemprop and RDFa property as those syntaxes have their own element-specific parsing rules.
* Profile URLs are provided for use with the HTML4 <code>profile</code> attribute, microdata <code>itemtype</code> attribute, and RDFa <code>vocab</code> & <code>typeof</code> attributes (though the latter requires slicing off the trailing segment of the profile for the typeof attribute, and leaving the rest in vocab).
* microformats 2 properties may also be explicitly bound as URIs using [[rel-profile]], the [[html5-profile]] attribute proposal, or an HTML5 'vocab' attribute instead. If URI bound terms are important to you, please express interest on [[rel-profile]], [[html5-profile]], or contribute to an [[html5-vocab]] draft.

=== v2 vocab to-do ===
To do:
* write a simple tutorial for creating/getting started with microformats-2 markup for new content
* examples in each h-* spec listed above of how to embed other microformats in them
* actual profile documents at <nowiki>http://microformats.org/profile/h-*</nowiki> URLs mentioned above.
* Provide any necessary microdata-specific language as needed (e.g. to be comparably understandable to the [http://www.whatwg.org/specs/web-apps/current-work/#vcard sample vCard4/hCard1 microdata vocabulary]. Also provide any necessary RDFa-specific language as needed. Both preferably in a generic vocabulary-independent way.
* write a porting guide mapping v1 property -> v2 property
** use-case: simple search/replace in templates (e.g. in case web author doesn't remember existing microformats vocabs and where they used them).
** advise using *both* in existing templates (e.g. in case some CSS depends on the existing microformats)
* analyzie/document how well the microformats2 model and vocabularies satisfy the [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019681.html use-cases used to design/create microdata].

== combining microformats ==
Since microformats 2 uses simple flat sets of properties for each microformat, multiple microformats are combined to indicate additional structure.

=== h-event location h-card ===
Events commonly have venue information with additional structure, like address information. For example:

<source lang=html4strict>
<div class="h-event">
<a class="p-name u-url" href="http://indiewebcamp.com/2012">
IndieWebCamp 2012
</a>
from <time class="dt-start">2012-06-30</time>
to <time class="dt-end">2012-07-01</time> at
<span class="p-location h-card">
<a class="p-name p-org u-url" href="http://geoloqi.com/">
Geoloqi
</a>,
<span class="p-street-address">920 SW 3rd Ave. Suite 400</span>,
<span class="p-locality">Portland</span>,
<abbr class="p-region" title="Oregon">OR</abbr>
</span>
</div>
</source>

The nested h-card used to structure the p-location of the h-event is represented as a structured value for "location" in the JSON, which has an additional key, "value" that represents the plain text version parsed from the p-location.

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-event"],
"properties": {
"name": ["IndieWebCamp 2012"],
"url": ["http://indiewebcamp.com/2012"],
"start": ["2012-06-30"],
"end": ["2012-07-01"],
"location": [{
"value": "Geoloqi, 920 SW 3rd Ave. Suite 400, Portland, OR",
"type": ["h-card"],
"properties": {
"name": ["Geoloqi"],
"org": ["Geoloqi"],
"url": ["http://geoloqi.com/"],
"street-address": ["920 SW 3rd Ave. Suite 400"],
"locality": ["Portland"],
"region": ["Oregon"]
}
}]
}
}]
}
</source>

Questions:
<div class="discussion">
* Should the nested hCard be present also as a top-level item in the JSON? - [[User:Tantek|Tantek]] 02:02, 19 June 2012 (UTC)
** My current (2012-243) leaning is no. - [[User:Tantek|Tantek]] 18:53, 30 August 2012 (UTC)
** If so, how do we avoid expansion of the JSON geometrically proportional to the depth of microformat nesting? (Or do we not worry about it?)
* Should there be a canonical hierarchical JSON and a canonical flattened JSON? - [[User:Tantek|Tantek]] 02:02, 19 June 2012 (UTC)
** My current (2012-243) leaning is no, we stick with one canonical JSON for uf2 which is hierarchical. - [[User:Tantek|Tantek]] 18:53, 30 August 2012 (UTC)
** If so, should the flattened JSON have references from properties to nested microformats that have been pushed to the top level per flattening? - [[User:Tantek|Tantek]] 02:02, 19 June 2012 (UTC)
*** If so, what convention does/do JSON follow for such synthetic local reference identifiers? - [[User:Tantek|Tantek]] 02:02, 19 June 2012 (UTC)
</div>

Notes:
* The 'location' value reflects the visible text of its element, including spaces and punctuation, as well as the state abbreviation 'OR'. The 'h-card' property values are only what is marked up, and thus include structure values without extra punctuation, and the state takes the expanded form from the <code>title</code> attribute of its <code><abbr></code> element.

=== h-card org h-card ===
People often publish information general to their company rather than specific to them, in which case, they may wish to encapsulate that in separately nested microformat. E.g. here is a simple h-card example with org property:

[http://blog.lizardwrangler.com Mitchell Baker] (Mozilla Foundation)

with source:
<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<span class="p-org">Mozilla Foundation</span>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"],
"org": ["Mozilla Foundation"]
}
}]
}
</source>

Sometimes such organization affiliations are hyperlinked to the website of the organization:

[http://blog.lizardwrangler.com Mitchell Baker] ([http://mozilla.org/ Mozilla Foundation])

You can mark that up with a nested h-card:
<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="p-org h-card"
href="http://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"],
"org": [{
"value": "Mozilla Foundation",
"type": ["h-card"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["http://mozilla.org/"]
}
}]
}
}]
}
</source>

Note: the nested h-card has implied 'name' and 'url' properties, just like any other root-class-name-only h-card on an <code><a href></code> would.

'''FOR PARSERS ONLY:'''

The nested 'h-card' could be marked up as an 'h-org' as well, which adds it to the nested microformat's type array, all as part of the property specified by the 'p-org'.

<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="p-org h-card h-org"
href="http://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"],
"org": [{
"value": "Mozilla Foundation",
"type": ["h-card", "h-org"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["http://mozilla.org/"]
}
}]
}
}]
}
</source>

'''FOR PARSERS ONLY:'''

Without a property class name like 'p-org' holding all the nested objects together, we need to introduce another array for nested children (similar to the existing DOM element notion of children) of a microformat that are not attached to a specific property:

<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="h-org h-card"
href="http://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"]
},
"children": [{
"type": ["h-card","h-org"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["http://mozilla.org/"]
}
}]
}]
}
</source>

Since there's no property class name on the element with classes 'h-card' and 'h-org', the microformat representing that element is collected into the children array.

Such a nested microformat implies some relationship (containment, being related), but is not as useful as if the nested microformat was a specific property of its parent.

For this reason it's recommended that authors should not publish nested microformats without a property class name, and instead, when nesting microformats, authors should always specify a property class name (like 'p-org') on the same element as the root class name(s) of the nested microformat(s) (like 'h-card' and/or 'h-org').

'''FOR PARSERS ONLY:'''

Or the nested object could be only marked up with 'h-card'. Source:

<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="h-card"
href="http://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"]
},
"children": [{
"type": ["h-card"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["http://mozilla.org/"]
}
}]
}]
}
</source>

'''TO DO: Add h-event h-card example and JSON, per real world publishing examples like [http://www.swingtime.co.uk/List/ClSouth.html Swing Time: Classes in Southern England].'''

== authoring ==
=== minimal markup ===
The best way to use microformats-2 is with as little additional markup as possible. This keeps your code cleaner, improves its maintainability, and thus the quality and longevity of your microformats.

One big advantage of microformats-2 over previous microformats (and others) is the ability to add one class name to an existing element to create a structured item.

See the [[microformats-2#simple_microformats_2_examples|simple examples at the top]] for a start, e.g.

Simple hCards work just by adding <code>class="h-card"</code> :
<source lang=html4strict>
<span class="h-card">Frances Berriman</span>

<a class="h-card" href="http://benward.me">Ben Ward</a>

<img class="h-card" alt="Sally Ride"
src="http://upload.wikimedia.org/wikipedia/commons/a/a4/Ride-s.jpg"/>

<a class="h-card" href="http://tantek.com">
<img alt="Tantek Çelik" src="http://ttk.me/logo.jpg"/>
</a>
</source>

* Tip: Inside an open tag, put the <code>class</code> attribute <em>first</em>, then any human text content attributes (e.g. <code>alt</code>), then URL attributes (e.g. <code>href</code> <code>src</code>), and lastly other attributes (e.g. <code>style</code>). Putting the class attribute first ties it closely to the element name/tag itself, makes it more obvious, and thus more likely to be kept up to date.

=== backward compatible ===
If you depend on current microformats [[implementations]], while they're being updated to support [[microformats-2]], you can include both existing microformats and microformats-2 markup.

In short: use both sets of class names simultaneously.

When doing so, use them on the same element, with the microformats-2 class name first, followed immediately by the existing microformats class name.

Here are the microformats-2 hCards from above with current [[hCard]] markup as well, which may require adding a wrapping element (e.g. a <code><span></code>) to separate the root class name element from explicit property class name elements:

<source lang=html4strict>
<span class="h-card vcard">
<span class="p-name fn">Frances Berriman</span>
</span>

<span class="h-card vcard">
<a class="p-name fn u-url url" href="http://benward.me">Ben Ward</a>
</span>

<span class="h-card vcard">
<img class="p-name fn u-photo photo" alt="Sally Ride"
src="http://upload.wikimedia.org/wikipedia/commons/a/a4/Ride-s.jpg"/>
</span>

<span class="h-card vcard">
<a class="u-url url" href="http://tantek.com">
<img class="p-name fn u-photo photo" alt="Tantek Çelik"
src="http://ttk.me/logo.jpg"/>
</a>
</span>
</source>

Tips:
* use the microformats-2 class name first, e.g.
** <code>class="h-card vcard"</code>
** <code>class="u-url url"</code>
* and pair them when using an element for multiple properties, e.g.:
** <code>class="p-name fn u-url url"</code>
** <code>class="p-name fn u-photo photo"</code>
* put microformats classes after classes for CSS (since page authors will likely interact more with their own classes for design than with microformats classes), e.g. as used on individual microformats [[events]] pages:
** <code>class="event-page h-event vevent"</code>

The prefixes (h-, p-, etc.) of microformats2 class names provide easier recognition, and when followed by the similarly named existing class name, they're more easily recognized as related and thus kept together when the markup is maintained over time.

Related FAQ: [[microformats2-faq#when_using_both_h-card_and_vcard_which_should_be_first_and_why|When using both h-card and vcard which should be first and why?]]

== validators ==
microformats2 validators:

{{new}} Test your microformatted web page with:
* https://pin13.net/mf2/

Barnaby Walters has a hosted version of the open source php-mf2 [[parser]] where you can enter your markup into a textarea and see how it's parsed:
* http://waterpigs.co.uk/php-mf2/

See the [[validators]] page for a longer list of validators.

== Examples in the wild ==
Please add new examples in the wild of microformats-2 to the top of this list. When it gets too big we can move it to a separate page like [[microformats-2-examples-in-wild]].

* ...
* David John Mead marks up his profile, blog posts and comments with h-card, h-entry and h-cite on [http://davidjohnmead.com davidjohnmead.com]
* [[User:Brian|Brian Suda]] marks up his blog posts up with h-entry and h-card on [http://optional.is/required/ optional.is]
* Ashton McAllen marks up his blog posts, reposts, comments and likes with h-entry, h-card and h-cite on [http://acegiak.net/ acegiak.net]
* Emma Kuo marks up her blog posts and notes with h-entry and h-card on [http://notenoughneon.com/ notenoughneon.com]
* Scott Jenson marks up his blog posts with h-entry and h-card on [http://jenson.org/ jenson.org]
* Emily McAllen marks up her blog posts with h-entry and h-card on [http://blackwoolholiday.com/ blackwoolholiday.com]
* Ryan Barrett marks up his blog posts, notes, replies and likes with h-entry and h-card on [https://snarfed.org/ snarfed.org]
* Barry Frost marks up his notes with h-entry, h-card and h-cite on [http://barryfrost.com/ barryfrost.com]
* Amber Case marks up her profile, blog posts, replies and notes with h-entry and h-card on [http://caseorganic.com/ caseorganic.com]
* Johannes Ernst marks up his blog posts with h-entry on [http://upon2020.com/blog/ upon2020.com]
* Michiel de Jong marks up his profile and notes with h-entry and h-card on [https://michielbdejong.com/ michielbdejong.com]
* Mike Taylor marks up his profile and blog posts with h-card and h-entry on [https://bear.im/bearlog/ bear.im]
* Erin Jo Ritchey marks up her profile, posts and comments using h-card, h-entry and h-cite with idno on [http://erinjo.is/ erinjo.is]
* Jeena Paradies marks up his profile, blog posts, notes and comments using h-card, h-entry and h-cite on [https://jeena.net/ jeena.net]
* Andy Sylvester marks up his profile, blog posts and comments using h-card and h-entry on [http://andysylvester.com/2014/03/01/howto-setting-up-the-selfoss-feed-reader-with-microformats-support/ andysylvester.com] (note: as of 2014-03-13 using h-entry for comments instead of correct h-cite --[[User:Barnabywalters|bw]] 14:44, 13 March 2014 (UTC))
* Hakan Demir marks up his Coupon and Voucher blog posts with h-entry and h-card on [http://www.gutscheinflagge.de/ gutscheinflagge.de]
* Chloe Weil marks up her blog posts with h-entry on [http://chloeweil.com/blog chloeweil.com]
* Christophe Ducamp marks up his blog posts and profile with h-entry and h-card on [http://christopheducamp.com/ christopheducamp.com]
* Glenn Jones marks up his blog posts, notes, replies, profile and comments with h-entry, h-card and h-cite on [http://glennjones.net/ glennjones.net]
* Marcus Povey marks up his blog posts and profile with h-entry and h-card on [http://www.marcus-povey.co.uk/ marcus-povey.co.uk]
* Eugen Busoiu marks up his web profile with h-card on [http://eugenbusoiu.com/#utm_source=microformats2&utm_medium=h-card&utm_campaign=Microformats eugenbusoiu.com]]
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* Kyle Mahan marks up his profile and notes with h-card and h-entry on [http://kylewm.com/ kylewm.com]
* Okinawan-lyrics marks up his blog posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* Emil Björklund marks up his blog posts with h-entry and h-card ([http://thatemil.com/blog/2013/09/16/webmentioning-adactio/ example])
* App.net rolled out support for h-card and h-entry on all profile pages and permalink pages as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* Brett Comnes marks up his posts with h-entry and h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his posts with h-card and h-entry, u-in-reply-to and u-like ([http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his posts up with h-card and h-entry, as well as draft u-in-reply-to and experimental u-like properties ([http://sandeep.io/101 example])
* Laurent Eschenauer marks up his posts with h-entry ([http://eschnou.com/entry/first-autonomous-flight-of-my-nodecopter-62-24992.html example])
* Tom Morris marks up his posts using h-entry ([http://tommorris.org/posts/8417 example])
* Sinolandquality marks up some of their content using h-feed and h-entry on [http://www.sinolandquality.com/Blog/?page_id=3516&utm_content=buffere4d40&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer sinolandquality.com]
* [http://www.w3.org/conf/ W3Conf 2013] uses h-event for the main event, and h-card for all the speakers and notable attendees. The h-cards make particularly good use of implied name, url, and photo properties.
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry and h-as-*
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Tom Morris uses h-card and [[XFN]] to markup [http://tommorris.org/pages/blogroll his blogroll].
* Aaron Parecki uses h-card to markup both authorship and references to people in his notes permalinks, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-card, h-event, and h-entry on his home page, as well as h-entry on all post permalinks, e.g. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], with [[rel-prev]]/[[rel-next]] (if applicable) to indicate prev/next posts, and with [[rel-author]] to his home page with canonical hCard to indicate authorship.
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-card on his home page, h-card, h-entry and XFN markup on his [http://waterpigs.co.uk/notes notes page].
** 2013-01-25 Barnaby Walters: <cite>[http://waterpigs.co.uk/articles/experimental-markup Experimental Markup]</cite> - describes how he's using microformats2 vocabularies: <code>h-adr</code>, <code>h-card</code>, <code>h-entry</code>, <code>h-event</code>, <code>h-geo</code>, <code>h-review</code>, and experimental vocabularies: <code>h-feed</code> (embedded for update histories), [[activity-streams]] objects <code>h-as-article</code>, <code>h-as-collection</code>, <code>h-as-note</code>, <code>h-as-update</code>, as well as experimental properties: <code>u-alternate</code> and <code>u-as-downstream-duplicate</code> (links to POSSE copies), and <code>u-in-reply-to</code> (links to content that the posts are in reply to).
* [http://tantek.com/presentations/2012/06/microformats microformats.org at 7 years] presentation with h-event and h-card markup for people and organizations.
* [http://tantek.com/presentations/2012/06/pdf2012-indieweb.html Rise of the Indie Web hCards] (from Personal Democracy Forum 2012 #pdf12 #pdf2012) has [[microformats-2]] h-calendar and h-card markup
* WebMaker by Mozilla has [[microformats-2]] h-calendar and h-card on event search (e.g. [https://webmaker.org/en-US/events/near/?lat=45.5234515&lng=-122.6762071 search near Portland Oregon]) and event pages (e.g. [https://webmaker.org/en-US/events/192f56eb9/ IndieWebCamp 2012]).[https://twitter.com/microformats/status/212207925643587585]
* WebFWD by Mozilla has [[microformats-2]] h-card markup on [https://webfwd.org/about/experts/ experts] and [https://webfwd.org/about/team/ team] pages
* [http://indiewebcamp.com IndieWebCamp] has [[microformats-2]] h-event markup with nested h-cards for the organizers and the location.
* [https://wiki.mozilla.org/Events Mozilla Events] page has [[microformats-2]] h-event markup with attendees marked up with h-card.
* The [http://pdx.esri.com/blog/2013/10/17/introducing-mapattack/ Esri PDX Blog] has h-entry markup on all blog posts (as of 2013-10-19), and h-product markup on [http://pdx.esri.com/projects/terraformer/ project pages]

=== offline ===
* spreadly marks up share permalink pages with h-entry, as well as minimal h-cards and experimental p-like properties ([http://my.spread.ly/share/51d570bc09e9486562000002 example])

== Implementations ==
{{new}} Test your microformatted web page with:
* https://pin13.net/mf2/ (where it says "Microformats Parser")

=== Blogging tools ===
* '''Storytlr''' parses the 'target' from [http://indiewebcamp.com/pingback pingbacks] for [https://github.com/storytlr/storytlr/blob/master/protected/application/public/controllers/PingbackController.php#L63 h-entry with properties and nested h-card] for information to automatically display in the [http://eschnou.com/entry/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html comments section on a post].

=== Converters ===

* '''[https://github.com/snarfed/activitystreams-unofficial activitystreams-unofficial]''' is a library and REST API that converts between silo APIs, [[ActivityStreams]] and [[microformats2]] (all directions). Supported silos include Facebook, Twitter, Instagram and Google+. Users include [http://brid.gy/ Bridgy], [http://reader.kylewm.com/ Woodwind], and [https://facebook-atom.appspot.com/ facebook-atom] and [https://twitter-atom.appspot.com/ twitter-atom], among others.

* '''[http://pipes.yahoo.com/pipes/pipe.info?_id=afc5568b4e8643bfb05436b1caaf91bc microformats to RSS]''' - a Yahoo! pipe that converts a URL containing an [[h-feed]] containing h-entries, into an [[RSS]] feed ([http://waterpigs.co.uk/notes/4SeNi5/ 2013-10-21 blog post announcing])

=== Parsers ===
Parsers, open source libraries, in alphabetical order by programming language:

==== Go ====
* '''andyleap/microformats''' Golang microformats2 parser
** github open source: https://github.com/andyleap/microformats
** live textarea entry: http://mf2.vendaria.net

==== Haskell ====
* '''myfreeweb/microformats2-parser''' Haskell microformats2 parser
** github open source: https://github.com/myfreeweb/microformats2-parser
** live textarea entry: https://unrelenting.technology/mf2/

==== Java ====
* '''mf2j''' An early-stage Java microformats2 parser
** github open source: https://github.com/kylewm/mf2j
** live: https://mf2j.herokuapp.com/?url={http://example.com}

==== Javascript ====
* '''microformat-node''' Node.js microformats2 parser
** github open source: https://github.com/glennjones/microformat-node
** test suite: https://github.com/microformats/tests
** blog post: http://glennjones.net/2013/01/brand-new-microformats-2-parser/
** live: http://glennjones.net/tools/microformats/
* '''microformat-shiv''' - cross browser javascript microformats 2 parser which can also be used in browser extensions.
** http://microformatshiv.com/
** github open source: https://github.com/glennjones/microformat-shiv

==== PHP ====
* '''<span id="php-mf2">php-mf2</span>''' - PHP microformats2 parser
** github open source: https://github.com/indieweb/php-mf2
** Packagist: https://packagist.org/packages/mf2/mf2
** live:
*** textarea entry: http://waterpigs.co.uk/php-mf2/
*** URL entry: https://pin13.net/mf2/
==== Python ====
* '''mf2py''' Python microformats2 parser
** main entry: [[mf2py]]
** github open source: https://github.com/tommorris/mf2py
** live:
*** URL entry: [https://mf2py.herokuapp.com/ mf2py.herokuapp.com]
*** textarea entry: https://kartikprabhu.com/connection/mfparser
*** another textarea: http://www.unmung.com/?html=
*** URL and/or textarea: https://kylewm.com/services/mf2

==== Ruby ====
* '''G5/microformats2''' Ruby microformats2 parser
** github open source: https://github.com/G5/microformats2

== Presentations ==
Presentations about microformats2:
* 2013-01-24 <cite>[http://waterpigs.co.uk/presentations/microformats-2/ Microformats 2]</cite> presentation by [[User:Barnabywalters|Barnaby Walters]] at the [[events/2013-01-24-exeter-web-meetup|Exeter Web Meetup]] in Devon, UK.
* 2012-09-21 <cite>[http://tantek.com/presentations/2012/09/microformats2/ microformats2 & bits of HTML5: The Evolution Of Web Data]</cite> presentation by [[User:Tantek|Tantek Çelik]] ([http://twitter.com/t @t]) at [[events/2012-09-21-refreshlx|RefreshLX]] in Lisbon, Portugal.
* 2012-07-21 <cite>[http://tantek.com/presentations/2012/07/html5-uf2/ HTML5 and microformats2: The Evolution Of Web Data]</cite> presentation by [[User:Tantek|Tantek Çelik]] ([http://twitter.com/t @t]) at [[events/2012-07-21-cascadesf|Innovators of the Web conference]] in San Francisco, CA.
* 2012-07-14 <cite>[http://tantek.com/presentations/2012/07/html5-microformats2/ HTML5 and microformats2: The Evolution Of Web Data]</cite> presentation by [[User:Tantek|Tantek Çelik]] ([http://twitter.com/t @t]) at [[events/2012-07-14-open-web-camp-4|Open Web Camp IV]] in San Jose, CA.

== Testimonials ==
* <blockquote class="twitter-tweet">To prove the web standards community can come up with better standards than the SE’s, compare this: http://microformats.org/wiki/microformats-2 with schema . org — Joost de Valk (@yoast) [https://twitter.com/yoast/status/298907685452124160 2013-02-05 13:35]</blockquote>
* <blockquote class="twitter-tweet">... I’m hoping SE’s will pick up microformats2. It’s SO much cleaner. — Joost de Valk (@yoast) [https://twitter.com/yoast/status/298911287117758464 2013-02-05 13:49]</blockquote>
* <blockquote class="twitter-tweet">... But damn Microformats2 are sexy. — Joost de Valk (@yoast) [https://twitter.com/yoast/status/298912179292344320 2013-02-05 13:53]</blockquote>

== About This Brainstorm ==
The rest of this page is a brainstorm currently written in narrative / exploratory format, that is, acknowledging the success that microformats have had, why so, and then a walk through of known issues with microformats in general along with iteration of ways to address said issues, ending up with the current microformats 2 design as a conclusion.

The proposals build on each other resulting in a solution that addresses the vast majority of general issues. The proposed changes merit a major version number increment, hence microformats 2.

This mathematical proof/derivation style is used to explicitly encourage understanding (and double-checking) of the rational steps taken in the development of microformats 2. Reasons are documented, sometimes along with alternatives considered (and reasons for rejection of those alternatives).

When the microformats 2 brainstorm has evolved sufficiently to demonstrate some degree of stability, usability, and implementability, it will be rewritten in a more declarative specification style, and this narrative/derivation will be archived to a background development page for historical purposes.

— [[User:Tantek|Tantek]]

== Background ==

2004: In early February microformats were introduced as a concept at eTech, and in September [[hCard]] and [[hCalendar]] were proposed at FOO Camp.

2010:
* 34% of webdevs use microformats ([http://www.webdirections.org/sotw10/markup/#semantics 2010 State of Web Development survey])
* 1.88 billion hCards (per [[Yahoo]] SearchMonkey)
* 36 million hCalendar events (ibid)

* XFN -> Social Graph API -> Web as Social Network / Address Book

== Addressing Issues ==
=== AUTHORS and PUBLISHING ===
Authors and publishers are perhaps the most important constituency in the microformats community. There are more of them than there are developers, programmers, parsers, etc. and they're the ones that solved the chicken-egg problem by publishing microformats even before tools were available for consuming them.

Therefore we must first address author/publisher general issues with microformats.

==== can we make the simplest case simpler ====
Issue: '''How can we make it easier for authors to publish microformats?'''

Currently the simplest hCard:
<source lang=html4strict>
<span class="vcard">
<span class="fn">
Chris Messina
</span>
</span>
</source>

requires 2 elements (nested, with perhaps at least one being pre-existing), and 2 class names.

Web authors/designers are used to the simplicity of most HTML tags, e.g. to mark up a heading:

<source lang=html4strict>
<h1>Chris Messina</h1>
</source>

requires just 1 element.

[http://zeldman.com/ Jeffrey Zeldman] pointed out this apparent perceived incremental complexity (2 elements vs 1) during a microformats workshop in 2009 in New York City.

'''How can we make microformats just as easy?'''

'''Proposal: allow root class name only.'''

This would enable:

<source lang=html4strict>
<h1 class="vcard">Chris Messina</h1>
</source>

requiring only 1 class name for the simplest case.

==== renaming for usability ====
Otherwise known as, choosing one form of consistency over another.

'''Can we do even better?'''

One of the most common questions asked about hCard is:

[[hcard-faq#Why_does_hCard_use_vcard_as_the_root_class_name|Why does hCard use vcard as the root class name?]]

This slight inconsistency between the name of the format and the name of the root class name consistently causes confusion in a large percentage of newcomers to microformats.
* See [[issues#hcard-vs-vcard-name]] for details/links.

Though in microformats we believe very strongly in the [[principle]] of [[reuse]], we have to admit that in this case experience/evidence has shown that this may be a case where we re-used something too far beyond it's original meaning. Thus:

'''Proposal: use root class name "hcard" instead of "vcard" for future hCards.'''

This would result in:

<source lang=html4strict>
<h1 class="hcard">Chris Messina</h1>
</source>

making the simple case even simpler:

Just 1 additional class name, named the same as the format you're adding. Think hCard, markup class="hcard".

At a minimum for compatibility we should document that parsers should accept "hcard" as an alternative to "vcard" as the root class name for hCard 1.0, and similarly for hCalendar 1.0: "hcalendar" in addition to "vcalendar", "hevent" in addition to "vevent".

However, for [[microformats-2]] we are going to distinguish root class names further by using an "h-" prefix (e.g. "h-card"). Read on to understand why.

==== simplifying to only needing one element ====
It's very important for the simple case to be as simple as possible, to enable the maximum number of people to get started with minimum effort. (The idea of using a single class name for a microformat was proposed by Ryan Cannon in 2006 specifically [[hcard-implied|for hCard]], and rediscovered by [[User:Tantek|Tantek]] in 2010 and subsequently generalized to all microformats.)

From there on, it's ok to require incremental effort for incremental return.

E.g. to add any additional information about a person, add explicit property names.

'''How does this simple root-only case work?'''

* root class name reflects name of the microformat
* every microformat must require at most 1 property (preferably 0)
** admit that requiring a field in an application just results in noise (the 90210 problem - apps which require zip code get lots of false 90210 entries), and specify that any application use cases which appear to "require" specific properties must instead define how to imply sensible defaults for them.
* when only a root class name is specified, imply the entire text contents of the element as the value of the primary property of the microformat. e.g.
** "hcard" implies "fn"
** hcalendar event - "hevent" - implies "summary"
** "hreview" implies "summary"
** "hentry" implies "entry-summary" (perhaps collapse into "summary" - in practice they're not sufficiently semantically distinct to require separate property names)
** '''OR''' instead of making the one implied property be vocabulary specific, introduce a new generic (applicable to all vocabularies) 'p-name' property (subsuming hCard's 'fn'). See [[microformats-2-brainstorming#further_simplifications|microformats 2 brainstorming: further simplifications]] for latest thoughts along these lines, including the following specific mark-up implied generic properties across all microformats (based on existing published markup use-cases)
*** 'p-name'
*** 'u-url'
*** 'u-photo'

==== flat sets of properties ====
'''What more can we simplify about microformats?'''

Numerous individuals have provided the feedback that whenever there is more than one level of hierarchy in a microformat, many (most?) developers get confused - in particular Kavi Goel of Google / Rich Snippets provided this feedback at a microformats dinner. Thus depending on multiple levels of hierarchy is likely resulting in a loss of authorability, perhaps even accuracy as confusion undoubtedly leads to more errors. Thus:

'''Proposal: simplify all microformats to flat sets of properties. '''

What this means:
* all microformats are simply an object with a set of properties with values.
* no more subproperties- drop the notion of subproperties.
* use composition of multiple microformats for any further hierarchy, e.g. the "location" of an hCalendar event can be an hCard, or the "agent" of one hCard can be another hCard.

For example for hCard this would mean the following specific changes to keep relevant functionality:
* drop "n", promote all "n" subproperties to full properties
** given-name, family-name, additional-name, honorific-prefix, honorific-suffix
* treat "geo" as a nested microformat
* treat "adr" as a nested microformat (what to do about adr's "type"?)
* treat "org" as a flat string and drop "organization-name" and "organization-unit" (in practice rarely used, also not revealed or ignored in contact management user interfaces - e.g. Address Book)

Example: add a middle initial to the previous example Chris Messina's name, and markup each name component:

<source lang=html4strict>
<h1 class="hcard">
<span class="fn">
<span class="given-name">Chris</span>
<abbr class="additional-name">R.</abbr>
<span class="family-name">Messina</span>
</span>
</h1>
</source>

Note:
# use of an explicit span with "fn" to markup his entire formatted name
# use of the abbr element to explicitly indicate the semantic that "R." is merely an abbreviation for his additional-name.

==== distinguishing properties from other classes ====
Current microformats properties re-use generic terms like "summary", "photo", "updated" both for ease of use and understanding.

However, through longer term experience, we've seen sites that accidentally drop (or break) their microformats support (e.g. Upcoming.org, Facebook) because web authors sometimes rewrite all their class names, and either are unaware that microformats were in the page, or couldn't easily distinguish microformats property class names from other site-specific class names.

This issue has been reported by a number of web authors.
* See: [[issues#class-collisions]]

Thus microformats 2 uses ''prefixes'' for property class names, e.g.:
* '''p-summary''' instead of ''summary''
* '''u-photo''' instead of ''photo''
* '''dt-updated''' instead of ''updated''

Such prefixing of all microformats class names was first suggested by Scott Isaacs of Microsoft to Tantek on a visit to Microsoft sometime in 2006/2007, but specifically aimed at making microformats easier to parse. At the time the suggestion was rejected since microformats were focused on web authors rather than parsers.

However, since experience has shown that distinguishing property class names is an issue for '''both web authors and parser developers''', this is a key change that microformats 2 is adopting. See the next section for details.

=== COMMUNITY and TOOLS ===
The second most important constituency in the microformats community are the developers, programmers, tool-makers.

A non-trivial number of them have been sufficiently frustrated with some general issues with microformats that they've done the significant extra work to support very different and less friendly alternatives (microdata, RDFa). Based on this real-world data (market behavior), it behooves us to address these general issues with microformats for this constituency.

==== existing microformats parsing requirements ====
COMMUNITY and TOOLS (that) USE MICROFORMATS
* parser / parsing
* structured
* getting the data out
* json - 1:1 mapping

[[parsing]] microformats currently requires
# a list of root class names of each microformat to be parsed
# a list of properties for each specific microformats, along with knowledge of the type of each property in order to parse their data from potentially different portions of the HTML markup
# some number of format-specific specific rules (markup/content optimizations)

This has meant that whenever a new microformat is drafted/specificied/adopted, parsers need to updated to handle it correctly, at a minimum to parse them when inside other microformats and avoid errantly implying properties from one to the other (containment, [[mfo]] problem).

==== naming conventions for generic parsing ====
I think there is a fairly simple solution to #1 and #2 from the above list, and we can make progress towards minimizing #3. In short:

'''Proposal: a set of naming conventions for microformat root class names and properties that make it obvious when:'''
* a class name represents a microformat root class name
* a class name represents a microformat property name
* a class name represents a microformat property that needs special parsing (specific type of property).

In particular - derived from the real world examples of existing proven microformats (rather than any abstraction of what a schema should have)
* '''"h-*" for root class names''', e.g. "h-card", "h-event", "h-entry"
** The 'h-' prefix is based on the existing microformats naming pattern of starting with 'h'.
* '''"p-*" for simple (text) properties''', e.g. "p-fn", "p-summary"
** vocabulary generic parsing, element text in general, treat certain HTML element/attribute combination as special and use those first, e.g. img/alt, abbr/title.
** The 'p-' prefix is based on the word "property" starting with 'p'.
* '''"u-*" for URL properties''', e.g. "u-url", "u-photo", "u-logo"
** special parsing required: prefer a/href, img/src, object/data etc. attributes to element contents.
** The 'u-' prefix is based on URL/URI starting with the letter 'u', which is the type of most of these related properties.
* '''"dt-*" for datetime properties''', e.g. "dt-start", "dt-end", "dt-bday"
** special parsing required: [[value-class-pattern]], in particular separate date time value parsing for better human readabillity / DRY balance.
** The 'dt-' prefix is based on "date time" having the initials "dt" and the preponderance of existing date time properties starting with "dt", e.g. dtstart, dtend, dtstamp, dtreviewed.
* '''"e-*" for element tree properties''' where the entire contained element hierarchy is the value, e.g. "e-content" (formerly "entry-content") for [[hAtom]]. The 'e-' prefix can also be mnemonically remembered as "element tree", "embedded markup", or "encapsulated markup".
** special parsing required: follow the [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#serializing-html-fragments HTML spec: Serializing HTML Fragments algorithm] to create a serialization.

This provides a simpler transition/education story for existing microformats authors/publishers:
* "h*" to "h-*", "dt*" to "dt-*", url-like properties to "u-*", entire embedded markup to "e-*", and "p-*" for all "plain text" properties.

See [[microformats-2-prefixes]] for further thoughts and discussions on these and other class prefixes.

Example: taking that simple heading hCard example forward:

<source lang=html4strict>
<h1 class="h-card">Chris Messina</h1>
</source>

As part of microformats 2 we would immediately define root class names and property names for all existing microformats and drafts consistent with this naming convention, and require support thereof from all new implementations, as well as strongly encouraging existing implementations to adopt the simplified microformats 2 syntax and mechanism. Question: which microformats deserve explicit backward compatibility?

As a community we would continue to use the microformats [[process]] both for researching and determining the need for new microformats, and for naming new microformat property names for maximum re-use and interoperability of a shared vocabulary.

If it turns out we need a new property type in the future, we can use one of the remaining single-letter-prefixes to add it to microformats 2. This would require updating of parsers of course, but in practice the number of different types of properties has grown very slowly, and we know from other schema/programming languages that there's always some small limited number of scalar/atomic property types that you need, and using those you can create compound types/objects that represent richer / more complicated types of data. See [[microformats-2-prefixes]] for documentation of existing single-letter class name prefixes in practice.

=== ADVANTAGES ===
This has numerous advantages:
* '''better maintainability''' - much more obvious to web authors/designers/publishers which class names are for/from microformats.
* '''no chance of collision''' - for all practical purposes with existing class names and thus avoiding any need to add more complex CSS style rules to prevent unintended styling effects.
* '''simpler parsing''' - parsers can now do a simple stream-parse (or in-order DOM tree walk) and parse out '''all''' microformat objects, properties, and values, without having to know anything about any specific microformats.
* '''separation of syntax and vocabulary''' - by abstracting microformats 2 syntax independent of any vocabulary, it allows and encourages development of shared vocabularies that can work in alternative syntaxes.

More examples: here is that same heading example with name components:

<source lang=html4strict>
<h1 class="h-card">
<span class="p-fn">
<span class="p-given-name">Chris</span>
<abbr class="p-additional-name">R.</abbr>
<span class="p-family-name">Messina</span>
</span>
</h1>
</source>

with a hyperlink to Chris's URL:

<source lang=html4strict>
<h1 class="h-card">
<a class="p-fn u-url" href="http://factoryjoe.com/">
<span class="p-given-name">Chris</span>
<abbr class="p-additional-name">R.</abbr>
<span class="p-family-name">Messina</span>
</a>
</h1>
</source>

=== COMPATIBILITY ===

microformats 2 is backwards compatible in that in permits content authors to markup with both old and new class names for compatibility with old tools.

Here is a simple example:

<source lang=html4strict>
<h1 class="h-card vcard">
<span class="fn">Chris Messina</span>
</h1>
</source>

a microformats 2 parser would see the class name "h-card" and imply the one required property from the contents, while a microformats 1.0 parser would find the class name "vcard" and then look for the class name "fn". no data duplication is required. this is a very important continuing application of the <abbr title="don't repeat yourself">DRY</abbr> [[principle]].

And the above hyperlinked example with both sets of class names:

<source lang=html4strict>
<h1 class="h-card vcard">
<a class="p-fn u-url n fn url" href="http://factoryjoe.com/">
<span class="p-given-name given-name">Chris</span>
<abbr class="p-additional-name additional-name">R.</abbr>
<span class="p-family-name family-name">Messina</span>
</a>
</h1>
</source>

=== VENDOR EXTENSIONS ===

(this section was only discussed verbally and not written up during discussions - capturing here as it is topical)

Proprietary extensions to formats have typically been shortlived experimental failures with one big recent exception.

Proprietary or experimental CSS3 property implementations have been very successful.

There has been much use of border radius properties and animations/transitions which use CSS properties with vendor-specific prefixes like:

* -moz-border-radius
* -webkit-border-radius

etc.

Note that these are merely string '''prefixes''', not bound to any URL, and thus not namespaces in any practical sense of the word. This is quite an important distinction, as avoiding the need to bind to a URL has made them easier to support and use.

This use of vendor specific CSS properties has in recent years allowed the larger web design/development/implementor communities to experiment and iterate on new CSS features while the features were being developed and standardized.

The benefits have been two-fold:
* designers have been able to make more attractive sites sooner (at least in some browsers)
* features have been market / real-world tested before being fully standardized, thus resulting in better features

Implementers have used/introduced "x-" prefixes for IETF MIME/content-types for experimental content-types, MIME parameter extensions, and HTTP header extensions, per RFC 2045 Section 6.3, RFC 3798 section 3.3, and [https://secure.wikimedia.org/wikipedia/en/wiki/List_of_HTTP_header_fields#Common_non-standard_headers Wikipedia: HTTP header fields - non-standard headers] (could use RFC reference instead) respectively, like:

* application/x-latex (per [https://secure.wikimedia.org/wikipedia/en/wiki/Internet_media_type#Type_x Wikipedia Internet media type: Type x])
* x-spam-score (in email headers)
* X-Pingback (per [http://en.wikipedia.org/wiki/Pingback Wikipedia:Pingback])

Some standard types started as experimental "x-" types, thus demonstrating this experiment first, standardize later approach has worked for at least some cases:

* image/x-png (standardized as image/png, both per [http://tools.ietf.org/html/rfc2083 RFC2083])

There have been times when specific sites have wanted to extend microformats beyond what the set of properties in the microformat, and currently lack any '''experimental''' way to do so - to try and see if a feature (or even a whole format) is interesting in the real world before bothering to pursue researching and walking it through the microformats process. Thus:

'''Proposal:'''
* '*-x-' + '-' + meaningful name for root and property class names
** where "*" indicates the single-character-prefix as defined above
** where "x" indicates a literal 'x' for an experimental extension OR
** OR "x" indicates a vendor prefix (more than one character, e.g. like CSS vendor extension abbreviations, or some stock symbols, avoiding first words/phrases/abbreviations of microformats properties like dt-)
** e.g.
** "h-bigco-one-ring" - a hypothetical "bigco" vendor-specific "one-ring" microformat root class name.
** "p-goog-preptime" - to represent [http://www.google.com/support/webmasters/bin/answer.py?answer=173379 Google's "preptime" property extension] to [[hRecipe]] (aside: "duration" may be another property type to consider separate from "datetime" as it may be subject to different parsing rules.)
** "p-x-prep-time" - a possible experimental property name to be added to hRecipe upon consideration/documentation of real-world usage/uptake.

Background - this proposal is a composition of the following (at least somewhat) successful vendor extension syntaxes
* [http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords CSS 2.1 4.1.2.1 Vendor-specific extensions]
* IETF MIME/content-type "x-*" extensions per RFC 2045 Section 6.3. [http://en.wikipedia.org/wiki/Internet_media_type]
* IETF MIME experimental fields (e.g. x-spam-score)
* HTTP header extensions (e.g. x-pingback)
* note also [http://www.mnot.net/blog/2009/02/18/x- some critical thoughts from mnot]

=== USERS ===
Need more tools and interfaces that:
* publish
* copy/paste
* right-click on a microformat
* share
* search results

discussed some existing like: [[H2VX]] converts hCard to vCard, hCalendar to iCalendar

how would we re-implement Live Clipboard today, making it easier for publishers and developers?

=== SEE ALSO ===
* [[microformats2]]
* [[microformats2-brainstorming]] - moving more experimental / undeveloped / and rejected thoughts ideas here to simplify/progress *this* page further.
* [[microformats2-experimental-properties]] - listing experimental (-x- prefixed) properties and their use
* [[microformats2-prefixes]]
* [[microformats2-faq]]
* [[microformats2-parsing]]
* 2010-05-02 [[events/2010-05-02-microformats-2-0|microformats 2.0 discussion session at FOO East]]

gender-examples

2015-08-22T20:16:10Z

Myfreeweb: /* discussion elsewhere */ Add link to #genderUX

<entry-title>gender examples</entry-title>

This page documents how people currently publish [[gender]] information on the web (sometimes implicitly - so not easily machine parsable - such as names (Andrew, Andrea), titles (Mr, Mrs, Miss), relationships (husband, brother), pronouns (he, she), etc.)), and what gender terms are supported by current web user interfaces. This research will hopefully be useful to the [[genealogy]] microformat effort, as well as efforts to [[vcard-suggestions|extend vCard]], and therefore [[hcard|hCard]].

== examples ==
These examples are based on two primary sources of real world web site usage (e.g. on social network sites)

* user interfaces for editing (and displaying) [[user profile]] information
* user interfaces for doing faceted (field-based) search based on value(s) of a gender (or sex) field.

== sites and services ==

Social network sites typically publish the gender of the individual.

Sites and services that allow users to enter and publish their gender. Please add to this list.

In alphabetical order:
* [https://bagcheck.com/blog/01-the-gender-question Bagcheck] chose to ask which pronoun you want to use:
** Preferred Possessive Pronoun: ( )Her ( )His ( )Their
* [http://crush3r.com/ Crusher]'s [http://crush3r.com/account Edit My Account](requires login) page combines gender and person vs organization distinction in an interesting type picker among girl, boy, band, or other with a field.
** Type: ( ) Girl ( ) Boy ( ) Band ( ) Other: [______]
* Canada Council for the Arts (need citation to specific sign-up form URL) - [https://twitter.com/heathr/status/189492984188903424 according to Heather Gold]:
** Female, Male, Transgender, Other (please specify), No answer, Please specify [______]
** [http://twitter.com/#!/heathr/status/189492984188903424/photo/1/large http://p.twimg.com/AqE23XpCIAArFWA.png]
* [http://digg.com/ Digg]'s [http://digg.com/settings/about About Me settings page](requires login) has a Gender popup that appears to be inspired by Pownce's list:
** Guy, Girl, Dude, Lady, Fellow, Bird, Chap, grrrl, Gentleman, Damsel, Male, Female, Transgender, None of the Above
* [https://www.flirtbox.co.uk/hotornot.php?gender=f flirtbox]: "Women" and "girls"
* [http://www.eharmony.co.uk/ eHarmony]: "Woman" or "Man"
* [http://facebook.com facebook.com]: changed from "Male/Female" to Male/Female/Custom" on 2014-02-13
** custom must be from one of 56 choices, despite being a free-entry text box -
** (Agender, Androgyne, Androgynous, Bigender, Cis, Cisgender, Cis Female, Cis Male, Cis Man, Cis Woman, Cisgender Female, Cisgender Male, Cisgender Man, Cisgender Woman, Female to Male, FTM, Gender Fluid, Gender Nonconforming, Gender Questioning, Gender Variant, Genderqueer, Intersex, Male to Female, MTF, Neither, Neutrois, Non-binary, Other, Pangender, Trans, Trans*, Trans Female, Trans* Female, Trans Male, Trans* Male, Trans Man, Trans* Man, Trans Person, Trans* Person, Trans Woman, Trans* Woman, Transfeminine, Transgender, Transgender Female, Transgender Male, Transgender Man, Transgender Person, Transgender Woman, Transmasculine, Transsexual, Transsexual Female, Transsexual Male, Transsexual Man, Transsexual Person, Transsexual Woman, Two-Spirit)
** list from [http://www.slate.com/blogs/future_tense/2014/02/13/facebook_custom_gender_options_here_are_all_56_custom_options.html Will Oremus at Slate]
* [http://www.gay.com/ gay.com]: "Male", "Female", "MTF" and "FTM".
* http://www.adam4adam.com/: "Male", "Female"
* [https://plus.google.com Google+]:
** before 2014-12-10: Male, Female, Other
** after 2014-12-10: Male, Female, Decline to State, Custom - if Custom selected, a freeform text field is enabled to put in your gender. [https://plus.google.com/app/basic/stream/z12iz5ajslvxe3mup23nud451xfqcfj4l04 Post by Rachael Bennett]
* [http://www.livejournal.com/ LiveJournal]'s [http://www.livejournal.com/manage/profile/ Edit Profile](requires login) page provides a popup menu for gender with the values in order:
** (Unspecified), Male, Female
* [http://ma.gnolia.com Ma.gnolia]'s [http://ma.gnolia.com/account/profile Edit Your Profile on Ma.gnolia](requires login) page provides a popup menu for gender with the values in order:
** Female, Male, Other
* MediaWiki.org
** Radio button choice on Preferences: "(I prefer not to say)", "She edits wiki pages", "He edits wiki pages"
** [https://phabricator.wikimedia.org/T61643 Phabricator thread on non-binary gender preferences]
*[http://metatalk.metafilter.com/20050/Gender-Go-nuts-Somebody-did#838160 Cortex histogrammed] [http://metafilter.com metafilter's] 10-year-old free-form gender field- [http://stuff.metafilter.com/genders/genderfield.txt data dump]
** The first entry is blank/null fields; the difference between that and "total records" is the number of people who have put anything at all in the field: 9,325 mefites have as of a few minutes ago put something in that field. Reckoning from the previous note, that means that something like 17-18% of users have actually elected to put something in that field at some point in their membership here.
** Of the folks who have something in that field, just over 60% use one of the top four options: "male", "female", "m", or "f".
** Of the top dozen or so unambiguous labels provided, male-identifying terms (male, m, dude, xy, boy, guy, man, mail) account for about 49% of total labels used; female-identifying terms (female, f, lady, girl, xx, femme, chick) account for about 18%.
*[http://myspace.com/ MySpace.com] used to only allow male or female. There was a protest on MySpace by some genderqueer users who would put the word "genderqueer" into irrelevant metadata fields as a form of symbolic protest (source: tommorris' memory, [http://www.reddit.com/r/genderqueer/comments/1xtkq5/facebook_recognizes_nonbinary_genders_now/cfestqf reddit comment from tommorris])
*[http://www.okcupid.com/ OKCupid] - "I'm male" and "I'm female"
** This has led to a change.org petition: [https://www.change.org/petitions/ensure-that-all-okcupid-users-are-able-to-comfortably-identify-their-gender-and-sexual-orientation Ensure that all OkCupid users are able to comfortably identify their gender and sexual orientation!]
** In 2014-11, OKCupid modified the gender and sexuality options. You can now select up to five from each of the following lists
*** Gender: Woman, Man, Agender, Androgynous, Bigender, Cis Man, Cis Woman, Genderfluid, Genderqueer, Gender Nonconforming, Hijra, Intersex, Non-binary, Other, Pangender, Transfeminine, Transgender, Transmasculine, Transsexual, Trans Man, Trans Woman, Two Spirit
*** Sexuality: Straight, Gay, Bisexual, Asexual, Demisexual, Heteroflexible, Homoflexible, Lesbian, Pansexual, Queer, Questioning, Sapiosexual
*** Source: [http://www.pinknews.co.uk/2014/11/16/okcupid-begins-rolling-out-new-sexuality-and-gender-options/ pinknews.co.uk]
*[http://openid.net/specs/openid-attribute-exchange-1_0.html OpenID's Attribute Exchange] includes gender
* [http://pof.com/ POF]: "Male" or "Female"
* [http://pownce.com/ Pownce]'s [http://pownce.com/settings/ Profile Settings](requires login) interface has a Gender popup with the following values in order:
** Guy, Girl, Dude, Chicky-poo, Bloke, Bird, Lady, Gentleman, Male, Female, Transgender, None of the Above
* [http://blog.xkcd.com/2010/05/06/sex-and-gender/ XKCD] used 'do you have a Y chromosome?' as they were studying colour blindness

== government/healthcare ==

* NHS Family doctor services registration form ([http://www.nhs.uk/servicedirectories/documents/gms1.pdf GMS1]): male, female
** Individual medical practices may supplement this form with their own registration form. Some allow for non-binary options for trans and intersex individuals...
** [http://www.belgravia-surgery-sw1.nhs.uk/website/E87005/files/Under_16s_New_Patient_Questionnaire_-The_Belgravia_Surgery.pdf Belgravia Surgery] (PDF) SW1: Male or Female
** [http://www.chelwest.nhs.uk/services/hiv-sexual-health/clinics/56-dean-street Dean Street sexual health clinic]: as part of their computerised registration process, they ask whether you are transgender. If you answer 'no', they then ask whether you are male or female. This is used to determine which medical tests are conducted.
** [http://www.marvenmedicalpractice.co.uk/ Marven Medical Practice], SW1V: "male", "female", "indeterminate"
** [http://www.northamsurgery.nhs.uk/website/L83050/files/NORTHAM_SURGERY_New_Born_Registration_Form.pdf Northam Surgery] (PDF): Male or Female
** [http://www.sexualhealthoxfordshire.nhs.uk/wp-content/uploads/2014/03/registration.pdf Sexual Health Oxfordshire] (PDF): Male or Female
** [http://www.gowerplacepractice.nhs.uk/website/F83043/files/UCL-Students-Health-Registration-Form-Protected.pdf UCL Students Health Registration Form] (PDF): Male or Female
** [http://www.yorksurgeryilford.nhs.uk/website/F86657/files/New_Patient_Registration_Form_2013.pdf York Surgery, Ilford] (PDF): Male or Female

== discussion elsewhere ==
* [http://www.myspace.com/queering_gender Because gender isn't binary]
* [http://community.livejournal.com/feminist/2925885.html Social networking sites & gender identity]
* [https://meta.wikimedia.org/wiki/Survey_best_practices Survey best practices] on meta.wikimedia.org
* [http://www.glaad.org/transgender/trans101 Transgender 101], GLAAD
* [https://tranarchism.wordpress.com/2010/11/26/not-your-moms-trans-101/ Not Your Mom's Trans 101], Asher at Tranarchism
* [https://blog.wikimedia.org/2015/03/09/gender-as-a-text-field/ Gender as a text field: What Wikipedia can learn from Facebook], Amanda Menking, Wikimedia Blog, 2015-03-09
* [http://43epnd.axshare.com/gender.html #genderUX – Some guiding principles for handling gender on forms]

== see also ==
* [[gender]]
* [[gender-formats]]
* [[gender-brainstorming]]
* [[profile-examples]]

== related ==
* [[genealogy]]
* [[hcard|hCard]]
* [[vcard-suggestions]]

hatom

2012-04-15T09:42:45Z

Myfreeweb: /* Implementations */ The proxy is 410 Gone

<entry-title>hAtom 0.1</entry-title>
{{Template:DraftSpecification}}

hAtom is a microformat for content that can be syndicated, primarily but not exclusively weblog postings. hAtom is based on a subset of the [http://www.atomenabled.org/ Atom] syndication format. hAtom will be one of several [[microformats]] open standards.
__TOC__
== Draft Specification ==

<div class="vcard">
;<span class="role">Editor/Author</span>
:<span class="fn">[http://blogmatrix.blogmatrix.com/ David Janes]</span> <span class="org">([http://www.blogmatrix.com BlogMatrix, Inc.])</span>
</div>

;Contributors
:<span class="vcard"><span class="fn">[http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]</span></span>
:<span class="vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="url">http://tantek.com/</span> and before at [http://technorati.com Technorati, Inc.])</span>

[[hatom#Copyright|copyright]] and [[hatom#Patents|patents]] statements apply.

== Status ==
hAtom 0.1 is a microformats.org draft specification. Public discussion on hAtom takes place on [[hatom-feedback]], the #microformats [[irc]] channel on irc.freenode.net, and [http://microformats.org/discuss/mail/microformats-discuss/ microformats-discuss mailing list].

=== Available languages ===
The English version of this specification is the only normative version. For translations of this document see the [[#translations]] section.

=== Errata and Updates ===
Known errors and issues in this specification are corrected in [[hatom-issues-resolved|resolved]] and [[hatom-issues-closed|closed]] issues. Please check there before reporting [[hatom-issues|issues]].

The hAtom 0.2 update is currently under development and incorporates known errata corrections as well as the [[value-class-pattern]].

== Introduction ==
hAtom is a [[microformat]] for identifying semantic information in weblog posts and practically any other place [http://www.atomenabled.org/ Atom] may be used, such as news articles. hAtom content is easily added to most blogs by simple modifications to the blog's template definitions.

{{rfc-2119-intro}}

== Semantic XHTML Design Principles ==
{{semantic-xhtml-design-principles}}

== Format ==
=== In General ===
The [http://atomenabled.org/developers/syndication/#person Atom Syndication Format] provides the conceptual basis for this microformat, with the following caveats:

* Atom provides a lot more functionality than we need for a "blog post" microformat, so we've taken the minimal number of elements needed.
* the "logical" model of hAtom is that of Atom. If there is a conflict, Atom should be taken as correct.
* the "physical" model of hAtom -- the actual writing of elements -- is a lot more varied than Atom provides for, due to the variety of ways weblogs are actually produced in the wild. The hAtom microformat provides a number of rules for "bridging the gap"

=== Schema ===
Schema elements are based on the Atom nomenclature and follow the microformat pattern of prefixing a unique identifier (in this case, '<code>h</code>') on the outermost container elements -- the Feed or Entry. The parts of this microformat are based on analysis of many weblog, bulletin board and media posts and can be read [[blog-post-brainstorming#Discovered_Elements]].

The hAtom schema consists of the following:

* hfeed ('''<code>hfeed</code>'''). optional.
** '''<code>feed category</code>'''. optional. keywords or phrases, using '''[[rel-tag]]'''.
** [[hentry]] ('''<code>hentry</code>''').
*** '''<code>entry-title</code>'''. required. text.
*** '''<code>entry-content</code>'''. optional (see field description). text. [*]
*** '''<code>entry-summary</code>'''. optional. text.
*** '''<code>updated</code>'''. required using [[datetime-design-pattern]]. [*]
*** '''<code>published</code>'''. optional using [[datetime-design-pattern]].
*** '''<code>author</code>'''. required using '''[[hcard|hCard]]'''. [*]
*** '''<code>bookmark</code>''' (permalink). optional, using '''[[rel-bookmark]]'''.
*** tags. optional. keywords or phrases, using '''[[rel-tag]]'''.

[*] Some required elements have defaults if missing, see below.

=== Field and Element Details ===

===== Feed =====
* a Feed element is identified by the class name <code>hfeed</code>
* a Feed element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1 Atom feed]
* the Feed element is optional and, if missing, is assumed to be the page
* hAtom documents {{may}} have multiple Feed elements

===== Feed Category =====
* a Feed Category element is identified by [[rel-tag]]
* a Feed {{may}} have a Feed Category
* a Feed Category element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.2 Atom category] inside a [http://www.atomenabled.org/developers/syndication/#optionalFeedElements feed]
* Feed Category elements {{must}} appear inside a Feed element but not inside an Entry element
* the [[rel-tag]] <code>href</code> encodes the atom <code>category:term</code>; the link text defines the atom <code>category:label</code>

===== Entry =====
* an Entry element is identified by class name <code>hentry</code>
* an Entry element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.2 Atom entry]
* any microformat content inside a <code><blockquote></code> or <code><q></code> element within the Entry should not be considered part of the Entry.
: ''This allows quoting other microformated data without worry of corrupting the model''

===== Entry Category =====
* an Entry Category element is identified by [[rel-tag]]
* an Entry {{may}} have an Entry Category
* an Entry Category element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.2 Atom category] inside an [http://www.atomenabled.org/developers/syndication/#optionalEntryElements entry]
* the [[rel-tag]] <code>href</code> encodes the atom <code>category:term</code>; the link text defines the atom <code>category:label</code>

===== Entry Title =====
* an Entry Title element is identified by the class name <code>entry-title</code>
* an Entry {{should}} have an Entry Title
* an Entry Title element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.14 Atom entry title]
* if the Entry Title is missing, use
** the first <code><h#></code> element in the Entry, or
** the <code><title></code> of the page, if there is no enclosing Feed element, or
** assume it is the empty string

===== Entry Content =====
* an Entry Content element is identified by class name <code>entry-content</code>
* an Entry {{should}} have Entry Content
* an Entry Content element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#atomContent Atom content]
* an Entry {{may}} have 0 or more Entry Content elements. The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry
: ''Many web logs split content into multiple sections with a "Read More" link and JavaScript tricks. This is also needed in cases where Entry Titles are coded in-line and are considered part of the content.''
* if the Entry Content is missing, assume it is the empty string

===== Entry Summary =====
* an Entry Summary element is identified by class name <code>entry-summary</code>
* an Entry Summary element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.13 Atom summary]
* an Entry {{may}} have 0 or more Entry Summary elements. The "logical Entry Summary" of an Entry is the concatenation, in order of appearance, of all the Entry Summarys within the Entry

===== Entry Permalink =====
* an Entry Permalink element is identified by [[rel-bookmark]]
* an Entry {{should}} have an Entry Permalink
* an Entry Permalink element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.7 Atom link in an entry]
* if the Entry Permalink is missing, use the URI of the page; if the Entry has an "id" attribute, add that as a fragment to the page URI to distinguish individual entries

===== Entry Updated =====
* an Entry Updated element is identified by class name <code>updated</code>
* an Entry Updated element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.15 Atom updated]
* an Entry {{should}} have an Entry Updated element
* use the [[datetime-design-pattern]] to encode the updated datetime
* if there is no Entry Updated element,
** use the Entry Published element, if present
** otherwise the page is invalid hAtom

===== Entry Published =====
* an Entry Published element is identified by the class name <code>published</code>
* an Entry Published element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.9 Atom published]
* use the [[datetime-design-pattern]] to encode the published datetime

===== Entry Author =====
* an Entry Author element is represented by class name <code>author</code>
* an Entry Author element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.1 Atom author]
* an Entry Author element {{must}} be encoded in an [[hcard|hCard]]
* an Entry Author element {{should}} be encoded in an <code><address></code> element
* an Entry {{should}} have at least one Entry Author element
* an Entry {{may}} have more than one Entry Author elements
* if the Entry Author is missing
** find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
** otherwise the entry is invalid hAtom

=== XMDP Profile ===
See [[hatom-profile]].

== Examples ==

See [[hatom-examples]].

=== Examples in the wild ===

See [[hatom-examples-in-wild]].

== Implementations ==

This section is '''informative'''.

The following implementations have been developed which either generate or parse hAtom links. If you have an hAtom implementation, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page like [[hatom-implementations]].

* [http://code.google.com/p/spinn3r-client/ spinn3r-client] - implemented in [http://spinn3r.com Spinn3r] and part of [http://code.tailrank.com/feedparser FeedParser] and our announcement of [http://blog.spinn3r.com/2008/01/announcing-spin.html hAtom in Spinn3r 2.1]
* the [http://code.google.com/p/aump/ Almost Universal Microformat Parser] can extract hAtom content from webpages ([http://code.davidjanes.com/aumfp/demo/ demo])
* [http://rbach.priv.at/hAtom2Atom/ hAtom2Atom.xsl] transforms hAtom to Atom (as the name suggests.)
* [http://placenamehere.com/article/185/SubscribingTohAtomFeedsWithNetNewsWire Subscribe To hAtom] is a script that provides [http://ranchero.com/netnewswire/ NetNewsWire 2.x] users with the ability to subscribe to hAtom documents as they would any other feed. by [[User:ChrisCasciano|Chris Casciano]].
* [http://boxtheweb.mihopa.net/code/apis/#outlineclasses Outline Classes] - has GPL'ed PHP code for reading hAtom
* [http://boxtheweb.4x2.net/ BoxtheWeb] - supports subscribing to hAtom as a feed format
* There is a [http://code.google.com/p/transformr/downloads/detail?name=hatom%280.2%29.zip hAtom toolkit] that extracts hAtom, there is also a [http://transformr.co.uk/ demo here]


== Copyright ==
{{MicroFormatCopyrightStatement2005}}
* [[User:Tantek|Tantek]]: I release all my contributions to this specification into the public domain and I encourage the other authors to do so as well.
** When all authors/editors have done so, we can remove the MicroFormatCopyrightStatement template reference and replace it with the MicroFormatPublicDomainContributionStatement.

== Patents ==
{{MicroFormatPatentStatement}}

== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://www.ietf.org/rfc/rfc4287 RFC4287: The Atom Syndication Format]
* [[hcard-parsing]]
* [[rfc-2119|RFC 2119]]
* [[iso-8601|ISO8601]]

=== Informative References ===
* [http://www.atomenabled.org/ atomenabled.org]

== Further Reading ==
* [http://www.ablognotlimited.com/articles/getting-semantic-with-microformats-part-5-hatom/ Getting Semantic With Microformats, Part 5: hAtom] by [http://www.ablognotlimited.com/ Emily Lewis]

== Work in progress ==
This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. There is a separate document where we are keeping our brainstorms and other explorations relating to hAtom:

* [[blog-post-brainstorming|blog-post Brainstorming]]

=== Version 0.1 ===

Version 0.1 was released 28 February 2006.

== Discussions ==

* See [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

=== Q&A ===
* If you have any questions about hAtom, check the [[hatom-faq|hAtom FAQ]], and if you don't find answers, add your questions!

=== Issues ===
* Please add any issues with the specification to the separate [[hatom-issues|hAtom issues]] document.

==See Also==
{{hatom-related-pages}}
* [[rel-enclosure]] - how to semantically reference enclosures (e.g. podcasts) in hAtom
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-post-feed-equivalence]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[xhtml-syndication]]

[[Category:Draft Specifications]]
[[Category:hAtom]]

== Translations ==
Read the hAtom draft specification in additional <span id="languages">languages</span>:
* [[hatom-fr|français]]

hatom-profile

2012-04-15T09:41:57Z

Myfreeweb: /* Usage */ HTML5

<entry-title>hAtom Profile</entry-title>

The following is an [http://gmpg.org/xmdp/ XMDP] profile for the [[hatom|hAtom]] specification.

== URLs ==
This profile is hosted as a separate XMDP file on microformats.org:
* http://microformats.org/profile/hatom
* shortURL: http://ufs.cc/x/hatom

== Usage ==
Profiles are referenced in (X)HTML files in the <code><head></code> tag, e.g.:
<source lang=html4strict>
<head profile='http://microformats.org/profile/hatom'>
</source>
In HTML5, head[profile] has been deprecated:
<source lang=html4strict>
<head>
…
<link rel='profile' href='http://microformats.org/profile/hatom'>
</head>
</source>

== Profile ==

<source lang=html4strict>
<dl class="profile">
<dt id="rel">rel</dt>
<dd><p>
<a rel="help" href="http://www.w3.org/TR/html401/struct/links.html#adef-rel">
HTML4 definition of the 'rel' attribute.</a>
Here is an additional value as defined in the
<a rel="help start" href="http://microformats.org/wiki/rel-tag">
rel-tag</a>
specification.</p>
<dl>
<dt id="tag">tag</dt>
<dd>Indicates that the referred resource serves as a "tag",
or keyword/subject, for the referring page, or some portion of the referring page (such as an hAtom).</dd>
</dl>
</dd>
<dt>class</dt>
<dd><p>
<a href="http://www.w3.org/TR/html401/struct/global.html#adef-class">
HTML4 definition of the 'class' attribute.</a>
This meta data profile defines some 'class' attribute values (class names)
and their meanings as suggested by a
<a href="http://www.w3.org/TR/WD-htmllink-970328#profile">
draft of "Hypertext Links in HTML"</a>.
All values are defined according to the semantics defined in the
<a rel="help start" href="http://microformats.org/wiki/hatom">
hAtom specification</a>.
</p>
<dl>
<dt id="hfeed">hfeed</dt>
<dd>The root class name and container for a feed, based on the definition of atom:feed (section 4.1.1 of RFC 4287),
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>

<dt id="hentry">hentry</dt>
<dd>The root class name and container for an entry, based on the definition of atom:feed (section 4.1.2 of RFC 4287),
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>

<dt id="entry-title">entry-title</dt>
<dd>This optional property provides the title or name of an entry, based on the definition of atom:feed (section 4.2.14 of RFC 4287),
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.</dd>

<dt id="entry-summary">entry-summary</dt>
<dd>This optional property provides the summary of an entry, based on the definition of atom:summary (section 4.2.13 of RFC 4287),
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.</dd>

<dt id="entry-content">entry-content</dt>
<dd>This optional property provides the contents of an entry, based on the definition of atom:content (section 4.1.3 of RFC 4287),
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.</dd>

<dt id="author">author</dt>
<dd>This optional property provides information about the person who wrote a feed or entry. If the value is provided then the same element that
has the class name of "author" should use the class name of "vcard" and thus represent an embedded <a href="http://microformats.org/wiki/hcard">hCard</a>. This property is based loosely on the definition of atom:author (section 4.2.1 of RFC 4287),
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.</dd>

<dt id="published">published</dt>
<dd>This optional property specifies the date and time (in ISO8601 date or date-time) that an entry was originally published.
This property is based loosely on the definition of atom:published (section 4.2.9 of RFC 4287),
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.</dd>

<dt id="updated">updated</dt>
<dd>This optional property specifies the date and time (in ISO8601 date or date-time) that an entry was most recently updated.
This property is based loosely on the definition of atom:updated (section 4.2.15 of RFC 4287),
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.</dd>

<dt id="category">category</dt>
<dd>A category of the feed or entry. Publishers should also use rel-tag to indicate the precise meaning of a category with a URL.
Note: this property may be repeated (a feed or entry may belong in several categories). Re-used from hCalendar which re-uses it from iCalendar (section 4.8.1.2 of RFC 2445).
This property is also based loosely on the definition of atom:category (section 4.2.2 of RFC 4287),
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.</dd>

<dt id="value">value</dt>
<dd>This class name is used to distinguish the <em>actual</em> value
of a property from any other cruft that may be in
the containing element representing the property.
See the
<a href="http://microformats.org/wiki/value-class-pattern">
value-class-pattern</a> for details.</dd>

<dt id="value-title">value-title</dt>
<dd>This class name is used to distinguish the <em>actual</em> value
of a property, specifically in the 'title' attribute of the element,
from the element contents and the element representing
the containing property.
See the
<a href="http://microformats.org/wiki/value-class-pattern#Parsing_value_from_a_title_attribute">
value-class-pattern value-title description</a> for details.</dd>

</dl>
</dd>
</dl>
</source>

== Related Pages ==
{{hatom-related-pages}}

hcard

2011-02-02T15:35:05Z

Myfreeweb: head profile is deprecated

<entry-title>hCard 1.0</entry-title>
<dfn style="font-style:normal;font-weight:bold">hCard</dfn> is a simple, open, distributed format for representing people, companies, organizations, and places, using a 1:1 representation of vCard ([[rfc-2426|RFC2426]]) properties and values in [[semantic-xhtml|semantic HTML or XHTML]]. hCard is one of several open [[microformats|microformat]] standards suitable for embedding in HTML, XHTML, Atom, RSS, and arbitrary XML.

'''Want to get started with writing an [[hcard|hCard]]?''' Use the [http://microformats.org/code/hcard/creator hCard creator] to write up some contact information and publish it, or follow the [[hcard-authoring|hCard authoring tips]] to add hCard markup to your current contact page.

<div class="vcard">
; <span class="role">Editor</span>
: <span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="url">http://tantek.com/</span>, and before at [http://technorati.com Technorati, Inc.], and at [http://microsoft.com/ Microsoft Corporation])
</div>
; Authors: [http://tantek.com/ Tantek Çelik] (affiliations above)
: <span class="vcard"><span class="fn">[[User:Brian|Brian Suda]]</span> (<span class="url">http://suda.co.uk/</span>)</span>

; Acknowledgments: See [[hcard#Inspiration_and_Acknowledgments|acknowledgments]].

[[hcard#Copyright|copyright]] and [[hcard#Patents|patents]] statements apply.

== Status ==
hCard 1.0 is a microformats.org specification. Public discussion on hCard takes place on [[hcard-feedback]], the #microformats [[irc]] channel on irc.freenode.net, and [http://microformats.org/discuss/mail/microformats-discuss/ microformats-discuss mailing list].

=== Available languages ===
The English version of this specification is the only normative version. For translations of this document see the [[#translations]] section.

=== Errata and Updates ===
Known errors and issues in this specification are corrected in [[hcard-issues-resolved|resolved]] and [[hcard-issues-closed|closed]] issues. Please check there before reporting [[hcard-issues|issues]].

The hCard 1.0.1 update is currently under development and incorporates known errata corrections as well as the [[value-class-pattern]].

== Introduction ==
The vCard standard ([[rfc-2426|RFC2426]]), has been broadly interoperably implemented (e.g. Apple's "Address Book" application built into MacOSX).

In addition, many bloggers identify themselves by name and discuss their friends and family. With just a tad bit of structure, bloggers can discuss people in their blog(s) in such a way that spiders and other aggregators can retrieve this information, automatically convert them to vCards, and use them in any vCard application or service.

This specification introduces the '''hCard''' format, which uses a 1:1 representation of the properties and values of the aforementioned vCard standard, in semantic HTML. Bloggers can both embed hCards directly in their web pages, and style them with CSS to make them appear as desired. In addition, hCard enables applications to retrieve information directly from web pages without having to reference a separate file.

Use the [http://microformats.org/code/hcard/creator hCard creator] and copy the HTML code it generates to your blog or website to publish your contact info.

{{rfc-2119-intro}}

== Format ==
=== In General ===
The vCard standard ([[rfc-2426|RFC2426]]) forms the basis of hCard.

The basic format of hCard is to use vCard object/property names in lower-case for class names, and to map the nesting of vCard objects directly into nested HTML elements.

=== Root Class Name ===
The root class name for an hCard is "vcard". An element with a class name of "vcard" is itself called an ''hCard''.

=== Properties and Sub-properties ===
The properties of an hCard are represented by elements inside the hCard. Elements with class names of the listed properties represent the values of those properties. Some properties have sub-properties, and those are represented by elements inside the elements for properties.

=== Property List ===
hCard properties (sub-properties in parentheses like this)

'''Required:'''
* '''fn'''
* <span id="property-list-n">'''n'''<sup style="font-size:smaller">[[#note1|1]]</sup> (family-name, given-name, additional-name, honorific-prefix, honorific-suffix)</span>
Optional:
* adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, type, value)
* agent
* bday
* category
* class
* email (type, value)
* geo (latitude, longitude)
* key
* label
* logo
* mailer
* nickname
* note
* org (organization-name, organization-unit)
* photo
* rev
* role
* sort-string
* sound
* <span id="property-list-tel">tel<sup style="font-size:smaller">[[#note2|2]]</sup> (type, value)</span>
* title
* tz
* uid
* url

=== Property Notes ===
<span id="note1">[[#property-list-n|1. ^]]</span>: The 'n' property is {{optional}} if any [[hcard#Implied_.22n.22_Optimization|implied 'n' optimization rules]] are in effect.<br />
<span id="note2">[[#property-list-tel|2. ^]]</span>: tel - Authors {{may}} follow the [http://en.wikipedia.org/wiki/E.123 E.123] standard for writing values of telephone numbers. Letter values (e.g. +1-555-FORMATS) {{must}} be converted to numbers. Use an <code>abbr</code> to display letters and provide a numerical value simultaneously, e.g. <code><nowiki><abbr title="+15553676287">+1-555-FORMATS</abbr></nowiki></code>.

=== Singular vs. Plural Properties ===
Singular properties: 'fn', 'n', 'bday', 'tz', 'geo', 'sort-string', 'uid', 'class', 'rev'. For properties which are singular, the first descendant element with that class {{should}} take effect, any others being ignored.

All other properties {{may}} be plural. Each class instance of such properties creates a new instance of that property.

=== Human vs. Machine readable ===
The human visible text contents of an element for a property represents the value of that property, with a few exceptions:

If an <code><abbr></code> element is used for a property, then the '<code>title</code>' attribute (if present) of the <code><abbr></code> element is the value of the property, instead of the contents of the element, which instead provide a more human presentable version of the value.

If an <code><a></code> element is used for one or more properties, it {{must}} be treated as follows:
# For the 'photo' property and any other property that takes a URL as its value, the <code>href="..."</code> attribute provides the property value.
# For other properties, the element's content is the value of the property.

If an <code><img></code> element is used for one or more properties, it {{must}} be treated as follows:
# For the 'photo' property and any other property that takes a URL as its value, the <code>src="..."</code> attribute provides the property value.
# For other properties, the <code><img></code> element's '<code>alt</code>' attribute is the value of the property.

If an <code><object></code> element is used for one or more properties, it {{must}} be treated as follows:
# For the 'photo' property and any other property that takes a URL as its value, the <code>data="..."</code> attribute provides the property value.
# For other properties, the element's content is the value of the property.

=== Value excerpting ===
Sometimes only part of an element which is the equivalent for a property is used for the value of the property. This typically occurs when a property has a subtype, like 'tel'. For this purpose, the special class name "<code>value</code>" is used to excerpt out the subset of the element that is the value of the property. E.g. here is an hCard fragment for marking up a home phone number:<br />

vCard:
<pre><nowiki>
TEL;TYPE=HOME:+1.415.555.1212
</nowiki></pre>

hCard:
<source lang=html4strict>
<span class="tel">
<span class="type">home</span>:
<span class="value">+1.415.555.1212</span>
</span>
</source>

This hCard fragment could be displayed as:

<div style="border: thin dashed black; width: 95%; padding: .5em 1em;">
<span class="tel">
<span class="type">home</span>:
<span class="value">+1.415.555.1212</span>
</span>
</div>



=== Property Exceptions ===
vCard has several properties which either do not make sense on, or are already implied within the context of a web page. This section explains what to (not) do with them.

# vCard's '''NAME''', '''PROFILE''', '''SOURCE''', '''PRODID''', '''VERSION''' properties are defined in Sections 2.1.2, 2.1.3, 2.1.4, 3.6.3, 3.6.9 of [[rfc-2426|RFC2426]]. Content publishers {{must-not}} use these properties in their hCards, and as such, hCard consumers/parsers {{must}} IGNORE these properties if they are found within an hCard. Instead. hCard to vCard converters {{should}} use the title of the page where the hCard is found (e.g. the <code><title></code> element in HTML documents) to construct the NAME property, {{may}} output a PROFILE value of "<code>VCARD</code>" per [[rfc-2426|RFC2426]], {{should}} use the URL of the page where the hCard is found to construct the SOURCE property (e.g. perhaps as a parameter to a URL/service that converts hCards to vCards), for an output vCard stream (e.g. a .vcf file). Only services/applications that output actual vCards should write the PRODID property, with the product identifier for said service/application. Similarly, only such services/applications should write the VERSION property, with the value "3.0" (without quotes) per [[rfc-2426|RFC2426]] Section 3.6.9.

=== Organization Contact Info ===
If the "FN" and "ORG" (organization) properties have the exact same value (typically because they are set on the same element, e.g. class="fn org"), then the hCard represents contact information for a company, organization or place and {{should}} be treated as such. In this case the author also {{must-not}} set the "N" property, or set it (and any sub-properties) explicitly to the empty string "". Thus parsers {{should}} handle the missing "N" property, in this case by implying empty values for all the "N" sub-properties.

=== Implied "N" Optimization ===
Although vCard requires that the "N" property be present, the authors of the vCard specification ([[rfc-2426|RFC2426]]) themselves do not include "N" properties in their vCards near the end of the spec (p.38). This apparent contradiction can be resolved by simply allowing the "FN" property to imply "N" property values in typical cases provided in the spec. We do so explicitly in hCard.

If "FN" and "ORG" are not the same (see previous section), and the value of the "FN" property is exactly two words (separated by whitespace), and there is no explicit "N" property, then the "N" property is inferred from the "FN" property. For "FN"s with either one word see below, and for three or more, the author {{must}} explicitly markup the "N", except for the organization contact info case, [http://microformats.org/wiki/hcard#Organization_Contact_Info see above] for that.

# The content of "FN" is broken into two "words" separated by whitespace.
# The ''first'' word of the "FN" is interpreted as the "given-name" for the "N" property.
# The ''second/last'' word of the "FN" is interpreted as the "family-name" for the "N" property.
# Exception: If the first word ends in a "," comma, then the first word (minus the comma at the end) is interpreted as the "family-name" and the second word is interpreted as the "given-name".

This allows simplification in the typical case of people stating:
* given-name (space) family-name
* family-name (comma) given-name

=== Implied "nickname" Optimization ===
Due to the prevalence of the use of nicknames/handles/usernames in actual content published on the Web (e.g. authors of [[hReview|reviews]]), hCard also has an implied "nickname" optimization to handle this.

Similar to the implied "n" optimization, if "FN" and "ORG" are not the same, and the value of the "FN" property is exactly one word, and there is no explicit "N" property, then:

# The content of the "FN" {{must}} be treated as a "nickname" property value.
# Parsers {{should}} handle the missing "N" property by implying empty values for all the "N" sub-properties.

Though parsers {{must}} follow the implied nickname optimization, publishers {{should}} explicitly indicate the "nickname" even in this case, e.g.:

<source lang=html4strict>
<span class="vcard">
<span class="fn nickname">daveman692</span>
</span>
</source>

The hCard {{may}} have additional explicit "nickname" property values in addition to the implied nickname.

=== Implied "organization-name" Optimization ===
The "ORG" property has two subproperties, organization-name and organization-unit. Very often authors only publish the organization-name. Thus if an "ORG" property has no "organization-name" inside it, then its entire contents {{must}} be treated as the "organization-name".

=== Tags as Categories ===
Categories in hCard {{may}} be represented by tags with [[rel-tag]]. When a category property is a rel-tag, the tag (as defined by rel-tag) is used for that category.

=== type subproperty values ===
The 'type' subproperty in particular takes different values depending on which property it is a subproperty of. These 'type' subproperty values are case-INSENSITIVE, meaning "Home" is the same as "home", as well as multivalued, e.g. a tel can be home and preferred:

vCard:
<pre><nowiki>
TEL;TYPE=HOME,PREF:+1.415.555.1212
</nowiki></pre>

hCard:
<source lang=html4strict>
<span class="tel"><span class="type">Home</span> (<span class="type">pref</span>erred):
<span class="value">+1.415.555.1212</span>
</span>
</source>

This could be displayed as:

<div style="border: thin dashed black; width: 95%; padding: .5em 1em; ">
<span class="tel"><span class="type">Home</span> (<span class="type">pref</span>erred):
<span class="value">+1.415.555.1212</span>
</span>
</div>

==== type with unspecified value ====
When the type of a property is specified, and there is no explicit value specified, then everything in the property except for the type is considered the value of the property. E.g.

<source lang=html4strict>
<span class="tel"><span class="type">Home</span> +1.415.555.1212</span>
</source>

is equivalent to:

<source lang=html4strict>
<span class="tel"><span class="type">Home</span><span class="value"> +1.415.555.1212</span></span>
</source>

And thus the type is "home" and the value is "+1.415.555.1212".

==== adr tel email types ====
The following lists are ''informative''. See [[rfc-2426|RFC2426]] sections 3.2.1 ADR, 3.3.1 TEL, and 3.3.2 EMAIL respectively for normative type values. They are repeated here for convenience. Default type subproperty value(s) is(are) first in each list and indicated in ALL CAPS. types may be multivalued.

* adr type: INTL, POSTAL, PARCEL, WORK, dom, home, pref
* tel type: VOICE, home, msg, work, pref, fax, cell, video, pager, bbs, modem, [http://flickr.com/photos/tags/carcellphone/ car], isdn, pcs
* email type: INTERNET, x400, pref

=== Profile ===
The hCard <span id="XMDP_Profile">XMDP profile</span> is at http://microformats.org/profile/hcard

Content that uses hCard {{should}} reference this profile, e.g.
<source lang=html4strict>
<link rel="profile" href="http://microformats.org/profile/hcard">
</source>
or
<source lang=html4strict>
This content uses <a rel="profile" href="http://microformats.org/profile/hcard">hCard</a>.
</source>
or
<source lang=html4strict>
<head profile="http://microformats.org/profile/hcard">
</source>
(profile attribute is deprecated in HTML5)
Content may combine the above methods as well.

=== Parsing Details ===

See [[hcard-parsing|hCard parsing]].

== Examples ==

This section is informative.

=== Sample vCard ===

Here is a sample vCard:

<pre><nowiki>
BEGIN:VCARD
VERSION:3.0
N:Çelik;Tantek
FN:Tantek Çelik
URL:http://tantek.com/
END:VCARD
</nowiki></pre>

and an equivalent in hCard with various elements optimized appropriately. See [[hcard-example1-steps| hCard Example 1]] for the derivation.

<source lang=html4strict>
<div class="vcard">
<a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
</div>
</source>

This hCard might be displayed as:
<div style="border: thin dashed black; width: 95%; padding: .5em 1em;">
[http://tantek.com/ Tantek Çelik]
</div>

Note: The version information is unnecessary in hCard markup directly since the version will be defined by the profile of hCard that is used/referred to in the 'profile' attribute of the <head> element.

===Live example===

Here is [http://www.commerce.net/ Commercenet]'s contact details, as a live hCard which will be detected, on this page, by microformat parsing tools:

<div class="vcard">
<div class="fn org">'''CommerceNet'''</div>
<div class="url">'''<nowiki>http://www.commerce.net/</nowiki>'''</div>
<div class="adr">'''<span class="type">Work</span>:'''
<div class="street-address">'''169 University Avenue'''</div>
<span class="locality">'''Palo Alto'''</span>, <span class="region">'''CA'''</span>  <span class="postal-code">'''94301'''</span>
<div class="country-name">'''USA'''</div>
</div>
<div class="tel">'''<span class="type">Work</span> +1-650-289-4040'''</div>
<div class="tel">'''<span class="type">Fax</span> +1-650-289-4041'''</div>
<div>'''Email <span class="email"><nowiki>info@commerce.net</nowiki></span>'''</div>
</div>

The mark-up, emboldening omitted for clarity, with the following semantic improvements:
* <code>abbr</code> to expand abbreviations
* hyperlinking the org name with the url

<source lang=html4strict>
<div class="vcard">
<a class="fn org url" href="http://www.commerce.net/">CommerceNet</a>
<div class="adr">
<span class="type">Work</span>:
<div class="street-address">169 University Avenue</div>
<span class="locality">Palo Alto</span>,
<abbr class="region" title="California">CA</abbr>  
<span class="postal-code">94301</span>
<div class="country-name">USA</div>
</div>
<div class="tel">
<span class="type">Work</span> +1-650-289-4040
</div>
<div class="tel">
<span class="type">Fax</span> +1-650-289-4041
</div>
<div>Email:
<span class="email">info@commerce.net</span>
</div>
</div>
</source>

=== More Examples ===
See [[hcard-examples|hCard examples]] for more examples, including all examples from vCard [[rfc-2426|RFC2426]] converted into hCard.

== Examples in the wild ==
This section is '''informative'''. The number of hCard examples in the wild has expanded far beyond the capacity of being kept inline in this specification. They have been moved to a [[hcard-examples-in-wild|separate page]].

See [[hcard-examples-in-wild|hCard Examples in the wild]].

== Implementations ==
This section is '''informative'''. The number of hCard implementations has also expanded beyond the capacity of keeping them inline. They have been moved to a [[hcard-implementations|separate page]].

See [[hcard-implementations|hCard Implementations]].

== Articles ==
This section is <strong>informative</strong>. For <span id="Further_Reading">further reading</span> on hCard see [[hcard-articles]].

==Buttons==
You can use these buttons on pages with hCards. See [[buttons#hCard]] for any recent additions.

* http://www.crowley.nl/images/hcard.png (mirror: http://www.davidjanes.com/images/mf_hcard.png)
* http://rbach.priv.at/2006/buttons/hcard.png
* http://www.boogdesign.com/images/buttons/microformat_hcard.png
* CSS-powered button, as evidenced at [http://re-run.com/about/microformat-badges microformat badges @ re-run]

== Copyright ==
Per the public domain release on the authors' user pages ([[User:Tantek|Tantek Çelik]], [[User:Brian|Brian Suda]]) this specification is released into the public domain.

{{MicroFormatPublicDomainContributionStatement}}

== Patents ==
{{MicroFormatPatentStatement}}

== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://www.ietf.org/rfc/rfc2426.txt vCard RFC2426]
* [http://www.itu.int/rec/T-REC-E.123-200102-I/en ITU recommendation E.123] format of telephone numbers (chargeable document)
* [[rfc-2119|RFC 2119]]

=== Informative References ===
This section is '''informative'''.
* [[hcard-history|hCard history]]
** [http://wiki.oreillynet.com/foocamp04/index.cgi?SimpleSemanticFormats FOO Camp 2004 Simple Semantic Formats presentation, 2004-09-10]
** [http://tantek.com/log/2004/09.html#hcard hCard term introduced and defined on the Web, 2004-09-30]
** Contributed from http://developers.technorati.com/wiki/hCard 2005-06-20
* [http://www.dante.net/np/ds/osi/9594-6-X.520.A4.ps X.520 in Postscript] ([http://72.14.253.104/search?q=cache:FjqzsFu4h20J:www.dante.net/np/ds/osi/9594-6-X.520.A4.ps HTMLization courtesy of Google Cache]) - vCard refers to ROLE as being "based on the X.520 Business Category explanatory attribute".
* [http://www.w3.org/2002/12/cal/rfc2426 HTML reformatted version of RFC2426]
* [http://w3.org/TR/REC-CSS1 CSS1]
* [http://www.w3.org/TR/xhtml11 XHTML 1.1]
* [http://en.wikipedia.org/wiki/E.123 Wikipedia summary of ITU-T Recommendation E.123] - for "TEL" values.
* [http://www.imc.org/pdi/ Internet Mail Consortium Personal Data Interchange vCard and vCalendar]
* [[iso-8601|ISO8601]]

==== Specifications That Use hCard ====
* [[adr]]
* [[geo]]
* [[hcalendar|hCalendar]]
* [[hreview|hReview]]

==== Similar Work ====
This section is '''informative'''.
* [http://www.intertwingly.net/wiki/pie/PaceBetterPersonElement Atom PaceBetterPersonElement]
* [http://www.jabber.org/jeps/jep-0054.html JEP-0054: vcard-temp]

== Inspiration and Acknowledgments ==
This section is '''informative'''.
Thanks to: my good friend [http://vadim.com/ Vadim] who introduced me to vCard ''many'' years ago, and if I'd only paid more attention then, perhaps I could have helped a lot of people avoid wasting a lot of time reinventing various standards wheels.

== Notes on derivation from vCard ==
This section is ''informative''.

<div id="Semantic_XHTML_Design_Principles">See: [[hcard-design-methodology]].</div>

=== More Semantic Equivalents ===
For some properties there are HTML elements which better match and convey their semantics. The following properties SHOULD be encoded with the following HTML:
* <code>URL</code> in vCard becomes <code><a class="url" href="...">...</a></code> inside the element with <code>class="vcard"</code> in hCard.
* Similarly, <code>EMAIL</code> in vCard becomes <code><nowiki><a class="email" href="mailto:...">...</a></nowiki></code>
* <code>PHOTO</code> in vCard becomes <code><img class="photo" src="..." alt="Photo of ..." /></code> or <code><object class="photo" data="..." type="...">Photo of ...</object></code>
* <code>UID</code> in vCard simply becomes another semantic applied to a specific URL (or EMAIL) for an hCard.

=== Singular and Plural derivations ===
The [[hcard#Singular_vs._Plural_Properties|lists of singular and plural properties]] have been derived by analyzing the semantics of the individual properties in vCard RFC2426 and determining logically that they MUST be singular per their semantics. See [[hcard-singular-properties]] for explanations.

==== Plural Properties Singularized ====
Since plural property names become their singular equivalents, even if the original plural property permitted only a single value with multiple components, those multiple components are represented each with their own singularly named property and the the property is effectively multivalued and subject to the above treatment of multivalued properties.

== Related Pages ==
{{hcard-related-pages}}

[[Category:Specifications]]
[[Category:hCard]]

== Translations ==
Read the hCard specification in additional <span id="languages">languages</span>:
* [[hcard-fr|français]]
* [[hcard-ru|Русский]]
* [[hcard-ja|日本語]]
* [[hcard-zh|漢語]]