(Difference between revisions)

Jump to: navigation, search

Tantek (Talk | contribs)
(move origins brainstorming and background from the main microformats2 page to reduce confusion)
Next diff →

Revision as of 15:59, 3 April 2018

microformats2 was originally proposed and conceptually explored during a discussion session at FOO East 2010.

During that session, much of the below was brainstormed, written up, and iterated. We have kept this documentation of microformats2 origins for those who want to understand how microformats2 was designed and evolved in the early years.

For the formal microformats2 documentation see:


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.



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


Addressing Issues


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



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


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 would result in:


making the simple case even simpler:


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



How does this simple root-only case work?

flat sets of properties

What more can we simplify about microformats?


Proposal: simplify all microformats to flat sets of properties.

What this means:



<h1 class="hcard">
 <span class="fn">



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.


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


parsing microformats currently requires



naming conventions for generic parsing




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:


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.


This has numerous advantages:


<h1 class="h-card">
 <span class="p-fn">

with a hyperlink to Chris's URL:

<h1 class="h-card">



Here is a simple example:

<h1 class="h-card vcard">


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

<h1 class="h-card vcard">




Proprietary or experimental CSS3 property implementations have been very successful.





The benefits have been two-fold:







Need more tools and interfaces that:



See Also

microformats2-origins was last modified: Wednesday, December 31st, 1969