misconceptions: Difference between revisions
(drafted with misconceptions from David Orchard) |
mNo edit summary |
||
| Line 10: | Line 10: | ||
Microformats make use of the <code>profile</code> attribute, in the <code><head></code> element to reference one or more profiles (this is all per HTML4 spec) to an [[XMDP]] profile document ([http://gmpg.org/xmdp/description XMDP is derived] from the "hints" in HTML4 as to what a profile document "could" be), to define specific rel (e.g. [http://gmpg.org/xfn/11 XFN 1.1 profile] and class (e.g. [http://www.w3.org/2006/03/hcard hCard profile]) values. | Microformats make use of the <code>profile</code> attribute, in the <code><head></code> element to reference one or more profiles (this is all per HTML4 spec) to an [[XMDP]] profile document ([http://gmpg.org/xmdp/description XMDP is derived] from the "hints" in HTML4 as to what a profile document "could" be), to define specific rel (e.g. [http://gmpg.org/xfn/11 XFN 1.1 profile] and class (e.g. [http://www.w3.org/2006/03/hcard hCard profile]) values. | ||
Thus microformats <em>are</em> built upon a form of URI based extensibility. Tantek did this <em>by design</em> for [[XFN]], his first experiment into extending HTML, and before he even coined the word "microformat" (XMDP & XFN were developed in 2003, "microformats" were first proposed in 2004). | Thus microformats <em>are</em> built upon a form of URI based extensibility. Tantek did this <em>by design</em> for [[XFN]], his first experiment into formally extending HTML, and before he even coined the word "microformat" (XMDP & XFN were developed in 2003, "microformats" were first proposed in 2004). | ||
What we have found is that, just like HTML was often used in the wild without explicit DOCTYPE URIs (and tools e.g. browsers supported it), microformats are often used in the wild without explicit profile URLs (and tools e.g. browser plugins support it). | What we have found is that, just like HTML was often used in the wild without explicit DOCTYPE URIs (and tools e.g. browsers supported it), microformats are often used in the wild without explicit profile URLs (and tools e.g. browser plugins support it). | ||
Revision as of 19:34, 25 September 2007
misconceptions about microformats
Some misconceptions either appear often enough, or may have been held by people that are experts in the fields of markup, web standards etc., and thus it is useful to document and debunk them.
misconceptions
microformats use non-URI based extensibility
misconception: Microformats use non-URI based extensibility.
Microformats make use of the profile attribute, in the <head> element to reference one or more profiles (this is all per HTML4 spec) to an XMDP profile document (XMDP is derived from the "hints" in HTML4 as to what a profile document "could" be), to define specific rel (e.g. XFN 1.1 profile and class (e.g. hCard profile) values.
Thus microformats are built upon a form of URI based extensibility. Tantek did this by design for XFN, his first experiment into formally extending HTML, and before he even coined the word "microformat" (XMDP & XFN were developed in 2003, "microformats" were first proposed in 2004).
What we have found is that, just like HTML was often used in the wild without explicit DOCTYPE URIs (and tools e.g. browsers supported it), microformats are often used in the wild without explicit profile URLs (and tools e.g. browser plugins support it).
microformats use unscoped class names
misconception: Microformats definitions use unqualified/scoped class attribute strings as semantic tags.
This is incorrect on two counts.
First, as above, microformats make use of profile URLs to define class name semantics. Thus it is entirely possible (though both unlikely, and undesirable) for someone to redefine class names with their own definitions in their own profile URL.
Second, compound microformats (e.g. hCard, hCalendar, hReview) use a fairly uniquely chosen string for the "root element" (e.g. vcard, vcalendar, vevent, hreview) and then generic terms only inside that root element. Thus use of any generic terms are scoped (some might even say "namespaced") within the fairly uniquely chosen "root element" class name.