microformats2

(Difference between revisions)

Jump to: navigation, search
m (Tweaked markup and phrasing)
Current revision (23:46, 28 October 2017) (view source)
(Examples in the wild)
 
(12 intermediate revisions not shown.)
Line 3: Line 3:
== Summary ==
== 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 is the latest version of microformats, 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]].
+
Microformats2 replaces and supersedes both classic microformats (sometimes called microformats1), as well as incorporates lessons learned from [[microdata]] and [[RDFa]].
-
=== simple microformats 2 examples ===
+
=== simple microformats2 examples ===
-
Here are a few simple microformats2 examples along with canonical [[JSON]].
+
Here are a few <span id="simple_microformats_2_examples">simple microformats2 examples</span> along with canonical [[JSON]].
==== person example ====
==== person example ====
Line 143: Line 143:
* <code>e-*</code> for embedded markup properties (e.g. <code>e-note</code>)<br />
* <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.
+
See [[microformats2-prefixes]] for more details.
; Flat sets of optional properties
; Flat sets of optional properties
Line 200: Line 200:
* '''<code>p-altitude</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.
+
For backward compatibility, microformats2 parsers {{should}} detect the following root class name and property names. A microformats2 parser may use existing classic 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/>
compat root class name: <code id="adr">adr</code><br/>
Line 268: Line 268:
* ...
* ...
-
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.
+
For backward compatibility, microformats2 parsers {{should}} detect the following root class name and property names. A microformats2 parser may use existing classic 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/>
compat root class name: <code id="vcard">vcard</code><br/>
Line 350: Line 350:
(*)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>.
(*)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.
+
For hAtom backward compatibility, microformats2 parsers {{should}} detect the following root class name and property names. A microformats2 parser may use existing classic 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/>
compat root class name: <code id="hentry">hentry</code><br/>
Line 409: Line 409:
(*)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>.
(*)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.
+
For backward compatibility, microformats2 parsers {{should}} detect the following root class name and property names. A microformats2 parser may use existing classic 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/>
compat root class name: <code id="vevent">vevent</code><br/>
Line 439: Line 439:
* '''<code>p-altitude</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-geo" is found, don't look for an "geo" on the same element.
+
For backward compatibility, microformats2 parsers {{should}} detect the following root class name and property names. A microformats2 parser may use existing classic 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>
compat root class name: <code id="geo">geo</code>
Line 480: Line 480:
* '''<code>p-price</code>''' - retail price of the product
* '''<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.
+
For backward compatibility, microformats2 parsers {{should}} detect the following root class name and property names. A microformats2 parser may use existing classic 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/>
compat root class name: <code id="hproduct">hproduct</code><br/>
Line 519: Line 519:
* ...
* ...
-
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.
+
For backward compatibility, microformats2 parsers {{should}} detect the following root class name and property names. A microformats2 parser may use existing classic 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/>
compat root class name: <code id="hrecipe">hrecipe</code><br/>
Line 551: Line 551:
* '''<code>p-affiliation</code>''' - an affiliation with an <code>h-card</code> organization
* '''<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.
+
For backward compatibility, microformats2 parsers {{should}} detect the following root class name and property names. A microformats2 parser may use existing classic 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/>
compat root class name: <code id="hresume">hresume</code><br/>
Line 584: Line 584:
* '''<code>u-url</code>''' - URL of the review
* '''<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.
+
For backward compatibility, microformats2 parsers {{should}} detect the following root class name and property names. A microformats2 parser may use existing classic 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/>
compat root class name: <code id="hreview">hreview</code><br/>
Line 601: Line 601:
* <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.
* <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.
+
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>. Microformats2 parsers {{should}} map these URLs into the page scoped rel collection.
=== h-review-aggregate ===
=== h-review-aggregate ===
Line 622: Line 622:
* '''<code>u-url</code>''' - URL of the review
* '''<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.
+
For backward compatibility, microformats2 parsers {{should}} detect the following root class name and property names. A microformats2 parser may use existing classic 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/>
compat root class name: <code id="hreview-aggregate">hreview-aggregate</code><br/>
Line 643: Line 643:
* 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.
* 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> &amp; <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).  
* Profile URLs are provided for use with the HTML4 <code>profile</code> attribute, microdata <code>itemtype</code> attribute, and RDFa <code>vocab</code> &amp; <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.
+
* microformats2 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 ===
=== v2 vocab to-do ===
Line 657: Line 657:
== combining microformats ==
== combining microformats ==
-
Since microformats 2 uses simple flat sets of properties for each microformat, multiple microformats are combined to indicate additional structure.
+
Since microformats2 uses simple flat sets of properties for each microformat, multiple microformats are combined to indicate additional structure.
=== h-event location h-card ===
=== h-event location h-card ===
Line 932: Line 932:
=== backward compatible ===
=== 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.
+
If you depend on current microformats [[implementations]], while they're being updated to support [[microformats2]], you can include both existing classic microformats and microformats2 markup.
In short: use both sets of class names simultaneously.  
In short: use both sets of class names simultaneously.  
Line 1,015: Line 1,015:
* Matthias Pfefferle marks up his blog posts, comments and profile with h-card, h-cite and h-entry on [http://notizblog.org/ notizblog.org]
* 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]
* 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])
* 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])
* 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])
Line 1,055: Line 1,054:
=== Converters ===
=== 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.
* '''[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.
Line 1,067: Line 1,065:
==== Parsers in production ====
==== Parsers in production ====
The following parsers are of very high quality, in active development, and use on live sites on the web 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 =====
===== Javascript =====
Line 1,074: Line 1,075:
** blog post: http://glennjones.net/2013/01/brand-new-microformats-2-parser/
** blog post: http://glennjones.net/2013/01/brand-new-microformats-2-parser/
** live: http://glennjones.net/tools/microformats/
** live: http://glennjones.net/tools/microformats/
-
* '''microformat-shiv'''  - cross browser javascript microformats 2 parser which can also be used in browser extensions.
+
** command line: https://github.com/JerrySievert/mf2
 +
* '''microformat-shiv'''  - cross browser javascript microformats2 parser which can also be used in browser extensions.
** http://microformatshiv.com/
** http://microformatshiv.com/
** github open source: https://github.com/glennjones/microformat-shiv
** github open source: https://github.com/glennjones/microformat-shiv
Line 1,096: Line 1,098:
*** another textarea: http://www.unmung.com/?html=
*** another textarea: http://www.unmung.com/?html=
*** URL and/or textarea: https://kylewm.com/services/mf2
*** URL and/or textarea: https://kylewm.com/services/mf2
 +
 +
===== Ruby =====
 +
* '''indieweb/microformats-ruby''' Ruby microformats parser
 +
** github open source: https://github.com/indieweb/microformats-ruby
 +
** live text entry: https://microformats-parser-ruby.herokuapp.com
 +
 +
===== Haskell =====
 +
* '''myfreeweb/microformats2-parser''' Haskell microformats2 parser
 +
** github open source: https://github.com/myfreeweb/microformats2-parser
 +
** live textarea entry: https://unrelenting.technology/mf2/
==== Development parsers ====
==== 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!
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 =====
===== Elixir =====
Line 1,105: Line 1,121:
===== Go =====
===== Go =====
-
* '''andyleap/microformats''' Golang microformats2 parser
+
* '''willnorris/microformats''' Golang microformats2 parser
-
** github open source: https://github.com/andyleap/microformats
+
** github open source: https://github.com/willnorris/microformats
-
** live textarea entry: http://mf2.vendaria.net
+
** live textarea entry: https://go.microformats.io/
-
 
+
-
===== Haskell =====
+
-
* '''myfreeweb/microformats2-parser''' Haskell microformats2 parser
+
-
** github open source: https://github.com/myfreeweb/microformats2-parser
+
-
** live textarea entry: https://unrelenting.technology/mf2/
+
===== Java =====
===== Java =====
Line 1,123: Line 1,134:
** live: https://mf2j.herokuapp.com/?url={http://example.com}
** live: https://mf2j.herokuapp.com/?url={http://example.com}
-
===== Ruby =====
+
==== Experiments ====
-
* '''G5/microformats2''' Ruby microformats2 parser
+
Experiments and other proof of concept microformat2 parsing support.
-
** github open source: https://github.com/G5/microformats2
+
* ...
 +
 
 +
=== Outreach ===
 +
* [https://github.com/mozilla/fathom/issues/42 Mozilla Fathom:  examples with nested classes, e.g. microformats2]
== Presentations ==
== Presentations ==
Line 1,140: Line 1,154:
== About This Brainstorm ==
== 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 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 microformats2 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.
+
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 microformats2.
-
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).
+
This mathematical proof/derivation style is used to explicitly encourage understanding (and double-checking) of the rational steps taken in the development of microformats2. 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.
+
When the microformats2 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]]
— [[User:Tantek|Tantek]]
Line 1,251: Line 1,265:
** "hreview" 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)
** "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)
+
** '''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|microformats2 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'
*** 'p-name'
*** 'u-url'
*** 'u-url'
Line 1,299: Line 1,313:
* See: [[issues#class-collisions]]
* See: [[issues#class-collisions]]
-
Thus microformats 2 uses ''prefixes'' for property class names, e.g.:
+
Thus microformats2 uses ''prefixes'' for property class names, e.g.:
* '''p-summary''' instead of ''summary''
* '''p-summary''' instead of ''summary''
* '''u-photo''' instead of ''photo''  
* '''u-photo''' instead of ''photo''  
Line 1,306: Line 1,320:
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.
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.
+
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 microformats2 is adopting. See the next section for details.
=== COMMUNITY and TOOLS ===
=== COMMUNITY and TOOLS ===
Line 1,361: Line 1,375:
</source>
</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 part of microformats2 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 microformats2 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.
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.
+
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 microformats2. 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 ===
=== ADVANTAGES ===
Line 1,372: Line 1,386:
* '''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.
* '''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.
* '''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.
+
* '''separation of syntax and vocabulary''' - by abstracting microformats2 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:
More examples: here is that same heading example with name components:
Line 1,400: Line 1,414:
=== COMPATIBILITY ===
=== 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.
+
microformats2 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:
Here is a simple example:
Line 1,410: Line 1,424:
</source>
</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]].
+
a microformats2 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:
And the above hyperlinked example with both sets of class names:

Current revision

Welcome to the microformats2 home page.

Contents

Summary

Microformats2 is the latest version of microformats, the simplest way to markup structured information in HTML. Microformats2 improves ease of use and implementation for both authors (publishers) and developers (parser implementers).

Microformats2 replaces and supersedes both classic microformats (sometimes called microformats1), as well as incorporates lessons learned from microdata and RDFa.

simple microformats2 examples

Here are a few simple microformats2 examples along with canonical JSON.

person example

<span class="h-card">Frances Berriman</span>

Parsed JSON:

{
  "items": [{ 
    "type": ["h-card"],
    "properties": {
      "name": ["Frances Berriman"] 
    }
  }]
}



hyperlinked person

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

Parsed JSON:

{
  "items": [{ 
    "type": ["h-card"],
    "properties": {
      "name": ["Ben Ward"],
      "url": ["http://benward.me"]
    }
  }]
}



hyperlinked person image

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

Parsed JSON:

{
  "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"]
    }
  }]
}

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



detailed person example

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

Parsed JSON:

{
  "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"
      ]
    }
  }]
}



Notes:

  1. The JSON "type" uses the full microformat root class name (e.g. "h-card") for consistent identification.
  2. 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.

See microformats2-prefixes 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: name, url, photo. The simple microformats2 examples above demonstrate these.




Parsing each prefix (including generating canonical JSON) is detailed step-by-step in:

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: draft. Please review and provide feedback in IRC.

See below for vocabulary summaries.

h-adr

Main article: 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: h-adr
profile/itemtype: http://microformats.org/profile/h-adr

properties:

For backward compatibility, microformats2 parsers SHOULD detect the following root class name and property names. A microformats2 parser may use existing classic 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: adr
properties: (parsed as p- plain text unless otherwise specified)

h-card

Main article: h-card

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

root class name: h-card
profile/itemtype: http://microformats.org/profile/h-card

properties:

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

For backward compatibility, microformats2 parsers SHOULD detect the following root class name and property names. A microformats2 parser may use existing classic 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: vcard
properties: (parsed as p- plain text unless otherwise specified)

Reserved: (backward compat properties that parsers MAY implement, if they do, they MUST implement in this way:

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 article: 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: h-entry
profile/itemtype: http://microformats.org/profile/h-entry

properties:

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:

Backward compatibility:

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

For hAtom backward compatibility, microformats2 parsers SHOULD detect the following root class name and property names. A microformats2 parser may use existing classic 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: hentry
properties: (parsed as p- plain text unless otherwise specified)

FAQ:

  • What is the p-name of a note?
    • A few options, from simplest to most detailed.
      • same as the p-content/e-content property.
      • same as the title 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 syndication and link-preview purposes to provide just the first sentence of the note as the p-name. Similarly if only a portion of the content is syndicated to other sites, that portion can be marked up as the p-summary.
  • ...

Resolved Issues:

h-event

Main article: h-event

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

root class name: h-event
profile/itemtype: http://microformats.org/profile/h-event

properties:

This is an update to hCalendar.

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

For backward compatibility, microformats2 parsers SHOULD detect the following root class name and property names. A microformats2 parser may use existing classic 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: vevent
properties: (parsed as p- plain text unless otherwise specified)

h-geo

Main article: h-geo

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

root class name: h-geo
profile/itemtype: http://microformats.org/profile/h-geo

properties:

For backward compatibility, microformats2 parsers SHOULD detect the following root class name and property names. A microformats2 parser may use existing classic 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: geo properties: (parsed as p- plain text unless otherwise specified)

h-item

Main article: 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: h-item
profile/itemtype: http://microformats.org/profile/h-item

properties:

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 article: h-product

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

root class name: h-product
profile/itemtype: http://microformats.org/profile/h-product

properties:

For backward compatibility, microformats2 parsers SHOULD detect the following root class name and property names. A microformats2 parser may use existing classic 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: hproduct
properties: (parsed as p- plain text unless otherwise specified)

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 article: h-recipe

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

root class name: h-recipe
profile/itemtype: http://microformats.org/profile/h-recipe

properties:

Experimental properties with wide adoption

For backward compatibility, microformats2 parsers SHOULD detect the following root class name and property names. A microformats2 parser may use existing classic 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: hrecipe
properties: (parsed as p- plain text unless otherwise specified)

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 article: h-resume

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

root class name: h-resume
profile/itemtype: http://microformats.org/profile/h-resume

properties:

For backward compatibility, microformats2 parsers SHOULD detect the following root class name and property names. A microformats2 parser may use existing classic 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: hresume
properties: (parsed as p- plain text unless otherwise specified)

Note: skill has a 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 article: h-review

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

root class name: h-review
profile/itemtype: http://microformats.org/profile/h-review

properties:

For backward compatibility, microformats2 parsers SHOULD detect the following root class name and property names. A microformats2 parser may use existing classic 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: hreview
properties: (parsed as p- plain text unless otherwise specified)

Note: The hReview format has three properties which make use of rel attribute, these are tag, permalink (via the self and bookmark values) and license. Microformats2 parsers SHOULD map these URLs into the page scoped rel collection.

h-review-aggregate

Main article: 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: h-review-aggregate
profile/itemtype: http://microformats.org/profile/h-review-aggregate

properties:

For backward compatibility, microformats2 parsers SHOULD detect the following root class name and property names. A microformats2 parser may use existing classic 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: hreview-aggregate
properties: (parsed as p- plain text unless otherwise specified)


v2 vocab notes

Notes:

v2 vocab to-do

To do:

combining microformats

Since microformats2 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:

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

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:

{
  "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"]
        }
      }]
    }
  }]
}

Questions:

  • Should the nested hCard be present also as a top-level item in the JSON? - Tantek 02:02, 19 June 2012 (UTC)
    • My current (2012-243) leaning is no. - 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? - 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. - 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? - Tantek 02:02, 19 June 2012 (UTC)
      • If so, what convention does/do JSON follow for such synthetic local reference identifiers? - Tantek 02:02, 19 June 2012 (UTC)

Notes:

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:

Mitchell Baker (Mozilla Foundation)

with source:

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

Parsed JSON:

{
  "items": [{ 
    "type": ["h-card"],
    "properties": {
      "name": ["Mitchell Baker"],
      "url": ["http://blog.lizardwrangler.com/"],
      "org": ["Mozilla Foundation"]
    }
  }]
}

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

Mitchell Baker (Mozilla Foundation)

You can mark that up with a nested h-card:

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

Parsed JSON:

{
  "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/"]
        }
      }]
    }
  }]
}

Note: the nested h-card has implied 'name' and 'url' properties, just like any other root-class-name-only h-card on an <a href> 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'.

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

Parsed JSON:

{
  "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/"]
        }
      }]
    }
  }]
}


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:

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

Parsed JSON:

{
  "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/"]
      }  
    }]
  }]
}

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:

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

Parsed JSON:

{
  "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/"]
      }  
    }]
  }]
}

TO DO: Add h-event h-card example and JSON, per real world publishing examples like 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 simple examples at the top for a start, e.g.

Simple hCards work just by adding class="h-card" :

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

backward compatible

If you depend on current microformats implementations, while they're being updated to support microformats2, you can include both existing classic microformats and microformats2 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 <span>) to separate the root class name element from explicit property class name elements:

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


Tips:

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: When using both h-card and vcard which should be first and why?

validators

microformats2 validators:

new! Test your microformatted web page with:

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:

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.

offline

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!

Blogging tools

Converters

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
Javascript
PHP
Python
Ruby
Haskell

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
Elixir
Go
Java

Experiments

Experiments and other proof of concept microformat2 parsing support.

Outreach

Presentations

Presentations about microformats2:

Testimonials

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

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

When the microformats2 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.

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:

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:

<span class="vcard">
  <span class="fn">
    Chris Messina
  </span>
</span>

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:

<h1>Chris Messina</h1>

requires just 1 element.

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:

<h1 class="vcard">Chris Messina</h1>

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:

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.

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:

<h1 class="hcard">Chris Messina</h1>

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 for hCard, and rediscovered by 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?

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:

For example for hCard this would mean the following specific changes to keep relevant functionality:

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

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

Note:

  1. use of an explicit span with "fn" to markup his entire formatted name
  2. 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.

Thus microformats2 uses prefixes for property class names, e.g.:

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

parsing microformats currently requires

  1. a list of root class names of each microformat to be parsed
  2. 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
  3. 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:

In particular - derived from the real world examples of existing proven microformats (rather than any abstraction of what a schema should have)

This provides a simpler transition/education story for existing microformats authors/publishers:

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

Example: taking that simple heading hCard example forward:

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

As part of microformats2 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 microformats2 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 microformats2. 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:

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

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

with a hyperlink to Chris's URL:

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

COMPATIBILITY

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

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

a microformats2 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 DRY principle.

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

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


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:

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:

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 Wikipedia: HTTP header fields - non-standard headers (could use RFC reference instead) respectively, like:

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

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:

Background - this proposal is a composition of the following (at least somewhat) successful vendor extension syntaxes

USERS

Need more tools and interfaces that:

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 was last modified: Saturday, October 28th, 2017

Views