Microformats Wiki - User contributions [en]

microformats2

2017-05-25T13:36:15Z

Benthatmustbeme: /* Ruby */ add link to live input version

<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

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

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

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

2017-05-19T14:31:44Z

Benthatmustbeme: /* Implementations */ move ruby to production parser

<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

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

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

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

code-tools

2017-05-04T13:08:40Z

Benthatmustbeme: Undo revision 66286 by Rosannaberardi (Talk)

<entry-title>Code & Tools</entry-title>
== Code Generators ==
There are a few tools available to help you generate microformatted code:

* [http://microformats.org/code/hcard/creator hCard creator]
* [http://microformats.org/code/hcalendar/creator hCalendar creator]
* [http://microformats.org/code/hreview/creator hReview creator]

The [http://gmpg.org/xfn/creator XFN creator] is a Web-based interface for quickly creating a link with the proper XFN values. It has been translated into the following languages:
* [http://gmpg.org/xfn/creator-fr French] as translated by Serge K. Keller
* [http://gmpg.org/xfn/creator-it Italian] as translated by Serge K. Keller and [http://www.caeciliana.ch/ Cécile Matthey]
* [http://gmpg.org/xfn/creator-es Spanish-Argentina] as translated by [http://ultimorender.com.ar/funkascript/ Manuel Razzari]
* [http://gmpg.org/xfn/creator-nl Dutch] as translated by [http://www.budts.be/weblog Jeroen Budts]
* [http://gmpg.org/xfn/creator-cs Czech] as translated by [http://www.zapisky.info/ Josef Petrák]
* [http://gmpg.org/xfn/creator-ja Japanese] as translated by [http://kidachi.kazuhi.to/ Kazuhito Kidachi]

== Validation Testing Tools ==
{{main|validators}}
You can check how your markup will be parsed by using the [http://waterpigs.co.uk/php-mf2/ php-mf2] tool. It will take markup and show you the JSON interpretation.

If you want to check markup as it is interpreted from your page you can check out the [http://microformat2-node.jit.su/ microformat-node] tool. It will grab your page and show you all found microformats that are supported by the tool.

== See Also ==
* [[browsers]]
* [[search-engines]]
* [[validators]]
* [[microformats2]]
* [[microformats2#Parsers]]

code-tools

2017-05-04T13:08:07Z

Benthatmustbeme: Undo revision 66287 by Adamvoges (Talk)

Canadian Immigrating to USA
Berardi immigration provides the highest level of immigration services and respect to the clients. Our Immigration Law firm focuses on serving [http://www.berardiimmigrationlaw.com/services/us-immigration-for-canadians Canadians immigrating to USA]. Contact Berardi immigration law for helping the Canadians with the complex issues of Canadian immigrating to USA.
For more info, you can visit my site: http://www.berardiimmigrationlaw.com

h-review

2017-05-01T13:43:23Z

Benthatmustbeme: /* Backward Compatiblity */ correct name

<entry-title>h-review</entry-title>
<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-review</dfn> is a simple, open format for publishing reviews on the web. h-review is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML/HTML5 on the web.

h-review is the [[microformats2]] update to [[hReview]].

{{cc0-owfa-license}}

== Example ==
Here is a simple review example:

<source lang=html4strict>
<div class="h-review">
<h1 class="p-name">Microformats: is structured data worth it?</h1>

<blockquote>
<a class="p-item h-item" href="http://microformats.org">Microformats</a> are the simplest way to publish structured data on the web.
</blockquote>

<p>
<data class="p-rating" value="5">★★★★★</data>
Published <time class="dt-published" datetime="2013-06-12 12:00:00">12<sup>th</sup> June 2013</time>
by <a class="p-author h-card" href="http://example.com">Joe Bloggs</a>.
</p>

<div class="e-content">
<p>Yes, microformats are undoubtedly great. They are the simplest way to markup structured data in HTML and reap the benefits thereof, including using your web page as your API by automatic conversion to JSON. The alternatives of microdata/schema and RDFa are much more work, require more markup, and are more complicated (harder to get right, more likely to break).</p>
</div>
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-review"
],
"properties": {
"name": [
"Microformats: is structured data worth it?"
],
"item": [
{
"value": "Microformats",
"type": [
"h-item"
],
"properties": {
"name": [
"Microformats"
],
"url": [
"http://microformats.org"
]
}
}
],
"rating": [
"5"
],
"published": [
"2013-06-12 12:00:00"
],
"author": [
{
"value": "Joe Bloggs",
"type": [
"h-card"
],
"properties": {
"name": [
"Joe Bloggs"
],
"url": [
"http://example.com"
]
}
}
],
"content": [
{
"value": "Yes, microformats are undoubtedly great. They are the simplest way to markup structured data in HTML and reap the benefits thereof, including using your web page as your API by automatic conversion to JSON. The alternatives of microdata/schema and RDFa are much more work, require more markup, and are more complicated (harder to get right, more likely to break).",
"html": "<p>Yes, microformats are undoubtedly great. They are the simplest way to markup structured data in HTML and reap the benefits thereof, including using your web page as your API by automatic conversion to JSON. The alternatives of microdata/schema and RDFa are much more work, require more markup, and are more complicated (harder to get right, more likely to break).</p>"
}
]
}
}
]
}
</source>

=== Get started ===
The class '''<code>h-review</code>''' is a ''root class name'' that indicates the presence of an h-review.

'''p-name''', '''p-item''', '''p-rating''', '''dt-published''', '''p-author''', '''e-content''' and the other property class names listed below defined elements as ''properties'' of the h-review.

The class '''<code>h-item</code>''' is a ''root class name'' that indicates an embedded '''[[h-item]]''' for the p-item property.

The class '''<code>h-card</code>''' is a ''root class name'' that indicates an embedded '''[[h-card]]''' for the p-author property.

See [[microformats2-parsing]] to learn more about property class names.

== Properties ==
h-review properties, inside an element with class '''h-review''':

* '''<code>p-name</code>''' - name of the review
* '''<code>p-item</code>''' - thing been reviewed, including embedded microformat for e.g. 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-author</code>''' - person who authored the review, optionally with an embedded [[h-card]]
* '''<code>dt-published</code>''' - date time of when the review was written and published
* '''<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-content</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>''' - review permalink URL

All properties are optional.

== Status ==
'''h-review''' is a microformats.org draft specification. Public discussion on h-review takes place on [[h-review-feedback]] and the #microformats [[irc]] channel on irc.freenode.net.

h-review is ready to use.

== Property Details ==
(stub, add any property explanations here)

== Examples in the Wild ==
* … add any h-review examples you find in the wild
* https://cleverdevil.io/2015/blood-rites-book-six-of-the-dresden-files

== Implementations ==
* [https://github.com/cleverdevil/Known-Reviews Reviews plugin for Known CMS] by [https://cleverdevil.io Jonathan LaCour].
** [https://github.com/cleverdevil/Known-Reviews/pull/4 pending pull request to sync with spec update 2016-05-29] -t

== Validating ==
{{h-spec-section-validating}}

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[hReview]] classnames on an h-review permalink page in addition to the more future-proof h-review properties, for example:

<source lang=html4strict>
<div class="h-review hreview">
<h1 class="p-name fn">My great review</h1>
</div>
</source>

=== Parser Compatibility ===
Microformats parsers should detect classic properties and parse them as microformats 2 properties. If an "h-review" is found, don't look for an "hReview" on the same element.

Compatibility root class name: hreview

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>item</code> (without vcard, vevent, hproduct) - parse as '''p-item h-item''' including backcompat nested properties:
** <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>item vcard</code> - parse as '''p-item h-card''' including backcompat [[hCard]] parsing
* <code>item vevent</code> - parse as '''p-item h-event''' including backcompat [[hCalendar]] vevent property parsing
* <code>item hproduct</code> - parse as '''p-item h-product''' including backcompat [[hProduct]] parsing
* <code>reviewer</code> - parse as '''p-author''', including compat root vcard in the absence of h-card
* <code>dtreviewed</code> - parse as '''dt-published'''
* <code>rating</code>
* <code>best</code>
* <code>worst</code>
* <code>description</code> - parse as '''e-content'''
* <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.

=== prior property names ===
There may be a handful of h-reviews out there (only one known so far) that use prior h-review property names. Parsers encountering these *may* interpret them as follows:

* <code>dt-reviewed</code> treat as a fallback for '''<code>dt-published</code>'''
* <code>e-description</code> treat as a fallback for '''<code>e-content</code>'''
* <code>p-reviewer</code> treat as a fallback for '''<code>p-author</code>'''

== Background ==
h-review is based on the existing [[hReview]] specification.

== See Also ==
* [[microformats2]]
* [[h-card]]
* [[h-event]]
* [[h-adr]]
* [[h-geo]]
* [[h-product]] can all be embedded in h-review as the p-item
* [[h-item]] is a minimal microformat in case none of the others suitably represent the item being reviewed

[[Category:Draft Specifications]]

h-adr

2017-05-01T13:31:52Z

Benthatmustbeme: /* Backward Compatiblity */ typo

<entry-title>h-adr</entry-title>
<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-adr</dfn> is a simple, open format for publishing structured locations such as addresses, physical and/or postal. h-adr is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML/HTML5 on the web.

h-adr is the [[microformats-2]] update to [[adr]]. It is most commonly used as part of an [[h-card]] or [[h-event]].

For named addresses, e.g. people or venues, use [[h-card]].

{{cc0-owfa-license}}

== Example ==
Here is a simple postal address example:

<source lang=html4strict>
<p class="h-adr">
<span class="p-street-address">17 Austerstræti</span>
<span class="p-locality">Reykjavík</span>
<span class="p-country-name">Iceland</span>
<span class="p-postal-code">107</span>
</p>
</source>

Parsed JSON:

<source lang=javascript>
{
"items": [
{
"type": [
"h-adr"
],
"properties": {
"street-address": [
"17 Austerstræti"
],
"locality": [
"Reykjavík"
],
"country-name": [
"Iceland"
],
"postal-code": [
"107"
],
"name": [
"17 Austerstræti Reykjavík Iceland 107"
]
}
}
]
}
</source>

The implicit "name" property that is generated from parsing an h-adr is there for consuming applications to have a simple flattened string representation of an h-adr.

For an explicitly named address (such as a mailing address to a specific person), use [[h-card]].

=== Get started ===
The class '''<code>h-adr</code>''' is a ''root class name'' that indicates the presence of an h-adr.

'''p-street-address''', '''p-locality''', '''p-country-name''', '''p-postal-code''' and all the other h-adr property class names listed below define properties of the h-adr.

See [[microformats-2-parsing]] to learn more about property class names.

== Properties ==
h-adr properties, inside an element with class '''h-adr''':
* '''<code>p-street-address</code>''' - house/apartment number, floor, street name
* '''<code>p-extended-address</code>''' - additional street details
* '''<code>p-post-office-box</code>''' - post office mailbox
* '''<code>p-locality</code>''' - city/town/village
* '''<code>p-region</code>''' - state/county/province
* '''<code>p-postal-code</code>''' - postal code, e.g. ZIP in the US
* '''<code>p-country-name</code>''' - should be full name of country, country code ok
* '''<code>p-label</code>''' - a mailing label, plain text, perhaps with preformatting
* '''<code>p-geo</code>''' (or u-geo with a RFC 5870 geo: URL), optionally embedded [[h-geo]]
* '''<code>p-latitude</code>''' - decimal latitude
* '''<code>p-longitude</code>''' - decimal longitude
* '''<code>p-altitude</code>''' - decimal altitude - new in vCard4 (RFC6350)

All properties are optional.

* '''<code>p-name</code>''' - there is no "p-name" property in h-adr. If your address has an explicit name, it's likely a venue, and you should use [[h-card]] instead.

== Status ==
'''h-adr''' is a microformats.org draft specification. Public discussion on h-adr takes place on [[h-adr-feedback]] and the #microformats [[irc]] channel on irc.freenode.net.

h-adr is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-adrs up with classic [[adr]] classnames.

== Property Details ==
(stub, add any property explanations here)

== Examples in the Wild ==
* … add any h-adr examples you find in the wild

== Validating ==
{{h-spec-section-validating}}

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[adr]] classnames in addition to the more future-proof h-adr properties, for example:

<source lang=html4strict>
<p class="h-adr adr">
<span class="p-street-address street-address">123 Main St.</span>,
<span class="p-locality locality">Pleasantville</span>
...
</p>
</source>

The class '''<code>adr</code>''' is a ''backward compatible root class name'' that indicates the presence of an [[adr]].

'''street-address''', '''locality''', and all the other backward compatibility adr property class names are listed below.

=== Parser Compatibility ===
Microformats parsers should detect classic properties only if a classic root class name is found and parse them as microformats2 properties.

If an "h-adr" is found, don't look for an "adr" on the same element.

Compatibility root class name: adr

Properties: (parsed as p- plain text unless otherwise specified)

* post-office-box
* extended-address
* street-address
* locality
* region
* postal-code
* country-name

== FAQ ==
=== What about country codes ===
Q: When marking up an address, can p-country-name be used to markup two letter country codes like "UK"? Or others like 3 letter Olympic country codes?

A: In short yes. You can do:
<source lang=html4strict>
<span class="p-country-name">UK</span>
</source>
However it's better if you mark it up with the <code>abbr</code> element and provide the full name as well, e.g.
<source lang=html4strict>
<abbr class="p-country-name" title="United Kingdom">UK</abbr>
</source>

Consuming applications may interpret any 2-3 character country-name per the table of 2-3 character [http://en.wikipedia.org/wiki/ISO_3166-1#Officially_assigned_code_elements country codes in ISO3166].

== Background ==
h-adr is based on the existing [[adr]] specification, which was extracted from [[hCard]] in order to allow it to be used for applications other than contact information.

== See Also ==
* [[microformats2]]
* [[h-geo]] can be embedded in h-adr
* [[h-card]] and [[h-event]] often contain h-adr
* [[vcard]] (most recently vCard4 RFC6350) vocabulary is re-used by h-adr.

[[Category:Draft Specifications]]

microformats2-parsing-faq

2017-05-01T13:30:18Z

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

<entry-title>microformats2-parsing-faq</entry-title>

This page documents answers to frequently (or expected to be) asked questions about [[microformats2-parsing]].

For questions about [[microformats2]] in general, see [[microformats2-faq]].

== questions ==
=== which backcompat root classes ===
Q: Which backcompat root classes should a [[microformats2]] parser support?

A: The microformats2 specification lists [[microformats2#v2_vocabularies|which microformats2 vocabularies are ready for use]], and each of those lists their classic microformat (if any) that has sufficiently broad use and support to be included in the set of backcompat root classes that a [[microformats2]] parser should support. Here they are in a list: (each is linked to the backcompat parsing section in its respective microformats2 vocabulary specification)

* [[h-adr#Backward_Compatibility|adr]]
* [[h-geo#Backward_Compatibility|geo]]
* [[h-entry#Backward_Compatibility|hentry]]
* [[h-product#Backward_Compatibility|hproduct]]
* [[h-recipe#Backward_Compatibility|hrecipe]]
* [[h-resume#Backward_Compatibility|hresume]]
* [[h-review#Backward_Compatibility|hreview]]
* [[h-review-aggregate#Backward_Compatibility|hreview-aggregate]]
* [[h-card#Backward_Compatibility|vcard]]
* [[h-event#Backward_Compatibility|vevent]]

=== normalizing u-* property values ===
Q: In the [[microformats2-parsing#parsing_a_u-_property|Parsing u-* section]], shouldn't item 5 (if there is a gotten value…) be at the end of the section? Shouldn't normalizing apply wherever the value comes from? (question from IRC, 2012-296).

A: Normalizing u-* property values occurs exactly where necessary and no more. In particular, normalizing only when present in URL attributes follows the semantics of those attributes (normalization to absolute URLs) per the [[HTML5]] specification, whereas when the value is present in a title attribute or in text, the expectation, in both normal usage and in the browser, is that such values are displayed and used as is without any normalization.

=== checking for explicit properties before implying ===
Q: When checking for whether or not to look for implied properties, should the parser look for an explicit "p-name" in particular or "*-name" in the list of parsed property names?

A: Before implying a "name" property, look for the unprefixed property, e.g. "name", not "p-name" nor "*-name".

In the JSON set of parsed property names, there are no prefixes (e.g. see the "Parsed JSON" examples in [[microformats2]]).

The order of operations in the parsing algorithm is explicit about this: parsers only imply properties ''after'' parsing an element for all explicit properties, per [[microformats2-parsing#parse_an_element_for_microformats|parse an element for microformats]].

Parsing for implied properties specifically refers to "name", "photo", and "url": [[microformats2-parsing#parsing_for_implied_properties|parsing for implied properties]] - all unprefixed versions of the property names.

The p- u- dt- e- prefixes are basically parse-time directives that are dropped once parsing is done and you collect the properties/values into your JSON parse tree.

=== empty property values ===
Q: [[microformats2-parsing]] lists many selectors of the form "abbr.p-x[title]". Is this intended to also match attributes with empty values?

A: Yes, the assumption is that the inclusion of an empty attribute value was a deliberate action by the author.

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

A: We have an answer.

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

citation-irc-notes-2006-04-09

2017-04-30T13:56:01Z

Benthatmustbeme: Undo revision 66281 by Cvkitssupplise (Talk) link spam

[[citation-irc-meetup|An irc discussion was held]].

== Summary ==

A citation microformat needs to cover four uses:

# full, bibliographic citations, eg "The Title Of An Article. Smith J. Journal Title (1987). 46:1; 23-35." This is the main citation microformat and should contain all the information necessary to locate the item and create a text citation in all the common formats (MLA, APA, etc).
# minimal, inline citations in text, eg (Smith, 1987). These generally link to an item in the bibliography using a fragment identifier.
# full, inline citations in text, eg following a blockquote.
# description of the current item/page, including title, creator, date etc.

* I disagree with this last requirement (description of the current item/page). A citation is IMHO a reference to a work *somewhere-else*. It is a reference to a work from *another* work. This is quite a different case than a work describing itself. For info about a work in the work itself, see for example [[blog-description-examples]]. -Tantek
** [http://rbach.priv.at/Microformats-IRC/2006-04-09#T192302 the SELF description was discussed] in the meet-up. The idea behind encoding all the attributes for the current page/item was to allow OTHERS to extract citation data from your page for their own use. Why should i re-key all the data about the article if i can simple convert the article to a citation itself! This should require no additional work or fields - their will be no properties unique to the SELF that are already not expressed in the base citation microformat. -[http://suda.co.uk/ brian]
*** I understand the desire to help automate this, but that means that it would be nice to have a transform from the self-description of a work, to a citation of the work. That transform doesn't necessarily have to be the identity transform, hence the last requirement shouldn't be a requirement. -Tantek
**** Your point that a citation is a reference to an outside source is right Tantek, but that doesn't mean that the description of self should be ANY different than that of an extraneous document, save for the fact that we call it a "citation." I think this may well have been why Ed bruoght up the idea of an hDC, where we end up thinking of hCite as more-or-less a sort of wrapper for other microformats (hCard, hCal, etc.). -Bruce
***** But we are not talking about "should be ANY different". We are talking about "should be SAME". My point is that it should NOT be a *requirement* for *citations* per se. The recognition that people will want to cite works is a good one, and thus when working on any "description" type format for a work describing itself, *that* work should look to the citation microformat and be sure to specify a transform, i.e. how to create a citation from a description. The easiest thing *might* be to simply embed a citation, but that is up to the description format, not up to the citation format, and thus should NOT be a requirement for the citation format. My guess is that most description formats will be a superset of what a general purpose citation has in it.
****** Consider the example of an article that contains within the page something along the lines of "Please cite this article as: The Title Of An Article. Smith J. Journal Title (1987). 46:1; 23-35.". That's both a citation and a description of the current page, and it should be marked up as such. --AlfEaton
******* Alf, that's a theoretical example, so we should not consider it as a requirement. If you can find 80/20 examples in the real world (published on the Web) that contain such a "suggested citation", please add those examples to [[citation-examples]].
******** Sigh, this is all sounding a bit patronizing Tantek. It's not a "theoretical example"; just Google for the phrase "please cite this article." But I'll add an example or two to the examples page. -- bruce
* In addition, naming a document "-recommendation" at this point is quite premature, especially when there is much work to be done in both doing the work and cleaning up of [[citation-examples]], [[citation-formats]], and [[citation-brainstorming]]. If this is meant to be a record of notes or a summary of a discussion, then it should be a notes page, e.g. see for example [[geo-bof-2005-06-30]]. Thanks, -Tantek
** I will write-up the notes for the irc-meeting shortly and post them to the appropriate place. In the mean-time the general consenus was that we have closed on the exploration phase of the citation microformat. We have solid goals and are moving to implementation. Admittably the citation pages need some serious clean-up, but there is no need to halt progress in the development/itteration phase for those who are helping to move forward the format. -[http://suda.co.uk/ brian]
*** Considering any "exploration" "closed" regarding a microformat makes no sense at all when the work to complete the necessary pages per the [[process]] has yet to happen. I'm moving this page to a name more reflecting of its consideration within the process, just notes. -Tantek

== Notes from the Meetup ==
NOTES for the 2006-04-09 IRC Citation meetup

ATTENDEES:
* briansuda
* bretonslivka
* darcusb
* dchud
* edsu
* fresco
* rsinger

=== Discussion Topics: ===
==== What is a citation? ====

Before launching into building a citation microformat, everyone should be on the same page as to what we are trying to define. So our working definition of a citation is:

citation: a short description that points to a fuller description elsewhere, either in a note or a reference list

reference item: a fuller description; also called a bibliographic entry or item

bibliography: a collection of citations

see: http://wiki.services.openoffice.org/wiki/Bibliographic_Project%27s_Developer_Page#Terminology

==== Scope of this microformat ====
3 Areas discussed:

1. citation information about the current page

2. citation information about a cited reference

3. inline citations, a form of #2

(these are 3 views of the same data)

Reuse of existing microformats, hCard for authors and publishers, hCalendar for dates and times.

Not a flat model.

==== Formats discussed: ====
* DC
** Not strong enough by itself
** Most basic properties

* DC+DCQ
** can be used for the locators (pages, volumes, etc.).
** The primary things from DCQ is the date stuff and the crucial isPartOf relation

* OpenURL
** openurl uses community profiles, each with their own schema some of which borrow vocabulary from each other, each their own standalone document
** Openurl is good for getting granularity, whether or not openurl is used or not isn't all that important as long as the microformat creates a model that's 'compatible' with openurl

* OpenDocument
** OpenDocument, there has been talk of adding an extensible metadata system based around modules, with default ones for DC and DCQ.

* PRISM
** One problem with PRISM is the that the "number" property is problematic. It should distinguish issue and document numbers

* MODS

==== Other ideas: ====
The core set of properties should account for the following basic structures:
* References
* Collections
* Events (this can be handled by hCalendar)
* Agents (this can be handled by hCard)

Collection includes subclasses like Periodical (and in turn Journal and such) and Series.
http://purl.org/net/biblio

=== Conclusion: ===
Start a draft model for everyone to look into, another straw proposal

== Current problems ==

* Bibliographies published in HTML generally just use plain text (a URL is often included), but are sometimes produced from fully marked-up data, which is lost.
* inline citations often link to bibliography items, but use named anchors rather than fragment identifiers.
* There are multiple ways of adding self-descriptive data to web pages, such as meta tags -- with or without Dublin Core -- or embedded RDF.
** meta tags are nearly useless since their content is invisible. -Tantek
** I think there is some agreement that there may be some elements in a citation that are useful and probably ''should'' be included in the spec that are best left non-visible. 'Machine readable' is not nearly useless. The problem with metatags isn't that they're useless, it's that they are hard to relate to specific content in a web page. --ross

== Straw Proposals ==
'''These straw thoughts/proposals should be on the [[citation-brainstorming]] page, not here, along with some citation (so to speak ;) of the proposer. -Tantek'''

=== Microformat for inline citations ===

<pre>
<cite>
<a href="#ref-1">1</a>
</cite>
</pre>

<pre>
<cite>
<a href="#ref-1">Smith, 2002</a>
</cite>
</pre>

=== Microformat for a generic bibliography citation ===
<pre>
<li class="citation" id="ref-1">
<span class="title">
<a class="url" href="http://dx.doi.org/[DOI]">[item title]</a>
</span>
<span class="creator vcard">
<span class="n">
<span class="family-name">[surname]</span>,
<abbr title="[given-name]" class="given-name">[initial]</abbr>
</span>
</span>
<span class="creator vcard">
<span class="n">
<span class="family-name">[surname]</span>,
<abbr title="[given-name]" class="given-name">[initial]</abbr>
</span>
</span>
<abbr class="date-published" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">[year]</abbr>
</li>
</pre>

Note: for an full inline citation, the <pre><li class="citation" id=""></li></pre> would be replaced by <pre><cite></cite></pre> and there would not be a link to a local fragment.

Note: for a self citation, the <pre><li class="citation" id=""></li></pre> would be replaced by <pre><span|div class="citation self"></span|div></pre>

=== Additional elements for a journal article citation ===
<pre>
class="citation article"
<span class="container">
<span class="title">
<a class="url" href="http://dx.doi.org/[doi]">[journal title]</a>
</span>
<abbr class="date-published" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">[year]</abbr>
<span class="volume">[volume no.]</span>
<span class="issue">[issue no.]</span>
<abbr class="uri" title="urn:issn/[issn]"/>
</span>

<span class="pages">[start-page]-[end-page]</span>
<abbr class="uri" title="info:pmid/[PMID]"/>
</pre>

* I changed "number" to "issue". I also think that all of that content ought likely be moved out of the "container" wrapper into the root level. Finally, should not the container include another type class ("periodical" or "journal")? -- bruce
** I thought you wanted the model not to be flat, ie the container should have its own attributes? --alf
*** I am not referring to things like titles, but rather only to the locator information (volume, issue, pages), and this is primarily for practical reasons. Those in fact are not characteristics of the container (periodical), but rather of the relationship between the article and issue, and then the issue and the periodical. E.g. to model it "properly" would suggest three levels (root, container/issue, collection/periodical), each with their own respective locators. So I was just thinking for those reasons to in general say these locators ought to be associated with the root. What do you think? -- bruce. Why not do three levels? -- alf.
**** It might be useful to define which elements would appear at each level. If there are "universals" that would appear in any of kind of citation (although might have a different label/connotation based on context), what would they be? Title? Creator? What else? Then we can start figuring out the special elements for each "type" of citation. --ross
***** Titles is the obvious one that applies across the board: chapters, books, photographs, legal cases, court reporters, webpages, series, etc. all have titles. Likewise, they all have different kinds of contributors (including in many cases creators). But that's it I think. -- bruce
***** See the generic format above: title, creator and date are pretty universal. --alf

=== Additional elements for a book citation ===
<pre>
class="citation book"
<span class="container">
<span class="title">
<a class="url" href="http://dx.doi.org/[doi]">[book title]</a>
</span>
<span class="subtitle">[book subtitle]</span>
<span class="publisher vcard">[publisher]</span>
<span class="editor vcard">[editor]</span>
<abbr class="date-published" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">[year]</abbr>
<abbr class="uri" title="urn:isbn:[isbn]"/>
</span>

<span class="pages">[start-page]-[end-page]</span>
</pre>

BDarcus: this looks good. I wonder, though, about two issues.

1. why not just title and abbreviatedTitle instead of title and subtitle?

2. date-published with books in particular is a can of worms. My book, for example, has a copyright date of 2006 (which is what one would include in the citation) but an actual publication date sometime in late-2005. The specificity of date-published is thus misleading. What we're really talking about is a copyright date. I wonder if the above might not be better with two classes: date and copyright? So then these classes of dates: date, copyright, issued (more generic than published). That slso fits dc and qualified dc.
*This seems complicated (of course, it's ''all'' complicated) because there's an assumption that the citation creator will actually know which of these the date actually is. It seems like a generic date field that can be qualified with "published" or "copyright" or "actual year the conference happened", etc. would be more user-friendly.
** Ross, yes, that's what I had in mind (but didn't explain very well). A generic "date" class ought to work for most cases, but leave room to add further qualfiers if necessary. -- bruce

h-card

2016-12-19T19:17:18Z

Benthatmustbeme: /* Implementations */ adding a few implementations

<entry-title>h-card</entry-title>
<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-card</dfn> is a simple, open format for publishing people and organisations on the web. h-card is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML/HTML5.

h-card is the [[microformats2]] update to [[hCard]].

{{cc0-owfa-license}}

== Example ==
Here is a simple minimal person example:

<source lang=html4strict>
<a class="h-card" href="http://example.com">Joe Bloggs</a>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"Joe Bloggs"
],
"url": [
"http://example.com"
]
}
}
]
}
</source>

And a slightly more complete example:

<source lang=html4strict>
<p class="h-card">
<img class="u-photo" src="http://example.org/photo.png" alt="" />
<a class="p-name u-url" href="http://example.org">Joe Bloggs</a>
<a class="u-email" href="mailto:joebloggs@example.com">joebloggs@example.com</a>,
<span class="p-street-address">17 Austerstræti</span>
<span class="p-locality">Reykjavík</span>
<span class="p-country-name">Iceland</span>
</p>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"photo": [
"http://example.org/photo.png"
],
"name": [
"Joe Bloggs"
],
"url": [
"http://example.org"
],
"email": [
"mailto:joebloggs@example.com"
],
"street-address": [
"17 Austerstræti"
],
"locality": [
"Reykjavík"
],
"country-name": [
"Iceland"
]
}
}
]
}
</source>

Nested h-card example

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

=== Get started ===
The class '''<code>h-card</code>''' is a ''root class name'' that indicates the presence of an h-card.

For minimal examples where at most <code>p-name</code>, <code>u-url</code> and <code>u-photo</code> are required (such as the first given above), only the root class name is needed — see [[microformats-2-implied-properties|implied properties]].

For more complex examples, the root class name must be placed on an element which encloses all the desired properties, and then the properties themselves marked up using the classnames given below.

See [[microformats2-parsing]] to learn more about property classnames.

== Properties ==
h-card properties, inside an element with class '''h-card''':
* '''<code>p-name</code>''' - The full/formatted name of the person or organisation
* '''<code>p-honorific-prefix</code>''' - e.g. Mrs., Mr. or Dr.
* '''<code>p-given-name</code>''' - given (often first) name
* '''<code>p-additional-name</code>''' - other/middle name
* '''<code>p-family-name</code>''' - family (often last) name
* '''<code>p-sort-string</code>''' - string to sort by
* '''<code>p-honorific-suffix</code>''' - e.g. Ph.D, Esq.
* '''<code>p-nickname</code>''' - nickname/alias/handle
* '''<code>u-email</code>''' - email address
* '''<code>u-logo</code>''' - a logo representing the person or organisation
* '''<code>u-photo</code>'''
* '''<code>u-url</code>''' - home page
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical URL
* '''<code>p-category</code>''' - category/tag
* '''<code>p-adr</code>''' - postal address, optionally embed an [[h-adr]] {{main|h-adr}}
* '''<code>p-post-office-box</code>'''
* '''<code>p-extended-address</code>''' - apartment/suite/room name/number if any
* '''<code>p-street-address</code>''' - street number + name
* '''<code>p-locality</code>''' - city/town/village
* '''<code>p-region</code>''' - state/county/province
* '''<code>p-postal-code</code>''' - postal code, e.g. US ZIP
* '''<code>p-country-name</code>''' - country name
* '''<code>p-label</code>'''
* '''<code>p-geo</code>''' or '''<code>u-geo</code>''', optionally embed an [[h-geo]] {{main|h-geo}}
* '''<code>p-latitude</code>''' - decimal latitude
* '''<code>p-longitude</code>''' - decimal longitude
* '''<code>p-altitude</code>''' - decimal altitude
* '''<code>p-tel</code>''' - telephone number
* '''<code>p-note</code>''' - additional notes
* '''<code>dt-bday</code>''' - birth date
* '''<code>u-key</code>''' - cryptographic public key e.g. SSH or GPG
* '''<code>p-org</code>''' - affiliated organization, optionally embed an [[h-card]]
* '''<code>p-job-title</code>''' - job title, previously 'title' in [[hCard]], disambiguated.
* '''<code>p-role</code>''' - description of role
* '''<code>u-impp</code>''' per RFC4770, new in vCard4 (RFC 6350)
* '''<code>p-sex</code>''' - biological sex, new in vCard4 (RFC 6350)
* '''<code>p-gender-identity</code>''' - gender identity, new in vCard4 (RFC 6350)
* '''<code>dt-anniversary</code>'''

All properties are optional.

== Status ==
'''h-card''' is a microformats.org draft specification. Public discussion on h-card takes place on [[h-card-feedback]] and the #microformats [[irc]] channel on irc.freenode.net.

h-card is ready to use and implemented in the wild, but for backwards compatibility you should also mark up top-level h-cards as classic [[hCard]]s.

== Property Details ==
(stub, to be expanded)

=== p-adr ===
<code>p-adr</code> can optionally embed an [[h-adr]] to cluster associated structured address properties. E.g. adding "p-adr" to the example earlier:

<source lang=html4strict>
<div class="h-card">
<p class="p-name">Joe Bloggs</p>
<p class="p-adr h-adr">
<span class="p-street-address">17 Austerstræti</span>
<span class="p-locality">Reykjavík</span>
<span class="p-country-name">Iceland</span>
</p>
</div>
</source>

Q: Why would you use "p-adr" to cluster associated structured address properties?

A: Because if you have more than one structured address, clustering which properties go with which address keeps them deterministically together, instead of depending on array indices or other heuristics.

=== p-tel ===
Note: use of 'value' within 'p-tel' should be automatically handled by the support of the [[value-class-pattern]]. And for now, the former [[hCard]] '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).

=== dt-bday ===
Using truncated representations of dates for birth date is often good practice as noted in [https://tools.ietf.org/html/rfc6350#section-4.3.1 the vcard spec] eg
* <code>1985-04</code> for April 1985
* <code>1985</code> for the year 1985
* <code>--04-12</code> for April 12th with no specified year

=== Reserved properties ===
Reserved properties (not used much, if at all, in practice):

* '''<code>p-organization-name</code>'''
* '''<code>p-organization-unit</code>'''
* '''<code>p-tz</code>''' - timezone offset, e.g. <code><data class="p-tz" value="-0800">PST</data></code>
* '''<code>dt-rev</code>'''

== Examples in the wild ==
Real world in the wild examples of sites and services that publish or consume h-card:

* ... add uses of h-card you see in the wild here.
* 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-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his homepage and posts with h-card [http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his homepage and posts up with h-card and h-entry ([sandeep.io/101 example])
* [http://eschnou.com/ Laurent Eschenauer] marks his homepage profile up using h-card
* [http://tommorris.org/ Tom Morris] marks himself up with h-card as well as venues he’s checked into ([http://tommorris.org/posts/8408 example])
* [http://www.w3.org/conf/ W3Conf 2013] uses h-card for all the event 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 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 on his home page as well as within [[h-entry]]s on permalink pages to indicate authorship.
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-card on his home page, as well as within h-entries for notes and articles, both to indicate authorship and also when mentioning people within the body of the notes.
* [http://tantek.com/presentations/2012/06/microformats microformats.org at 7 years] presentation with 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 [[microformats2]] h-card markup
* WebMaker by Mozilla has [[microformats2]] 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 [[microformats2]] h-card markup on [https://webfwd.org/about/experts/ experts] and [https://webfwd.org/about/team/ team] pages
* [http://indiewebcamp.com IndieWebCamp] has [[microformats2]] h-event markup with embedded h-cards for the organizers and the location.
* [https://wiki.mozilla.org/Events Mozilla Events] page has [[microformats2]] h-event markup with attendees marked up with h-card.
* [https://tristanthomas.me Tristan Thomas] uses h-card on his home page
* [http://cold32.com/about-the-author-and-contact.htm Cold32.com] uses h-card (and h-geo) on its about-the-author-and-contact page
* [https://workfrom.co/ Workfrom.co] renders h-cards for venues (e.g. [https://workfrom.co/palio-dessert-and-espresso-house])
* [http://www.pcwdld.com/ PCWDLD.com] renders h-cards for download pages(e.g. [http://www.pcwdld.com/solarwinds-network-topology-mapper-review Download page example])

=== offline ===
* spreadly marks up share permalink pages with minimal h-cards inside h-entry

== Validating ==
* '''[http://indiewebify.waterpigs.co.uk/validate-h-card/ indiewebify.me h-card validator]''' parses [[h-card]] markup and makes suggestions for things to add, with code samples
{{h-spec-section-validating}}

== Implementations ==
Software implementations that publish or consume h-card, including themes, plugins, or extensions:

(This section is a stub that needs expansion! In practice, nearly every CMS on every [https://indieweb.org/ indie web] site supports publishing h-card by default.)

When adding an implementation, please provide and link to its home page and open source repo if any.
* [https://gnu.io/social/ GNUsocial] [https://git.gnu.io/gnu/gnu-social/ source code]
* [https://hubzilla.org/hubzilla/ Hubzilla] [https://github.org/redmatrix/hubzilla source code]
* [http://friendica.com/ Friendica] [https://github.org/friendica/friendica source code]
* [http://github.com/dissolve/inkblot InkBlot]
* ...
* ...

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[hCard]] classnames in addition to the more future-proof h-card properties, for example:

<source lang=html4strict>
<p class="h-card vcard">
<span class="p-name fn">Joe Bloggs</span>,
<span class="p-org org">Awesome Nonprofit</span>
...
</p>
</source>

The class '''<code>vcard</code>''' is a ''backward compatible root class name'' that indicates the presence of an [[hCard]].

'''fn''', '''org''', and all the other backward compatibility hCard property class names are listed below.

=== Parser Compatibility ===
Microformats parsers {{should}} detect classic properties only if a classic root class name is found and parse them as microformats2 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-'''

== Background ==
This work is based on the existing [[hCard]] and [[vcard]] specifications.

== Design Principles ==

(stub, expand)

== Additions ==
We've tried very hard with h-card to stay compatible with the vCard4 vocabulary, and thus additions should be proposed on the vCard4 mailing list.

However, you may still use this wiki to capture additions for h-card here:
* [[h-card-brainstorming]]

== See Also ==
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-adr]]
* [[h-geo]]
* [[hCard]]

[[Category:Draft Specifications]]

h-entry

2016-12-19T19:15:27Z

Benthatmustbeme: /* Implementations */ add a few implementations

<entry-title>h-entry</entry-title>
<dfn style="font-style:normal;font-weight:bold">h-entry</dfn> is a simple, open format for episodic or datestamped content on the web. h-entry is often used with content intended to be syndicated, e.g. blog posts. h-entry is one of several open [[microformats|microformat]] standards suitable for embedding data in HTML/HTML5.

h-entry is the [[microformats2]] update to [[hAtom]]'s "hentry". For an update to "hfeed" see [[h-feed]].

;<span id="Status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [[h-entry-issues|feedback]]. This specification has portions that are stable, draft, and proposed. Features are stable unless explicitly labeled draft or proposed, or in draft or proposed sections. Draft and proposed features are likely to change substantively. While substantive changes to stable features are unexpected, it is a living specification subject to substantive change by issues and errata filed in response to implementation experience, requiring consensus among participating implementers as part of an explicit [[#change_control|change control]] process.
;Participate
:[https://github.com/microformats/h-entry/issues Open Issues]
:[[h-entry-issues|Resolved issues before 2012-246]]
:[[IRC]]: [irc://irc.freenode.net/microformats #microformats on Freenode]
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__

== Example ==
Here is a simple blog post example:

<source lang=html4strict>
<article class="h-entry">
<h1 class="p-name">Microformats are amazing</h1>
<p>Published by <a class="p-author h-card" href="http://example.com">W. Developer</a>
on <time class="dt-published" datetime="2013-06-13 12:00:00">13<sup>th</sup> June 2013</time>

<p class="p-summary">In which I extoll the virtues of using microformats.</p>

<div class="e-content">
<p>Blah blah blah</p>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-entry"
],
"properties": {
"name": [
"Microformats are amazing"
],
"author": [
{
"value": "W. Developer",
"type": [
"h-card"
],
"properties": {
"name": [
"W. Developer"
],
"url": [
"http://example.com"
]
}
}
],
"published": [
"2013-06-13 12:00:00"
],
"summary": [
"In which I extoll the virtues of using microformats."
],
"content": [
{
"value": "Blah blah blah",
"html": "<p>Blah blah blah</p>"
}
]
}
}
]
}
</source>

=== Get started ===
The class '''<code>h-entry</code>''' is a ''root class name'' that indicates the presence of an h-entry.

'''p-name''', '''p-author''', '''dt-published''' and the other h-entry property classnames listed below define properties of the h-entry.

See [[microformats2-parsing]] to learn more about property classnames.

== Properties ==
h-entry properties, inside an element with class '''h-entry'''. All properties are optional.

=== Core Properties ===
The following ''core'' h-entry properties have broad consensus and are broadly interoperably published and consumed:
* '''<code>p-name</code>''' - entry name/title
* '''<code>p-summary</code>''' - short entry summary
* '''<code>e-content</code>''' - full content of the entry
* '''<code>dt-published</code>''' - when the entry was published
* '''<code>dt-updated</code>''' - when the entry was updated
* '''<code>p-author</code>''' - who wrote the entry, optionally embedded [[h-card]](s)
* '''<code>p-category</code>''' - entry categories/tags
* '''<code>u-url</code>''' - entry permalink URL
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical entry URL
* '''<code>p-location</code>''' - location the entry was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code>u-syndication</code>''' - URL(s) of syndicated copies of this post. The property equivalent of [[rel-syndication]] ([http://erinjo.is/2014/checked-into-rockit-colabs-23 example])
* '''<code>u-in-reply-to</code>''' - the URL which the h-entry is considered reply to (i.e. doesn’t make sense without context, could show up in comment thread), optionally an embedded [[h-cite]] ([http://indiewebcamp.com/reply-context reply-context]) ([http://waterpigs.co.uk/notes/4V2DjG/ example])
* '''<code id="p-rsvp">p-rsvp</code>''' (enum, use <data> element or [[value-class-pattern]])
** "yes", "no", "maybe", "interested". Case-insensitive values, normalized to lowercase. Examples:
** <code><nowiki>... <data class="p-rsvp" value="yes">is going</data> to ...</nowiki></code>, or
** <code><nowiki>... <data class="p-rsvp" value="maybe">might go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="no">unable to go</data> to ...</nowiki></code>
** <code><nowiki>... <data class="p-rsvp" value="interested">am interested/tracking/watching</data> ...</nowiki></code>

=== Draft Properties ===
The following draft properties are in use in the wild (published and consumed), and are under strong consideration, but are not yet part of the core:

* '''<code id="p-comment">p-comment</code>''' - optionally embedded (or nested?) [[h-cite]](s), each of which is a comment on/reply to the parent h-entry. See [[comment-brainstorming]] ([http://waterpigs.co.uk/notes/4V2DjG/ example])
* '''<code id="u-like-of">u-like-of</code>''' - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded [[h-cite]] ([http://barryfrost.com/posts/11 example])
* '''<code id="u-repost-of">u-repost-of</code>''' - the URL which the h-entry is considered a “repost” of. Optionally an embedded [[h-cite]].
* '''<code id="u-photo">u-photo</code>''' - one or more photos that is/are considered the primary content of the entry, unless there is a <code>p-location h-card</code>, which is still considered a "checkin" (i.e. with a photo). Otherwise the presence of a u-photo means the name of the entry should be interpreted as a caption on the photo, and the summary/content should be interpreted as a description of the photo.
* '''<code>u-video</code>''' - special u- parsing rules for <code><video src> & <source src></code>

=== Proposed Additions ===
The following properties are proposed additions based on various use-cases, such as existing [[link-preview-brainstorming|link preview]] markup conventions, but are awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:
* '''<code>u-audio</code>''' - special u- parsing rules for <code><audio src> & <source src></code>
* '''<code>u-like</code>''' - similar to p-comment, URL to a like post of the current post, e.g. in a responses list or facepile.
* '''<code>u-repost</code>''' - similar to u-like, URL to a repost of the current post, e.g. in a responses list or facepile.
* '''<code>u-featured</code>''' - a representative photo or image for the entry, e.g. primary photo for an article or subject-cropped photo, suitable for use in a [[link-preview]].
* '''<code>p-latitude</code>''' - latitude of the location of the entry
* '''<code>p-longitude</code>''' - longitude of the location of the entry

The following interpretation is also proposed addition:
* if the <code>p-location</code> is also an embedded [[h-card]], the entry is treated as a "checkin".

== Property Details ==
This section is a stub.
=== p-location ===
'''<code>p-location</code>''' has been re-used from [[h-event]].

== FAQ ==
=== p-name of a note ===
<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>

=== venue an entry was posted from ===
<div class="discussion">
* '''How do you indicate a named venue where an entry was posted from? Like a restaurant or park.'''
** Use an embedded [[h-card]] microformat on a <code>p-location</code> property value.
</div>
=== address an entry was posted from ===
<div class="discussion">
* '''How do you indicate the address where an entry was posted from? Like a restaurant or park.'''
** If the address is just part of a named venue, see above, use an [[h-card]]
** Otherwise use an embedded [[h-adr]] microformat on a <code>p-location</code> property value.
</div>
=== lat long an entry was posted from ===
<div class="discussion">
* '''How do you indicate the latitude and longitude of where an entry was posted from?'''
** If the location has a name in addition to latitude and longitude, see above, use an [[h-card]]
** Otherwise if there is an address in addition to latitude and longitude, see above, use an [[h-adr]]
** Otherwise use an embedded [[h-geo]] microformat on a <code>p-location</code> property value.
</div>
=== dt-published property and HTML5 time element ===
<div class="discussion">
* '''Does the dt-published property need to be a time element?'''
** The <code>dt-published</code> property should be a <code><time></code> element so that you can take advantage of HTML5's "datetime" property.
** This lets you specify a human-readable date in the value of the attribute, and the ISO8601 machine-readable date in the "datetime" property.
</div>
=== what is the bare minimum list of required properties on an h-entry ===
<div class="discussion">
* What is the bare minimum list of required properties on an h-entry?
** No properties are explicitly required, but in practice a h-entry should have the following properties at a minimum for consumers:
</div>
* <code>name</code> (can be implied)
* <code>url</code> (can be implied)
* <code>published</code> — if there is no "published" date for the "entry", then reconsider whether it is correct (or worth) marking it up as an entry.
<div class="discussion">
* What properties should an h-entry have in addition to the bare minimum?
** Beyond the bare minimum, a typical h-entry should have the following as well:
</div>
* <code>content</code> (or <code>summary</code> at least) - especially for structured content. For a plain text note, the content/summary (whichever is used) should be the same as the <code>name</code>, otherwise it will be implied from the text content of the root element.
* <code>name</code> - for explicitly named/titled entries. Otherwise the entry is assumed to be a "title-less" note (like a tweet).
* <code>author</code> - including a nested <code>[[h-card]]</code> with author details like name, photo, url.

== Examples in the wild ==
Real world in the wild examples of sites and services that publish or consume h-entry:

* ... add uses of h-entry you see in the wild here.
* ind.ie mark up their [https://ind.ie/blog blog] listing and [https://ind.ie/blog/autumn-events-2014/ permalink] pages with h-entry
* 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))
* 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]
* 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 posts with h-entry and h-card ([http://www.okinawan-lyrics.com/ example])
* App.net marks up profile pages and permalink pages with h-entry as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* The Twitter archive browser UI uses h-entry and h-card internally, unfortunately it’s not exposed as HTML in static files anywhere
* 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])
* Numerous newer W3C specs, e.g.
** [http://www.w3.org/TR/2013/CR-css3-values-20130404/ CSS Values and Units Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/CR-css3-conditional-20130404/ CSS Conditional Rules Module Level 3 - 2013-04-04]
** [http://www.w3.org/TR/2013/WD-css3-page-20130314/ CSS Paged Media Module Level 3 - 2013-03-14]
** [http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/ CSS Counter Styles Level 3 - 2013-02-21]
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry.
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card and h-entry markup on their homepage and individual thoughts pages
* Aaron Parecki uses h-entry to mark up notes, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses 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
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-entry on all notes and articles, as well as nested within notes as reply contexts [http://waterpigs.co.uk/notes/1468/ example] and comments [http://waterpigs.co.uk/notes/1482/ example].

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

== Validating ==
* '''[http://indiewebify.me/validate-h-entry/ indiewebify.me h-entry validator]''' parses [[h-entry]] markup, finds common errors and makes suggestions for things to add, with code samples
* '''[http://shrewdness.waterpigs.co.uk/test/ Shrewdness h-entry/h-feed validator]''' shows how shrewdness interprets+displays h-entries, with original source and interim formats, works for single h-entries and feed pages

{{h-spec-section-validating}}

== Implementations ==
Software implementations that publish or consume h-entry, including themes, plugins, or extensions:

(This section is a stub that needs expansion! In practice, nearly every CMS on every [https://indieweb.org/ indie web] site supports publishing h-entry by default.)

When adding an implementation, please provide and link to its home page and open source repo if any.
* [https://gnu.io/social/ GNUsocial] [https://git.gnu.io/gnu/gnu-social/ source code]
* [https://hubzilla.org/hubzilla/ Hubzilla] [https://github.org/redmatrix/hubzilla source code]
* [http://friendica.com/ Friendica] [https://github.org/friendica/friendica source code]
* [http://github.com/dissolve/inkblot InkBlot]
* ...

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility with legacy [[hAtom]] consuming implementations, use [[hAtom]] classnames (or rel values) in addition to the more future-proof h-entry properties, for example:

<source lang=html4strict>
<div class="h-entry hentry">
<h1 class="p-name entry-title">My great blog post</h1>
</div>
</source>

The list of equivalent [[hAtom]] classnames and rel values is provided below.

=== Parser Compatibility ===
Microformats parsers {{should}} detect classic properties only if a classic root class name is found and parse them as microformats2 properties.

If an "h-entry" is found, don't look for an "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> - parse as '''<code>p-summary</code>'''
* <code>entry-content</code> - parse as '''<code>e-content</code>'''
* <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>rel=bookmark</code> - parse as '''<code>u-url</code>'''. While not a class name nor typical microformats property, rel=bookmark was the only way to indicate an hentry permalink. Thus parsers should look for rel=bookmark hyperlinks inside an hentry, and take their "href" value as a value for a '''<code>u-url</code>''' property, including handling any relative URL resolution.
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hentry. Thus parsers should look for rel=tag hyperlinks inside an hentry, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

Proposed:
* <code>time.entry-date[datetime]</code> - in the absence of <code>published</code>, parse as '''<code>dt-published</code>'''. parse for the first <code><time></code> element with class name of <code>entry-date</code> and non-empty <code>datetime</code> attribute inside an hentry, if there is no <code>published</code> property, use that time element's <code>datetime</code> attribute value for the <code>dt-published</code> property. Evidence: default WordPress themes 2011-2014([https://wp-themes.com/twentyeleven/][https://wp-themes.com/twentytwelve/][https://wp-themes.com/twentythirteen/][https://wp-themes.com/twentyfourteen/]).
* <code>rel=author</code> - in the absence of <code>author</code>, parse as '''<code>u-author</code>'''. While not a class name nor typical microformats property, rel=author was commonly used to link to an author's URL. Thus parsers should look for rel=author hyperlinks inside an hentry (or even on the same page, preceding the hentry), use the absolute version of it as a value for the '''<code>u-author</code>''' property if there is no "author" property. (citations to "hentry" examples in the wild that <em>depend</em> on rel=author needed to accepted this proposal. Note: default WordPress themes twentyeleven, twentytwelve, twentythirteen, twentyfourteen all use rel=author but only inside class="author vcard", and thus rel=author can be ignored since authorship is already picked up by existing <code>author</code> backcompat parsing.)

=== Compat FAQ ===
==== What about rel bookmark ====
Also asked as: ''Why use an h-entry u-url u-uid for permalinks when I have [[rel-bookmark|rel=bookmark]]?''

A: tl;dr: use <code>class="u-url u-uid"</code> instead of <code>rel=bookmark</code> for post permalinks because it's simpler (fewer attributes), and works better across contexts (permalink page, recent posts on home page, collection of posts on archive pages).

rel=bookmark was the old [[hAtom]] way of marking up permalinks. Since then two factors have contributed to reducing use of rel inside microformats:
* rel by typically* document scoped in [[HTML5]] - thus making it inappropriate for use in microformats that are aggregated, e.g. a collection of posts on a home page or in monthly archives.
* it is easier to always use class names for properties. When formats use two (or more!) attributes in HTML to specify properties, confusion results in lower data quality (of the markup and thus the stuff that is marked up). Thus per the microformats [[principle]] of [[simplicity]], in [[microformats2]] we only use class names for properties.

<nowiki>*</nowiki> even though rel=bookmark in particular is article-element / sectioning scoped in HTML5[http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-bookmark], it's a detail that typical authors are not going to remember, and thus it's not good to depend on it for any kind of format.

==== Why rename entry-title entry-summary entry-content ====
The <code>entry-*</code> classnames in classic [[hAtom]] were prefixed as such due to concerns about vocabulary overlap with the title (as in job title, completely separate semantic) property in [[hCard]] and the summary property in [[hCalendar]] (see: [[hatom-faq#Could_hAtom_instead_use_title_content_and_summary|hAtom FAQ]]).

Following the [[simplicity]] principle, in microformats2, the aforementioned vagueness of '''title''' is dealt with by removing it. As '''name''' is now used consistently across all vocabularies as the property which “names” the microformat, it makes sense to use it to mark up the name of a post.

Likewise, adding entry- to '''summary''' doesn’t add any useful information, and in practice there have been no problems with blog post summaries overlapping with entry summaries, so it makes sense to simplify to '''summary'''. The same applies to '''entry-content''' simplified to '''content'''.

See also: [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-128 2012-08-30 IRC conversation].

== Related Work ==
Work that re-uses or builds upon h-entry:
* [https://mailpile.pagekite.me:8080/p/Open_Message_Format Mailpile Open Message Format] is using h-entry with structured properties, e.g. p-author h-card.

== Background ==
This work is based on the existing [[hAtom]] microformat, and extensive selfdogfooding in the [http://indiewebcamp.com indie web camp] community.

== change control ==
Minor editorial changes (e.g. fixing minor typos or punctuation) that do not change and preferably clarify the structure and existing intended meaning may be done by anyone without filing issues, requiring only a sufficient "Summary" description field entry for the edit. More than minor but still purely editorial changes may be made by an editor. Anyone may question such editorial changes by undoing corresponding edits without filing an issue. Any further reversion or iteration on such an editorial change must be done by filing an issue.

For the stable features of this document, substantive issue filing, resolution, and edits may be done by filing an [[h-entry-issues|issue]] and discussing them on the issue and on #microformats [[IRC]] with a link to the issue.

Because this is primarily a vocabulary specification, very few issues beyond the list of vocabulary have filed or required any lengthy discussion. If such a non-trivial issue arises in the future, use the [[microformats2-parsing#change_control|microformats2-parsing change control process]] to resolve them.

In general, non-vocabulary related features or requirements should be avoided in this specification, e.g. changes to microformats2 syntax must be proposed as [[microformats2-parsing]] changes using the [[microformats2-parsing#change_control|microformats2-parsing change control process]].

Beyond that, the following requirements must be met for adding or moving features (e.g. properties and values) to proposed, draft, or stable:

;Proposed
:[[#Proposed_Additions|Proposed features]] must provide documentation of what specific real world use-cases they are solving, preferably with a link to a step-by-step user scenario, e.g. demonstratable using existing non-standard / single-site / single-implementation tools.
;Draft
:[[#Draft_Properties|Draft properties]] must in addition be published and consumed in the wild on the public web, demonstrate solving the use case for which they were proposed, and should provide citations of real world public web sites publishing and (other sites) consuming them, interoperably.
;Stable
:Stable features (e.g. [[#Core_Properties|Core Properties]]) must in addition be published and consumed in the wild on multiple sites by multiple implementations (3+ different sites and implementations for publishing and consuming). When a draft property reaches a critical mass of deployment by numerous sites and implementations (far beyond 3+), due to network effects and backward compatibility considerations it effectively becomes stable, since it becomes increasingly difficult to change it in any way and have so many sites and implementations also change.

For creating an entirely new vocabulary, and more details about how to research existing values, properties, document examples in the wild, etc., see the microformats [[process]].

== See Also ==
* [[h-feed]]
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-geo]]
* [[hCard]]

[[Category:Specifications]]

jf2

2016-01-04T22:06:04Z

Benthatmustbeme: Undo revision 65369 by Benthatmustbeme (Talk) nevermind, this is actually a bug in webmention.io, misunderstanding there.

{{stub}}

'''<dfn>jf2</dfn>''' is a working name for a simplified more minimal JSON representation of [[microformats2]].

== Basic Example ==
<source lang="javascript">
{
"type": "entry",
"author": {
"type": "card",
"name": "Tantek Çelik",
"url": "http:\/\/tantek.com\/",
"photo": "http:\/\/tantek.com\/photo.jpg"
},
"published": "2015-10-21T12:34-0700",
"category": ["simple", "example"],
"content": "Example of a simple note"
}
</source>

== Specification ==
* [https://github.com/dissolve/jf2 github.com/dissolve/jf2] - Primary development

== Implementations ==
=== Parsers ===
Open source parsers:
* [https://github.com/dissolve/socialstream github.com/dissolve/socialstream] - Sample php code to convert MF2 -> JS2
* [http://www.unmung.com/ unmung.com] - another conversion service that can convert mf2 to jf2

=== Consuming Code ===
Service that converts jf2 into readable HTML:
* [http://stream.thatmustbe.us/ stream.thatmustbe.us] - Service running the socialstream code

== Name Candidates ==
As 'jf2' is only a working name let's collect alternatives:

;JFDI
:Backronym: JSON For Data Interchange
;jf2
:Minimal JSON for mf2

== Prior Work ==
* [[microformats2]] JSON

== Prior Simplifications ==
Output from:

=== [http://webmention.io webmention.io] ===
This service outputs a list of webmentions received for a post. It recognizes when a post is a reply, like, repost, invitation, RSVP, and mention. Example JSON output:

<source lang="javascript">
{
"source": "http://tantek.com/2013/112/t2/milestone-show-indieweb-comments-h-entry-pingback",
"verified": true,
"verified_date": "2013-04-25T17:09:33-07:00",
"id": 900,
"data": {
"author": {
"name": "Tantek Çelik",
"url": "http://tantek.com/",
"photo": "http://tantek.com/logo.jpg"
},
"name": "Another milestone: @eschnou automatically shows #indieweb comments with h-entry sent via pingback http://eschnou.com/entry/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html",
"content": "Another milestone: <a class=\"auto-link h-x-username\" href=\"https:\/\/twitter.com\/eschnou\">@eschnou<\/a> automatically shows #indieweb comments with h-entry sent via pingback <a class=\"auto-link\" href=\"http:\/\/eschnou.com\/entry\/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html\">http:\/\/eschnou.com\/entry\/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html<\/a>",
"published": "2013-04-22T15:03:00-07:00",
"published_ts": 1366668180,
"url": "http://tantek.com/2013/112/t2/milestone-show-indieweb-comments-h-entry-pingback"
}
}
</source>

=== webmention.herokuapp.com ===

This site outputs in multiple formats, based on receiving webmentions, parsing them for microformats and consolidating into a single feed. Live examples for kevinmarks.com:
*[https://webmention.herokuapp.com/api/mentions?site=kevinmarks.com&format=html HTML mf2 markup]
<source lang=html4strict>
<div class="h-entry">
<a href="http://waterpigs.co.uk/" class="p-author h-card">
<img src="http://waterpigs.co.uk/photo.jpg" alt="">
Barnaby Walters
</a>
<div class="p-summary p-name">@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf</div>
<footer>
<time class="dt-published" datetime="2014-04-01T14:25:14.000Z" pubdate="">
<a class="u-url u-uid" href="http://waterpigs.co.uk/notes/4VMERE/">2 years ago</a>
</time>
mentioning <a href="http://kevinmarks.com/">http://kevinmarks.com/</a>
</footer>
</div>
</source>
*[http://www.unmung.com/mf2?url=https%3A%2F%2Fwebmention.herokuapp.com%2Fapi%2Fmentions%3Fsite%3Dkevinmarks.com%26format%3Dhtml&html=&pretty=on parsed JSON form of the HTML]

<source lang=javascript>
{
"type": ["h-entry"],
"properties": {
"uid": ["http://waterpigs.co.uk/notes/4VMERE/"],
"author": [
{"type": ["h-card"],
"properties": {
"url": ["http://waterpigs.co.uk/"],
"photo": ["http://waterpigs.co.uk/photo.jpg"],
"name": [""]
},
"value": "Barnaby Walters"
}],
"url": ["http://waterpigs.co.uk/notes/4VMERE/"],
"summary": ["@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf"],
"published": ["2014-04-01T14:25:14Z"],
"name": [ "@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf"]
}
}
</source>

*[https://webmention.herokuapp.com/api/mentions?site=kevinmarks.com&format=json simplified JSON] (whitespace added)

<source lang=javascript>
{
"url":"http://waterpigs.co.uk/notes/4VMERE/",
"name":null,
"published":1396362314000,
"summary":"@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf",
"author": {
"name":"Barnaby Walters",
"photo":"http://waterpigs.co.uk/photo.jpg",
"url":"http://waterpigs.co.uk/"
},
"interactions": ["http://www.kevinmarks.com/indiewebsfdemowrapup.html"],
"targets":["http://kevinmarks.com/"],
"type":"reply",
"interactionTarget":false
}
</source>

=== [https://github.com/indieweb/php-comments php-comments] library ===
This library takes HTML and converts it to a simple PHP data structure. Example post:

<source lang="php">
$result = array(
'type' => 'reply',
'author' => array(
'name' => 'Aaron Parecki',
'photo' => 'http://aaronparecki.com/images/aaronpk.png',
'url' => 'http://aaronparecki.com/'
),
'published' => '2014-02-16T18:48:17-0800',
'name' => 'Example Note',
'text' => 'this text is displayed as the comment',
'url' => 'http://aaronparecki.com/post/1'
);
</source>

== See Also ==
* [[json]]
* [[microformats2]]
* [[microformats2-parsing]]

jf2

2016-01-04T22:04:50Z

Benthatmustbeme: /* webmention.herokuapp.com */ author was missing type:card

{{stub}}

'''<dfn>jf2</dfn>''' is a working name for a simplified more minimal JSON representation of [[microformats2]].

== Basic Example ==
<source lang="javascript">
{
"type": "entry",
"author": {
"type": "card",
"name": "Tantek Çelik",
"url": "http:\/\/tantek.com\/",
"photo": "http:\/\/tantek.com\/photo.jpg"
},
"published": "2015-10-21T12:34-0700",
"category": ["simple", "example"],
"content": "Example of a simple note"
}
</source>

== Specification ==
* [https://github.com/dissolve/jf2 github.com/dissolve/jf2] - Primary development

== Implementations ==
=== Parsers ===
Open source parsers:
* [https://github.com/dissolve/socialstream github.com/dissolve/socialstream] - Sample php code to convert MF2 -> JS2
* [http://www.unmung.com/ unmung.com] - another conversion service that can convert mf2 to jf2

=== Consuming Code ===
Service that converts jf2 into readable HTML:
* [http://stream.thatmustbe.us/ stream.thatmustbe.us] - Service running the socialstream code

== Name Candidates ==
As 'jf2' is only a working name let's collect alternatives:

;JFDI
:Backronym: JSON For Data Interchange
;jf2
:Minimal JSON for mf2

== Prior Work ==
* [[microformats2]] JSON

== Prior Simplifications ==
Output from:

=== [http://webmention.io webmention.io] ===
This service outputs a list of webmentions received for a post. It recognizes when a post is a reply, like, repost, invitation, RSVP, and mention. Example JSON output:

<source lang="javascript">
{
"source": "http://tantek.com/2013/112/t2/milestone-show-indieweb-comments-h-entry-pingback",
"verified": true,
"verified_date": "2013-04-25T17:09:33-07:00",
"id": 900,
"data": {
"author": {
"name": "Tantek Çelik",
"url": "http://tantek.com/",
"photo": "http://tantek.com/logo.jpg"
},
"name": "Another milestone: @eschnou automatically shows #indieweb comments with h-entry sent via pingback http://eschnou.com/entry/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html",
"content": "Another milestone: <a class=\"auto-link h-x-username\" href=\"https:\/\/twitter.com\/eschnou\">@eschnou<\/a> automatically shows #indieweb comments with h-entry sent via pingback <a class=\"auto-link\" href=\"http:\/\/eschnou.com\/entry\/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html\">http:\/\/eschnou.com\/entry\/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html<\/a>",
"published": "2013-04-22T15:03:00-07:00",
"published_ts": 1366668180,
"url": "http://tantek.com/2013/112/t2/milestone-show-indieweb-comments-h-entry-pingback"
}
}
</source>

=== webmention.herokuapp.com ===

This site outputs in multiple formats, based on receiving webmentions, parsing them for microformats and consolidating into a single feed. Live examples for kevinmarks.com:
*[https://webmention.herokuapp.com/api/mentions?site=kevinmarks.com&format=html HTML mf2 markup]
<source lang=html4strict>
<div class="h-entry">
<a href="http://waterpigs.co.uk/" class="p-author h-card">
<img src="http://waterpigs.co.uk/photo.jpg" alt="">
Barnaby Walters
</a>
<div class="p-summary p-name">@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf</div>
<footer>
<time class="dt-published" datetime="2014-04-01T14:25:14.000Z" pubdate="">
<a class="u-url u-uid" href="http://waterpigs.co.uk/notes/4VMERE/">2 years ago</a>
</time>
mentioning <a href="http://kevinmarks.com/">http://kevinmarks.com/</a>
</footer>
</div>
</source>
*[http://www.unmung.com/mf2?url=https%3A%2F%2Fwebmention.herokuapp.com%2Fapi%2Fmentions%3Fsite%3Dkevinmarks.com%26format%3Dhtml&html=&pretty=on parsed JSON form of the HTML]

<source lang=javascript>
{
"type": ["h-entry"],
"properties": {
"uid": ["http://waterpigs.co.uk/notes/4VMERE/"],
"author": [
{"type": ["h-card"],
"properties": {
"url": ["http://waterpigs.co.uk/"],
"photo": ["http://waterpigs.co.uk/photo.jpg"],
"name": [""]
},
"value": "Barnaby Walters"
}],
"url": ["http://waterpigs.co.uk/notes/4VMERE/"],
"summary": ["@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf"],
"published": ["2014-04-01T14:25:14Z"],
"name": [ "@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf"]
}
}
</source>

*[https://webmention.herokuapp.com/api/mentions?site=kevinmarks.com&format=json simplified JSON] (whitespace added)

<source lang=javascript>
{
"url":"http://waterpigs.co.uk/notes/4VMERE/",
"name":null,
"published":1396362314000,
"summary":"@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf",
"author": {
"type":"card",
"name":"Barnaby Walters",
"photo":"http://waterpigs.co.uk/photo.jpg",
"url":"http://waterpigs.co.uk/"
},
"interactions": ["http://www.kevinmarks.com/indiewebsfdemowrapup.html"],
"targets":["http://kevinmarks.com/"],
"type":"reply",
"interactionTarget":false
}
</source>

=== [https://github.com/indieweb/php-comments php-comments] library ===
This library takes HTML and converts it to a simple PHP data structure. Example post:

<source lang="php">
$result = array(
'type' => 'reply',
'author' => array(
'name' => 'Aaron Parecki',
'photo' => 'http://aaronparecki.com/images/aaronpk.png',
'url' => 'http://aaronparecki.com/'
),
'published' => '2014-02-16T18:48:17-0800',
'name' => 'Example Note',
'text' => 'this text is displayed as the comment',
'url' => 'http://aaronparecki.com/post/1'
);
</source>

== See Also ==
* [[json]]
* [[microformats2]]
* [[microformats2-parsing]]

jf2

2016-01-04T22:03:24Z

Benthatmustbeme: /* Basic Example */ type:image has been dropped for simpler format

jf2

2015-12-08T02:29:32Z

Benthatmustbeme: correct links for jf2

{{stub}}

'''<dfn>jf2</dfn>''' is a working name for a simplified more minimal JSON representation of [[microformats2]].

== Basic Example ==
<source lang="javascript">
{
"type": "entry",
"author": {
"type": "card",
"name": "Tantek Çelik",
"url": "http:\/\/tantek.com\/",
"photo": {
"type": "image",
"url": "http:\/\/tantek.com\/photo.jpg"
}
},
"published": "2015-10-21T12:34-0700",
"category": ["simple", "example"],
"content": "Example of a simple note"
}
</source>

== Prior Work ==
* [[microformats2]] JSON

== Prior Simplifications ==
Output from:

=== [http://webmention.io webmention.io] ===
This service outputs a list of webmentions received for a post. It recognizes when a post is a reply, like, repost, invitation, RSVP, and mention. Example JSON output:

<source lang="javascript">
{
"source": "http://tantek.com/2013/112/t2/milestone-show-indieweb-comments-h-entry-pingback",
"verified": true,
"verified_date": "2013-04-25T17:09:33-07:00",
"id": 900,
"data": {
"author": {
"name": "Tantek Çelik",
"url": "http://tantek.com/",
"photo": "http://tantek.com/logo.jpg"
},
"name": "Another milestone: @eschnou automatically shows #indieweb comments with h-entry sent via pingback http://eschnou.com/entry/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html",
"content": "Another milestone: <a class=\"auto-link h-x-username\" href=\"https:\/\/twitter.com\/eschnou\">@eschnou<\/a> automatically shows #indieweb comments with h-entry sent via pingback <a class=\"auto-link\" href=\"http:\/\/eschnou.com\/entry\/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html\">http:\/\/eschnou.com\/entry\/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html<\/a>",
"published": "2013-04-22T15:03:00-07:00",
"published_ts": 1366668180,
"url": "http://tantek.com/2013/112/t2/milestone-show-indieweb-comments-h-entry-pingback"
}
}
</source>

=== webmention.herokuapp.com ===

This site outputs in multiple formats, based on receiving webmentions, parsing them for microformats and consolidating into a single feed. Live examples for kevinmarks.com:
*[https://webmention.herokuapp.com/api/mentions?site=kevinmarks.com&format=html HTML mf2 markup]
<source lang=html4strict>
<div class="h-entry">
<a href="http://waterpigs.co.uk/" class="p-author h-card">
<img src="http://waterpigs.co.uk/photo.jpg" alt="">
Barnaby Walters
</a>
<div class="p-summary p-name">@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf</div>
<footer>
<time class="dt-published" datetime="2014-04-01T14:25:14.000Z" pubdate="">
<a class="u-url u-uid" href="http://waterpigs.co.uk/notes/4VMERE/">2 years ago</a>
</time>
mentioning <a href="http://kevinmarks.com/">http://kevinmarks.com/</a>
</footer>
</div>
</source>
*[http://www.unmung.com/mf2?url=https%3A%2F%2Fwebmention.herokuapp.com%2Fapi%2Fmentions%3Fsite%3Dkevinmarks.com%26format%3Dhtml&html=&pretty=on parsed JSON form of the HTML]

<source lang=javascript>
{
"type": ["h-entry"],
"properties": {
"uid": ["http://waterpigs.co.uk/notes/4VMERE/"],
"author": [
{"type": ["h-card"],
"properties": {
"url": ["http://waterpigs.co.uk/"],
"photo": ["http://waterpigs.co.uk/photo.jpg"],
"name": [""]
},
"value": "Barnaby Walters"
}],
"url": ["http://waterpigs.co.uk/notes/4VMERE/"],
"summary": ["@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf"],
"published": ["2014-04-01T14:25:14Z"],
"name": [ "@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf"]
}
}
</source>

*[https://webmention.herokuapp.com/api/mentions?site=kevinmarks.com&format=json simplified JSON] (whitespace added)

<source lang=javascript>
{
"url":"http://waterpigs.co.uk/notes/4VMERE/",
"name":null,
"published":1396362314000,
"summary":"@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf",
"author": {
"name":"Barnaby Walters",
"photo":"http://waterpigs.co.uk/photo.jpg",
"url":"http://waterpigs.co.uk/"
},
"interactions": ["http://www.kevinmarks.com/indiewebsfdemowrapup.html"],
"targets":["http://kevinmarks.com/"],
"type":"reply",
"interactionTarget":false
}
</source>

=== [https://github.com/indieweb/php-comments php-comments] library ===
This library takes HTML and converts it to a simple PHP data structure. Example post:

<source lang="php">
$result = array(
'type' => 'reply',
'author' => array(
'name' => 'Aaron Parecki',
'photo' => 'http://aaronparecki.com/images/aaronpk.png',
'url' => 'http://aaronparecki.com/'
),
'published' => '2014-02-16T18:48:17-0800',
'name' => 'Example Note',
'text' => 'this text is displayed as the comment',
'url' => 'http://aaronparecki.com/post/1'
);
</source>

== Name Candidates ==
As 'jf2' is only a working name let's collect alternatives:

;JFDI
:Backronym: JSON For Data Interchange
;jf2
:Minimal JSON for mf2

== Links ==
* [https://github.com/dissolve/jf2 github.com/dissolve/jf2] - Primary development
* [https://github.com/dissolve/socialstream github.com/dissolve/socialstream] - Sample php code to convert MF2 -> JS2
* [http://stream.thatmustbe.us/ stream.thatmustbe.us] - Service running the socialstream code
* [http://www.unmung.com/ unmung.com] - another conversion service that can convert mf2 to jf2

== See Also ==
* [[json]]
* [[microformats2]]
* [[microformats2-parsing]]

jf2

2015-11-03T21:04:29Z

Benthatmustbeme: Undo revision 65290 by Veganstraightedge (Talk) thats not a recursive acronym

{{stub}}

'''<dfn>jf2</dfn>''' is a working name for a simplified more minimal JSON representation of [[microformats2]].

== Basic Example ==
<source lang="javascript">
{
"type": "entry",
"author": {
"type": "card",
"name": "Tantek Çelik",
"url": "http:\/\/tantek.com\/",
"photo": {
"type": "image",
"url": "http:\/\/tantek.com\/photo.jpg"
}
},
"published": "2015-10-21T12:34-0700",
"category": ["simple", "example"],
"content": "Example of a simple note"
}
</source>

== Prior Work ==
* [[microformats2]] JSON

== Prior Simplifications ==
Output from:

=== [http://webmention.io webmention.io] ===
This service outputs a list of webmentions received for a post. It recognizes when a post is a reply, like, repost, invitation, RSVP, and mention. Example JSON output:

<source lang="javascript">
{
"source": "http://tantek.com/2013/112/t2/milestone-show-indieweb-comments-h-entry-pingback",
"verified": true,
"verified_date": "2013-04-25T17:09:33-07:00",
"id": 900,
"data": {
"author": {
"name": "Tantek Çelik",
"url": "http://tantek.com/",
"photo": "http://tantek.com/logo.jpg"
},
"name": "Another milestone: @eschnou automatically shows #indieweb comments with h-entry sent via pingback http://eschnou.com/entry/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html",
"content": "Another milestone: <a class=\"auto-link h-x-username\" href=\"https:\/\/twitter.com\/eschnou\">@eschnou<\/a> automatically shows #indieweb comments with h-entry sent via pingback <a class=\"auto-link\" href=\"http:\/\/eschnou.com\/entry\/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html\">http:\/\/eschnou.com\/entry\/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html<\/a>",
"published": "2013-04-22T15:03:00-07:00",
"published_ts": 1366668180,
"url": "http://tantek.com/2013/112/t2/milestone-show-indieweb-comments-h-entry-pingback"
}
}
</source>

=== webmention.herokuapp.com ===
This site outputs in multiple formats, based on receiving webmentions, parsing them for microformats and consolidating into a single feed. Live examples for kevinmarks.com:
*[https://webmention.herokuapp.com/api/mentions?site=kevinmarks.com&format=html HTML mf2 markup]
<source lang=html4strict>
<div class="h-entry">
<a href="http://waterpigs.co.uk/" class="p-author h-card">
<img src="http://waterpigs.co.uk/photo.jpg" alt="">
Barnaby Walters
</a>
<div class="p-summary p-name">@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf</div>
<footer>
<time class="dt-published" datetime="2014-04-01T14:25:14.000Z" pubdate="">
<a class="u-url u-uid" href="http://waterpigs.co.uk/notes/4VMERE/">2 years ago</a>
</time>
mentioning <a href="http://kevinmarks.com/">http://kevinmarks.com/</a>
</footer>
</div>
</source>
*[http://www.unmung.com/mf2?url=https%3A%2F%2Fwebmention.herokuapp.com%2Fapi%2Fmentions%3Fsite%3Dkevinmarks.com%26format%3Dhtml&html=&pretty=on parsed JSON form of the HTML]
<source lang=javascript>
{
"type": ["h-entry"],
"properties": {
"uid": ["http://waterpigs.co.uk/notes/4VMERE/"],
"author": [
{"type": ["h-card"],
"properties": {
"url": ["http://waterpigs.co.uk/"],
"photo": ["http://waterpigs.co.uk/photo.jpg"],
"name": [""]
},
"value": "Barnaby Walters"
}],
"url": ["http://waterpigs.co.uk/notes/4VMERE/"],
"summary": ["@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf"],
"published": ["2014-04-01T14:25:14Z"],
"name": [ "@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf"]
}
}
</source>
*[https://webmention.herokuapp.com/api/mentions?site=kevinmarks.com&format=json simplified JSON] (whitespace added)
<source lang=javascript>
{
"url":"http://waterpigs.co.uk/notes/4VMERE/",
"name":null,
"published":1396362314000,
"summary":"@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf",
"author": {
"name":"Barnaby Walters",
"photo":"http://waterpigs.co.uk/photo.jpg",
"url":"http://waterpigs.co.uk/"
},
"interactions": ["http://www.kevinmarks.com/indiewebsfdemowrapup.html"],
"targets":["http://kevinmarks.com/"],
"type":"reply",
"interactionTarget":false
},
</source>

=== [https://github.com/indieweb/php-comments php-comments] library ===
This library takes HTML and converts it to a simple PHP data structure. Example post:

<source lang="php">
$result = array(
'type' => 'reply',
'author' => array(
'name' => 'Aaron Parecki',
'photo' => 'http://aaronparecki.com/images/aaronpk.png',
'url' => 'http://aaronparecki.com/'
),
'published' => '2014-02-16T18:48:17-0800',
'name' => 'Example Note',
'text' => 'this text is displayed as the comment',
'url' => 'http://aaronparecki.com/post/1'
);
</source>

== Name Candidates ==
As 'jf2' is only a working name let's collect alternatives:

;JFDI
:Backronym: JSON For Data Interchange
;jf2
:Minimal JSON for mf2

== Links ==
* [https://github.com/w3c-social/Social-Syntax-Brainstorming/wiki/jf2 github.com/w3c-social/Social-Syntax-Brainstorming/wiki/jf2] - Primary development
* [https://github.com/dissolve/socialstream github.com/dissolve/socialstream] - Sample php code to convert MF2 -> JS2
* [http://stream.thatmustbe.us/?url=ben.thatmustbe.me/feed stream.thatmustbe.us/?url=ben.thatmustbe.me/feed] - Service running the socialstream code

== See Also ==
* [[json]]
* [[microformats2]]
* [[microformats2-parsing]]

jf2

2015-10-30T15:19:49Z

Benthatmustbeme: /* Links */ actually fix the link, not just the label

{{stub}}

'''<dfn>jf2</dfn>''' is a working name for a simplified more minimal JSON representation of [[microformats2]].

== Basic Example ==
<source lang="javascript">
{
"type": "entry",
"author": {
"type": "card",
"name": "Tantek Çelik",
"url": "http:\/\/tantek.com\/",
"photo": "http:\/\/tantek.com\/photo.jpg"
},
"published": "2015-10-21T12:34-0700",
"category": ["simple", "example"],
"content": "Example of a simple note"
}
</source>

== Prior Work ==
* [[microformats2]] JSON

== Prior Simplifications ==
Output from:

=== [http://webmention.io webmention.io] ===
This service outputs a list of webmentions received for a post. It recognizes when a post is a reply, like, repost, invitation, RSVP, and mention. Example JSON output:

<source lang="javascript">
{
"source": "http://tantek.com/2013/112/t2/milestone-show-indieweb-comments-h-entry-pingback",
"verified": true,
"verified_date": "2013-04-25T17:09:33-07:00",
"id": 900,
"data": {
"author": {
"name": "Tantek Çelik",
"url": "http://tantek.com/",
"photo": "http://tantek.com/logo.jpg"
},
"name": "Another milestone: @eschnou automatically shows #indieweb comments with h-entry sent via pingback http://eschnou.com/entry/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html",
"content": "Another milestone: <a class=\"auto-link h-x-username\" href=\"https:\/\/twitter.com\/eschnou\">@eschnou<\/a> automatically shows #indieweb comments with h-entry sent via pingback <a class=\"auto-link\" href=\"http:\/\/eschnou.com\/entry\/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html\">http:\/\/eschnou.com\/entry\/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html<\/a>",
"published": "2013-04-22T15:03:00-07:00",
"published_ts": 1366668180,
"url": "http://tantek.com/2013/112/t2/milestone-show-indieweb-comments-h-entry-pingback"
}
}
</source>

=== webmention.herokuapp.com ===
This site outputs in multiple formats, based on receiving webmentions, parsing them for microformats and consolidating into a single feed. Live examples for kevinmarks.com:
*[https://webmention.herokuapp.com/api/mentions?site=kevinmarks.com&format=html HTML mf2 markup]
<source lang=html4strict>
<div class="h-entry">
<a href="http://waterpigs.co.uk/" class="p-author h-card">
<img src="http://waterpigs.co.uk/photo.jpg" alt="">
Barnaby Walters
</a>
<div class="p-summary p-name">@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf</div>
<footer>
<time class="dt-published" datetime="2014-04-01T14:25:14.000Z" pubdate="">
<a class="u-url u-uid" href="http://waterpigs.co.uk/notes/4VMERE/">2 years ago</a>
</time>
mentioning <a href="http://kevinmarks.com/">http://kevinmarks.com/</a>
</footer>
</div>
</source>
*[http://www.unmung.com/mf2?url=https%3A%2F%2Fwebmention.herokuapp.com%2Fapi%2Fmentions%3Fsite%3Dkevinmarks.com%26format%3Dhtml&html=&pretty=on parsed JSON form of the HTML]
<source lang=javascript>
{
"type": ["h-entry"],
"properties": {
"uid": ["http://waterpigs.co.uk/notes/4VMERE/"],
"author": [
{"type": ["h-card"],
"properties": {
"url": ["http://waterpigs.co.uk/"],
"photo": ["http://waterpigs.co.uk/photo.jpg"],
"name": [""]
},
"value": "Barnaby Walters"
}],
"url": ["http://waterpigs.co.uk/notes/4VMERE/"],
"summary": ["@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf"],
"published": ["2014-04-01T14:25:14Z"],
"name": [ "@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf"]
}
}
</source>
*[https://webmention.herokuapp.com/api/mentions?site=kevinmarks.com&format=json simplified JSON] (whitespace added)
<source lang=javascript>
{
"url":"http://waterpigs.co.uk/notes/4VMERE/",
"name":null,
"published":1396362314000,
"summary":"@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf",
"author": {
"name":"Barnaby Walters",
"photo":"http://waterpigs.co.uk/photo.jpg",
"url":"http://waterpigs.co.uk/"
},
"interactions": ["http://www.kevinmarks.com/indiewebsfdemowrapup.html"],
"targets":["http://kevinmarks.com/"],
"type":"reply",
"interactionTarget":false
},
</source>

=== [https://github.com/indieweb/php-comments php-comments] library ===
This library takes HTML and converts it to a simple PHP data structure. Example post:

<source lang="php">
$result = array(
'type' => 'reply',
'author' => array(
'name' => 'Aaron Parecki',
'photo' => 'http://aaronparecki.com/images/aaronpk.png',
'url' => 'http://aaronparecki.com/'
),
'published' => '2014-02-16T18:48:17-0800',
'name' => 'Example Note',
'text' => 'this text is displayed as the comment',
'url' => 'http://aaronparecki.com/post/1'
);
</source>

== Name Candidates ==
As 'jf2' is only a working name let's collect alternatives:

;JFDI
:Backronym: JSON For Data Interchange
;jf2
:Minimal JSON for mf2

== Links ==
* [https://github.com/w3c-social/Social-Syntax-Brainstorming/wiki/jf2 github.com/w3c-social/Social-Syntax-Brainstorming/wiki/jf2] - Primary development
* [https://github.com/dissolve/socialstream github.com/dissolve/socialstream] - Sample php code to convert MF2 -> JS2
* [http://stream.thatmustbe.us/?url=ben.thatmustbe.me/feed stream.thatmustbe.us/?url=ben.thatmustbe.me/feed] - Service running the socialstream code

== See Also ==
* [[json]]
* [[microformats2]]
* [[microformats2-parsing]]

jf2

2015-10-30T11:07:04Z

Benthatmustbeme: /* Links */ correct link

{{stub}}

'''<dfn>jf2</dfn>''' is a working name for a simplified more minimal JSON representation of [[microformats2]].

== Basic Example ==
<source lang="javascript">
{
"type": "entry",
"author": {
"type": "card",
"name": "Tantek Çelik",
"url": "http:\/\/tantek.com\/",
"photo": "http:\/\/tantek.com\/photo.jpg"
},
"published": "2015-10-21T12:34-0700",
"category": ["simple", "example"],
"content": "Example of a simple note"
}
</source>

== Prior Work ==
* [[microformats2]] JSON

== Prior Simplifications ==
Output from:

=== [http://webmention.io webmention.io] ===
This service outputs a list of webmentions received for a post. It recognizes when a post is a reply, like, repost, invitation, RSVP, and mention. Example JSON output:

<source lang="javascript">
{
"source": "http://tantek.com/2013/112/t2/milestone-show-indieweb-comments-h-entry-pingback",
"verified": true,
"verified_date": "2013-04-25T17:09:33-07:00",
"id": 900,
"data": {
"author": {
"name": "Tantek Çelik",
"url": "http://tantek.com/",
"photo": "http://tantek.com/logo.jpg"
},
"name": "Another milestone: @eschnou automatically shows #indieweb comments with h-entry sent via pingback http://eschnou.com/entry/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html",
"content": "Another milestone: <a class=\"auto-link h-x-username\" href=\"https:\/\/twitter.com\/eschnou\">@eschnou<\/a> automatically shows #indieweb comments with h-entry sent via pingback <a class=\"auto-link\" href=\"http:\/\/eschnou.com\/entry\/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html\">http:\/\/eschnou.com\/entry\/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html<\/a>",
"published": "2013-04-22T15:03:00-07:00",
"published_ts": 1366668180,
"url": "http://tantek.com/2013/112/t2/milestone-show-indieweb-comments-h-entry-pingback"
}
}
</source>

=== webmention.herokuapp.com ===
This site outputs in multiple formats, based on receiving webmentions, parsing them for microformats and consolidating into a single feed. Live examples for kevinmarks.com:
*[https://webmention.herokuapp.com/api/mentions?site=kevinmarks.com&format=html HTML mf2 markup]
<source lang=html4strict>
<div class="h-entry">
<a href="http://waterpigs.co.uk/" class="p-author h-card">
<img src="http://waterpigs.co.uk/photo.jpg" alt="">
Barnaby Walters
</a>
<div class="p-summary p-name">@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf</div>
<footer>
<time class="dt-published" datetime="2014-04-01T14:25:14.000Z" pubdate="">
<a class="u-url u-uid" href="http://waterpigs.co.uk/notes/4VMERE/">2 years ago</a>
</time>
mentioning <a href="http://kevinmarks.com/">http://kevinmarks.com/</a>
</footer>
</div>
</source>
*[http://www.unmung.com/mf2?url=https%3A%2F%2Fwebmention.herokuapp.com%2Fapi%2Fmentions%3Fsite%3Dkevinmarks.com%26format%3Dhtml&html=&pretty=on parsed JSON form of the HTML]
<source lang=javascript>
{
"type": ["h-entry"],
"properties": {
"uid": ["http://waterpigs.co.uk/notes/4VMERE/"],
"author": [
{"type": ["h-card"],
"properties": {
"url": ["http://waterpigs.co.uk/"],
"photo": ["http://waterpigs.co.uk/photo.jpg"],
"name": [""]
},
"value": "Barnaby Walters"
}],
"url": ["http://waterpigs.co.uk/notes/4VMERE/"],
"summary": ["@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf"],
"published": ["2014-04-01T14:25:14Z"],
"name": [ "@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf"]
}
}
</source>
*[https://webmention.herokuapp.com/api/mentions?site=kevinmarks.com&format=json simplified JSON] (whitespace added)
<source lang=javascript>
{
"url":"http://waterpigs.co.uk/notes/4VMERE/",
"name":null,
"published":1396362314000,
"summary":"@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf",
"author": {
"name":"Barnaby Walters",
"photo":"http://waterpigs.co.uk/photo.jpg",
"url":"http://waterpigs.co.uk/"
},
"interactions": ["http://www.kevinmarks.com/indiewebsfdemowrapup.html"],
"targets":["http://kevinmarks.com/"],
"type":"reply",
"interactionTarget":false
},
</source>

=== [https://github.com/indieweb/php-comments php-comments] library ===
This library takes HTML and converts it to a simple PHP data structure. Example post:

<source lang="php">
$result = array(
'type' => 'reply',
'author' => array(
'name' => 'Aaron Parecki',
'photo' => 'http://aaronparecki.com/images/aaronpk.png',
'url' => 'http://aaronparecki.com/'
),
'published' => '2014-02-16T18:48:17-0800',
'name' => 'Example Note',
'text' => 'this text is displayed as the comment',
'url' => 'http://aaronparecki.com/post/1'
);
</source>

== Name Candidates ==
As 'jf2' is only a working name let's collect alternatives:

;JFDI
:Backronym: JSON For Data Interchange
;jf2
:Minimal JSON for mf2

== Links ==
* [https://github.com/w3c-social/Social-Syntax-Brainstorming/wiki/Minimal-Activity-Stream github.com/w3c-social/Social-Syntax-Brainstorming/wiki/jf2] - Primary development
* [https://github.com/dissolve/socialstream github.com/dissolve/socialstream] - Sample php code to convert MF2 -> JS2
* [http://stream.thatmustbe.us/?url=ben.thatmustbe.me/feed stream.thatmustbe.us/?url=ben.thatmustbe.me/feed] - Service running the socialstream code

== See Also ==
* [[json]]
* [[microformats2]]
* [[microformats2-parsing]]

jf2

2015-10-29T19:08:42Z

Benthatmustbeme: add important links

{{stub}}

'''<dfn>jf2</dfn>''' is a working name for a simplified more minimal JSON representation of [[microformats2]].

== Basic Example ==
<source lang="javascript">
{
"type": "entry",
"author": {
"type": "card",
"name": "Tantek Çelik",
"url": "http:\/\/tantek.com\/",
"photo": "http:\/\/tantek.com\/photo.jpg"
},
"published": "2015-10-21T12:34-0700",
"category": ["simple", "example"],
"content": "Example of a simple note"
}
</source>

== Prior Work ==
* [[microformats2]] JSON

== Prior Simplifications ==
Output from:

=== [http://webmention.io webmention.io] ===
This service outputs a list of webmentions received for a post. It recognizes when a post is a reply, like, repost, invitation, RSVP, and mention. Example JSON output:

<source lang="javascript">
{
"source": "http://tantek.com/2013/112/t2/milestone-show-indieweb-comments-h-entry-pingback",
"verified": true,
"verified_date": "2013-04-25T17:09:33-07:00",
"id": 900,
"data": {
"author": {
"name": "Tantek Çelik",
"url": "http://tantek.com/",
"photo": "http://tantek.com/logo.jpg"
},
"name": "Another milestone: @eschnou automatically shows #indieweb comments with h-entry sent via pingback http://eschnou.com/entry/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html",
"content": "Another milestone: <a class=\"auto-link h-x-username\" href=\"https:\/\/twitter.com\/eschnou\">@eschnou<\/a> automatically shows #indieweb comments with h-entry sent via pingback <a class=\"auto-link\" href=\"http:\/\/eschnou.com\/entry\/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html\">http:\/\/eschnou.com\/entry\/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html<\/a>",
"published": "2013-04-22T15:03:00-07:00",
"published_ts": 1366668180,
"url": "http://tantek.com/2013/112/t2/milestone-show-indieweb-comments-h-entry-pingback"
}
}
</source>

=== webmention.herokuapp.com ===
This site outputs in multiple formats, based on receiving webmentions, parsing them for microformats and consolidating into a single feed. Live examples for kevinmarks.com:
*[https://webmention.herokuapp.com/api/mentions?site=kevinmarks.com&format=html HTML mf2 markup]
<source lang=html4strict>
<div class="h-entry">
<a href="http://waterpigs.co.uk/" class="p-author h-card">
<img src="http://waterpigs.co.uk/photo.jpg" alt="">
Barnaby Walters
</a>
<div class="p-summary p-name">@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf</div>
<footer>
<time class="dt-published" datetime="2014-04-01T14:25:14.000Z" pubdate="">
<a class="u-url u-uid" href="http://waterpigs.co.uk/notes/4VMERE/">2 years ago</a>
</time>
mentioning <a href="http://kevinmarks.com/">http://kevinmarks.com/</a>
</footer>
</div>
</source>
*[http://www.unmung.com/mf2?url=https%3A%2F%2Fwebmention.herokuapp.com%2Fapi%2Fmentions%3Fsite%3Dkevinmarks.com%26format%3Dhtml&html=&pretty=on parsed JSON form of the HTML]
<source lang=javascript>
{
"type": ["h-entry"],
"properties": {
"uid": ["http://waterpigs.co.uk/notes/4VMERE/"],
"author": [
{"type": ["h-card"],
"properties": {
"url": ["http://waterpigs.co.uk/"],
"photo": ["http://waterpigs.co.uk/photo.jpg"],
"name": [""]
},
"value": "Barnaby Walters"
}],
"url": ["http://waterpigs.co.uk/notes/4VMERE/"],
"summary": ["@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf"],
"published": ["2014-04-01T14:25:14Z"],
"name": [ "@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf"]
}
}
</source>
*[https://webmention.herokuapp.com/api/mentions?site=kevinmarks.com&format=json simplified JSON] (whitespace added)
<source lang=javascript>
{
"url":"http://waterpigs.co.uk/notes/4VMERE/",
"name":null,
"published":1396362314000,
"summary":"@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf",
"author": {
"name":"Barnaby Walters",
"photo":"http://waterpigs.co.uk/photo.jpg",
"url":"http://waterpigs.co.uk/"
},
"interactions": ["http://www.kevinmarks.com/indiewebsfdemowrapup.html"],
"targets":["http://kevinmarks.com/"],
"type":"reply",
"interactionTarget":false
},
</source>

=== [https://github.com/indieweb/php-comments php-comments] library ===
This library takes HTML and converts it to a simple PHP data structure. Example post:

<source lang="php">
$result = array(
'type' => 'reply',
'author' => array(
'name' => 'Aaron Parecki',
'photo' => 'http://aaronparecki.com/images/aaronpk.png',
'url' => 'http://aaronparecki.com/'
),
'published' => '2014-02-16T18:48:17-0800',
'name' => 'Example Note',
'text' => 'this text is displayed as the comment',
'url' => 'http://aaronparecki.com/post/1'
);
</source>

== Name Candidates ==
As 'jf2' is only a working name let's collect alternatives:

;JDFI
:Backronym: JSON For Data Interchange
;jf2
:Minimal JSON for mf2

== Links ==
* [https://github.com/w3c-social/Social-Syntax-Brainstorming/wiki/Minimal-Activity-Stream github.com/w3c-social/Social-Syntax-Brainstorming/wiki/Minimal-Activity-Stream] - Primary development
* [https://github.com/dissolve/socialstream github.com/dissolve/socialstream] - Sample php code to convert MF2 -> JS2
* [http://stream.thatmustbe.us/?url=ben.thatmustbe.me/feed stream.thatmustbe.us/?url=ben.thatmustbe.me/feed] - Service running the socialstream code

== See Also ==
* [[json]]
* [[microformats2]]
* [[microformats2-parsing]]