faq: Difference between revisions
AndyMabbett (talk | contribs) (Who uses microformats?) |
GRegorLove (talk | contribs) (s/<source>/<syntaxhighlight>/) |
||
(50 intermediate revisions by 12 users not shown) | |||
Line 1: | Line 1: | ||
{{DISPLAYTITLE: Microformats FAQ }} | |||
This page document frequently asked questions about microformats. For frequently asked questions from the [[press]], see [[press-faq]]. | This page document frequently asked questions about microformats. For frequently asked questions from the [[press]], see [[press-faq]]. | ||
Line 5: | Line 5: | ||
If you're looking for a microformat for marking up FAQs, see [[question-answer]]. | If you're looking for a microformat for marking up FAQs, see [[question-answer]]. | ||
== How To == | |||
=== What microformats should I use to markup my blog === | |||
''What microformats should I use to markup my blog?'' | |||
A: Use a classic [[microformat]] on the body of each page. For your index page, use an [[h-card]], since it's about you, and an [[h-feed]] for any recent updates you post there. For your individual permalink pages, use [[h-entry]]. | |||
For all of the data on your pages, use [[microformats2]]. | |||
From: http://indiewebcamp.com/faq#How_should_I_markup_my_blog | |||
=== When should I use microformats2 or microformats1 === | |||
<span id="When_should_I_use_microformats2_over_microformats1">''On sites that don't currently have microformats, should microformats2 be utilized in or classic microformats? E.g. for a rather large site.''</span> | |||
A: [[microformats2]] use less markup (are even simpler) than classic (v1) microformats, so in general microformats2 is preferred for adding to sites. | |||
You may also want to add one v1 microformat for each page that describes the primary subject of the page. | |||
You can easily use both: | |||
* if a page is about a '''person''' or '''company''', add an '''[[hCard]]''' (and '''[[h-card]]''') to markup the info about the person/company. | |||
* Or if the page is for an '''event''', add an '''[[hCalendar]]''' <code>vevent</code> (and '''[[h-event]]''') about the event info. | |||
* Similarly with a page that is a '''[[hReview|review]], [[hProduct|product]], [[hAtom|blog post]], or [[hRecipe|recipe]]'''. | |||
See the [[Main_Page#Specifications|list of specs and drafts]] for more recommended top level microformats. | |||
For all other references to things on the page, links to or mentions of [[h-card|people]]/[[h-event|events]]/[[h-cite|citations]]/products, etc. use [[microformats2]]. | |||
=== What microformats should I use for backward compatibility === | |||
For backwards compatibility, e.g. with some [[search-engines]], it's sufficient to include one v1 microformat for each page that best describes what that page is about. See above '''When should I use microformats2 or microformats1''' for more details. | |||
== Common Details == | |||
=== Can you mix properties and the root class name === | |||
''<span id="nesting-properties">Can you put properties on the same element as the root class for a microformat? E.g. span class="h-card p-org"?</span>'' | |||
* No, property elements must be inside the root class name element. | |||
Mixing will result in more confusion for parsers which may be parsing nested microformats. In this case in the question, you need two elements: | |||
* WRONG: <code><span class="h-card p-org"></code> | |||
* RIGHT: <code><span class="h-card"><span class="p-org"></code> | |||
The only time you can put a root class name (like "h-card") and a property class name on the same element, is when the root class name is providing an entire object as the embedded value of that property which then belongs to some other object higher up the tree. | |||
E.g. using an h-card for the location of an h-event | |||
<syntaxhighlight lang="html"> | |||
<span class="h-event"> | |||
<span class="p-name">HTML5 Developer Conference</span>, | |||
<time class="dt-start">2013-04-01</time>...<time class="dt-end">2013-04-03</time>, at | |||
<span class="p-location h-card"> | |||
<span class="p-name p-org">The Palace Hotel</span>, | |||
<span class="p-locality">San Francisco</span> | |||
</span> | |||
</span> | |||
</syntaxhighlight> | |||
Note the <code><span class="p-location h-card"></code> which specifies that: | |||
* the <code>p-location</code> is a property of the surrounding <code>[[h-event]]</code> | |||
* the <em>value</em> of that h-event’s <code>p-location</code> is an entire embedded <code>h-card</code> | |||
Another example, inside an [[h-entry]], specifying the author as an h-card: <code><span class="p-author h-card"></code> | |||
Derived from: [[hcard-faq#Can_you_mix_properties_and_the_root_class_name]] | |||
== Wiki specific questions == | == Wiki specific questions == | ||
Line 11: | Line 71: | ||
A: First, read this: http://en.wikipedia.org/wiki/Wikipedia:Username . Second, real names are preferred to pseudonyms/handles etc. Real names encourage better transparency and accountability. Third, the most common problem creating a user name is forgetting to capitalize the first letter of the user name. Try using a WikiCase version of your full name as username, e.g. RyanKing. | A: First, read this: http://en.wikipedia.org/wiki/Wikipedia:Username . Second, real names are preferred to pseudonyms/handles etc. Real names encourage better transparency and accountability. Third, the most common problem creating a user name is forgetting to capitalize the first letter of the user name. Try using a WikiCase version of your full name as username, e.g. RyanKing. | ||
===Q: ''How do I pass a reCAPTCHA V1'' === | |||
A: Do you feel that there's a part of you that's missing? | |||
== Email list == | == Email list == | ||
=== Why do I get You are not allowed to post to this mailing list === | |||
''' ''Q: I've tried sending email to the mailing list. Why do I get a bounce message stating: "You are not allowed to post to this mailing list. ..." ? '' ''' | |||
A: You must first subscribe to the microformats mailing list that you are trying to post to. | |||
===Q: ''I've joined the discussion mailing list but am not seeing my replies anywhere. Why?''=== | ===Q: ''I've joined the discussion mailing list but am not seeing my replies anywhere. Why?''=== | ||
Line 26: | Line 95: | ||
== Basic Microformat Questions == | == Basic Microformat Questions == | ||
===Q: ''Who uses microformats?'' === | ===Q: ''Who uses microformats?'' === | ||
A: See a list of | A: See a list of [[examples-in-wild|sites using microformats]] and [[implementations|numerous tools]] that support microformats. | ||
===Q: ''When should I use a microformat? What are they for?''=== | ===Q: ''When should I use a microformat? What are they for?''=== | ||
Line 40: | Line 105: | ||
Microformats are designed to make the data you already publish for humans available to machines. It allows applications as simple as cut-and-paste or as complex as a search engine to use your data effectively. | Microformats are designed to make the data you already publish for humans available to machines. It allows applications as simple as cut-and-paste or as complex as a search engine to use your data effectively. | ||
===Q: ''Should I use microformats or microdata?'''=== | |||
A: '''microformats''' require less markup, are easier to learn for common cases like [[hcard-authoring|people]]/[[hcalendar-authoring|events]]/[[get-started|etc.]], and are supported by more [[tools]] including [[search-engines]]. | |||
If you're looking for minimal markup addition, just use microformats. | |||
If you want to use both, you may do so because they don't interfere. | |||
===Q: ''Are microformats dependent upon (X)HTML?''=== | ===Q: ''Are microformats dependent upon (X)HTML?''=== | ||
A: Microformats | A: No. Microformats work with the class attribute in HTML5, SVG etc., and can also be embedded in any XML (like Atom or RSS), as embedded XHTML. | ||
Line 53: | Line 126: | ||
===Q: ''I'd like to make a donation to the microformat cause. How can I do this?''=== | ===Q: ''I'd like to make a donation to the microformat cause. How can I do this?''=== | ||
A: Thank you for your willingness to support microformats. | A: Thank you for your willingness to support microformats. microformats.org is an all volunteer unpaid organization, and sponsor contributions really help the community. There are several ways to support microformats with donations: | ||
<div class="discussion"> | |||
* Donate to a microformats [[open source]] effort, e.g. | |||
** [https://addons.mozilla.org/en-US/firefox/addon/4106/developers DONATE to Operator] - an essential [[Firefox]] extension | |||
* Sponsor a microformats [[weekly meetup]]. | |||
** Watch the [[events]] page for a weekly meetup near you, participate and sponsor dinner and or drinks! | |||
* Sponsor a microformatsDevCamp like the [[events/2009-07-25-dev-camp|recent devCamp in SF]]. | |||
** Watch the [[events]] page for upcoming devCamps, vEvents, and other similar opportunities to sponsor. | |||
</div> | |||
===Q: ''Which microformats have been implemented?'' === | ===Q: ''Which microformats have been implemented?'' === | ||
Line 74: | Line 154: | ||
A. Yes...tons... [[implementations]]. | A. Yes...tons... [[implementations]]. | ||
===Q. ''What is the 'h' for, in front of Calendar and Card?'' === | |||
''What's the meaning of the 'h' before the [[hCalendar]] and [[hCard]] microformats?'' | |||
A. hCard and hCalendar are the <strong>H</strong>TML versions of vCard and iCalendar, hence the replacement of the leading lowercase 'v' or 'i' with 'h'. Origins: <cite>[http://tantek.com/log/2004/09.html#d30t1725 Tantek's Thoughts: "Semantic XHTML" slides posted]</cite>. | |||
See the [[hcard-faq|hCard FAQ]] and the [[hcalendar-faq|hCalendar faq]] for more specific questions on those microformats. | |||
===Q. ''Is there a way to indicate that a given web page contains markup that conforms to one or more microformats?'' === | ===Q. ''Is there a way to indicate that a given web page contains markup that conforms to one or more microformats?'' === | ||
A. The HTML HEAD element's '<code>profile</code>' attribute alerts applications to the potential presence of microformats. The [http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#h-7.4.4.3 W3C HTML Specification] describes more about the profile attribute, and the [http://gmpg.org/xmdp/description XMDP description] documents how it is used. | A. The HTML HEAD element's '<code>profile</code>' attribute alerts applications to the potential presence of microformats. The [http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#h-7.4.4.3 W3C HTML Specification] describes more about the profile attribute, and the [http://gmpg.org/xmdp/description XMDP description] documents how it is used. | ||
===Q: ''What do these specific jargon terms mean?''=== | |||
A: See our [[glossary]]. | |||
===Q. ''What about using new URI schemes instead of class names, e.g. for geo information?''=== | ===Q. ''What about using new URI schemes instead of class names, e.g. for geo information?''=== | ||
Line 98: | Line 189: | ||
===Q: ''Who controls microformats?''=== | ===Q: ''Who controls microformats?''=== | ||
A: An open community. Microformats are open standards licensed under Creative Commons Attribution. Much of the work here was begun on [http://developers.technorati.com/wiki Technorati's Developer Wiki], | A: An open community. Microformats are open standards originally licensed under Creative Commons Attribution, and placed into the [[Microformats_Wiki:Copyrights|public domain since 2007-12-29]]. Much of the work here was begun on [http://developers.technorati.com/wiki Technorati's Developer Wiki], and Technorati contributed the work done there to the microformats community when microformats.org was established. The microformats.org domain is registered to Rohit Khare (see [http://whois.uberdose.com/microformats.org Whois microformats.org]), CommerceNet is graciously hosting the servers, but claims no control over microformat standards. Anyone may follow the established [[process]] and contribute towards the development of microformat standards. | ||
Any required [[governance]] | Any required [[governance]] (and very little ''has been'' required) of the microformats [[IRC]] channel, wiki, and [[mailing lists]] is discussed by a group of volunteer [[administrators]]. | ||
===Q: ''Who is the registrar for microformats?''=== | ===Q: ''Who is the registrar for microformats?''=== | ||
Line 114: | Line 205: | ||
===Q: ''How do I validate my microformated content?''=== | ===Q: ''How do I validate my microformated content?''=== | ||
A: | A: See [[validators]] for a list of microformats validators. | ||
===Q: '' | ===Q: ''Why do microformats use English terms for property names?''=== | ||
A: Similar to how HTML uses English words like "class", "span" or "head", microformats re-uses English words for property names. As microformats property names are based on existing standards (see [[process]], and [[naming-principles]]), this is another problem that is far outside the scope of microformats. As Ryan King put it, this is a pre-existing (unsolved) "problem" with English-based HTML, the English-based CSS, the English-based HTTP and so on. Note that this is NOT about the internationalization of the content and data itself - which is of course an excellent goal, advocated and promoted by microformats and the standards they are based on (e.g. W3C, IETF). This is purely about the names of the properties (and enumerated values) in the formats. See also [[internationalization]] and the [[en-us-faq#why_not_use_other_spellings_and_languages_for_properties|en-US FAQ: why not use other spellings and languages for properties]] regarding the question of alternate (non-English) names in other (natural) languages, and mappings. | |||
===Q: ''How come microformats stay as drafts even though they seem usable?'' === | |||
A: This was discussed at the [http://2007.sxsw.com/interactive/programming/panels/?action=show&id=IAP060234 The Growth and Evolution of Microformats] panel at [http://en.wikipedia.org/wiki/South_by_Southwest SXSW] 2007. The basic answer is it was important to at least have a basic software implementation -- even an experimental one -- before moving a format from Draft to Specification. It can sometimes be hard to recognize subtle inconsistencies within a format by eye; however, in the process of implementing a format-reader in code, inconsistencies (if any) can become much more noticeable (due to [[dry | DRY / Don't Repeat Yourself]], among other programming best practices). Then, once such tools have been created (in effect, confirming both the programmability of the format, and interoperability across tools), it can be considered for transition to a Specification. Using interoperable implementations as a measure of format quality is a long-standing practice of IETF and W3C. | |||
A: | |||
== Creating and Suggesting New Microformats == | == Creating and Suggesting New Microformats == | ||
Line 130: | Line 219: | ||
A. The first thing to do before attempting a new microformat open standard is to make as much use of [[POSH]] and existing [[microformats]] open standards as possible in whatever site you are looking to mark up with your new microformat, as a way of learning what is left to be done. That is, at a minimum first: | A. The first thing to do before attempting a new microformat open standard is to make as much use of [[POSH]] and existing [[microformats]] open standards as possible in whatever site you are looking to mark up with your new microformat, as a way of learning what is left to be done. That is, at a minimum first: | ||
* Mark up all people and organizations as [[hcard|hCards]] | * Mark up all people and organizations as [[hcard|hCards]] and add those pages to [[hcard-examples-in-wild]] | ||
* Mark up all events and time based things as [[hcalendar|hCalendar]] events | * Mark up all events and time based things as [[hcalendar|hCalendar]] events and add those pages to [[hcalendar-examples-in-wild]] | ||
* Mark up all reviews as [[hreview|hReviews]] | * Mark up all reviews as [[hreview|hReviews]] and add those pages to [[hreview-examples-in-wild]] | ||
* etc. | * etc. | ||
Then join the microformats [http://microformats.org/discuss discuss list], and ask folks what they think of your use of the microformats and if it can be improved. | Then join the microformats [http://microformats.org/discuss IRC channel and discuss list], and ask folks what they think of your use of the microformats and if it can be improved. | ||
From that experience you will then be able to figure out what is left to be specified. Otherwise it is too hard to approach the "whole problem". | From that experience you will then be able to figure out what is left to be specified. Otherwise it is too hard to approach the "whole problem". | ||
Line 163: | Line 252: | ||
== Class interactions == | == Class interactions == | ||
===Q. ''Are there issues with page styling when specific class values are used?''=== | ===Q. ''Are there issues with page styling when specific class values are used?''=== | ||
A. There might be. However, any such issues can be easily (trivially) worked around by using contextual selectors. | A. There might be. However, any such issues can be easily (trivially) worked around by using contextual selectors. | ||
===Q. ''How does the use of class values for semantics interact with the use of class values for attaching CSS styles?''=== | ===Q. ''How does the use of class values for semantics interact with the use of class values for attaching CSS styles?''=== | ||
A. The class attribute takes a space separated set of class names [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 HTML4 reference]. Thus both author and microformat defined class names may be used in the same class attribute. | A. The class attribute takes a space separated set of class names [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 HTML4 reference]. Thus both author and microformat defined class names may be used in the same class attribute. Experience has shown that the best practice is for authors to use their own class names for styling, and only use microformats class names for expressing microformats semantics. If the author is already using using specific class names, they can continue to do so. If the author is already using a class name that happens to also be a microformats class name, then the author may want to consider using contextual CSS class selectors to make sure to reduce any unintentional styling effects, or ideally use their own site-specific class names that are not microformats class names. | ||
See also: | See also: | ||
Line 178: | Line 265: | ||
* [http://www.meyerweb.com/eric/thoughts/2004/07/18/competent-classing Competant Classing], by Eric Meyer for discussion of choosing class names in (X)HTML | * [http://www.meyerweb.com/eric/thoughts/2004/07/18/competent-classing Competant Classing], by Eric Meyer for discussion of choosing class names in (X)HTML | ||
* [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling] - Ryan King dispells common misconceptions about the ''HTML'' class attribute. | * [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling] - Ryan King dispells common misconceptions about the ''HTML'' class attribute. | ||
* [https://tantek.com/2012/353/b1/why-html-classes-css-class-selectors Why you should say HTML classes, CSS class selectors, or CSS pseudo-classes, but not CSS classes] | |||
===Q. ''Are class names case sensitive?'' === | |||
A: Yes, HTML class names (i.e. as used in microformats) are case-sensitive. | |||
By [[naming-principles#Some_Details|convention]], microformats use all lowercase classnames similar to CSS's approach. This way authors never have to guess about the capitalization of microformats properties - they're always all lowercase. | |||
== <code><div></code> and <code><span></code> semantics == | == <code><div></code> and <code><span></code> semantics == | ||
=== Q. ''Can microformats use other elements besides divs?'' === | |||
A. Yes. Markup with microformats should use the most appropriate semantic HTML. For example if the name of an organization hCard is a top level heading, then: <p><code><div class=vcard><br/><strong><h1 class="fn org">ACME Co.</h1></strong><br/></div></code></p> is more appropriate than <p><code><div class=vcard><br/><strong><div class="fn org">ACME Co.</div></strong><br/></div></code></p> | |||
=== Q. ''Is it semantically meaningless to use divs?'' === | === Q. ''Is it semantically meaningless to use divs?'' === | ||
A. Yes, both <code><div></code> and <code><span></code> have nearly no semantics. <code><div></code> can be used to represent a "division" of the page content. Similarly <code><span></code> can be used to reperesent that that "span" of text has some meaning, but the specifics of what that meaning is undefined by the <code><span></code>. | A. Yes, both <code><div></code> and <code><span></code> have nearly no semantics. <code><div></code> can be used to represent a "division" of the page content. Similarly <code><span></code> can be used to reperesent that that "span" of text has some meaning, but the specifics of what that meaning is undefined by the <code><span></code>. | ||
=== Q. ''Does the use of <code><div></code> and <code><span></code> elements add any semantics to web pages?''=== | === Q. ''Does the use of <code><div></code> and <code><span></code> elements add any semantics to web pages?''=== | ||
Line 193: | Line 288: | ||
=== Q. ''Why do the examples on the wiki use <code class="element"><span></code> and <code class="element"><div></code> for nearly everything?''=== | === Q. ''Why do the examples on the wiki use <code class="element"><span></code> and <code class="element"><div></code> for nearly everything?''=== | ||
A. <code class="element"><span></code> and <code class="element"><div></code> are generic elements in HTML. When you use microformats, you should pick the most specific semantic element available for the semantics you are trying to express. You might, for example, apply <code>class="vevent"</code> to a <code><nowiki><tr></nowiki></code>, or <code>class="vcard"</code> to a <code><nowiki><p></nowiki></code>. | A. <code class="element"><span></code> and <code class="element"><div></code> are generic elements in HTML. When you use microformats, you should pick the most specific semantic element available for the semantics you are trying to express. You might, for example, apply <code>class="vevent"</code> to a <code><nowiki><tr></nowiki></code>, or <code>class="vcard"</code> to a <code><nowiki><p></nowiki></code>. Here is an example using more [[semantic HTML]] with a definition list to mark-up an hCard: | ||
<syntaxhighlight lang="html"> | |||
<dl class="vcard"> | |||
<dt class="category">Restaurant</dt> | |||
<dd class="fn org"> | |||
<a class="url" href="http://www.yelp.com/biz/crepes-n-more-fairfield">Crepes N More</a> | |||
</dd> | |||
<dt>Address</dt> | |||
<dd class="adr"> | |||
<span class="street-address">620 Jackson st.</span>, | |||
<span class="locality">Fairfield</span>, | |||
<abbr class="region" title="California">CA</abbr>, | |||
<span class="postal-code">94533</span>, | |||
<abbr class="country-name" title="United States of America">USA</abbr> | |||
</dd> | |||
<dt>Phone</dt> | |||
<dd class="tel">+1.707.428.2210</dd> | |||
</dl> | |||
</syntaxhighlight> | |||
== Class semantics == | == Class semantics == | ||
Line 208: | Line 321: | ||
See W3C HTML 4.01 Specification: [http://www.w3.org/TR/html401/struct/global.html#adef-class 7.5.2 Element identifiers: the id and class attributes] | See W3C HTML 4.01 Specification: [http://www.w3.org/TR/html401/struct/global.html#adef-class 7.5.2 Element identifiers: the id and class attributes] | ||
===Q. ''Does the order of class names matter?'' === | |||
A. No. The HTML class attribute is an unordered space separated set of class names. The order of classes in an class attribute do affect their meaning or use. E.g. these two divs' class names are equivalent: | |||
<syntaxhighlight lang="html"> | |||
<div class="a b">...</div> | |||
<div class="b a">...</div> | |||
</syntaxhighlight> | |||
===Q. ''Do (X)HTML class names have semantics?''=== | ===Q. ''Do (X)HTML class names have semantics?''=== | ||
Line 229: | Line 349: | ||
* [http://tantek.com/log/2004/07.html#d20t2359 More about the class attribute, Tantek Çelik] | * [http://tantek.com/log/2004/07.html#d20t2359 More about the class attribute, Tantek Çelik] | ||
== Microformats and | ===Q. ''Should human readable data go into class names?'' === | ||
A. No. We should not put human readable data into the <code>class</code> attribute, because it puts human-readable data in a spot that's no longer visible. See the [[principles]]. | |||
Q. Follow-up. How is that different from putting human readable data into the <code>title</code> attribute? | |||
A. The title attribute is displayed in tool-tips in the overwhelming majority of browsers in use and thus is quite semi-visible, and thus human verifiable by casual users. The class attribute is not displayed in a tool-tip or any other user interface (not withstanding developer interfaces like view source). | |||
===<abbr title='Question'>Q.</abbr> Why don't microformats use the HTML5 <code>data-</code> attributes to embed data?=== | |||
<abbr title='Answer'>A</abbr>: | |||
# The HTML5 <code>data-</code> attribute specification expressly forbids the microformats use-case:<blockquote cite='https://www.w3.org/TR/html5/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes'>Custom data attributes are intended to store custom data private to the page or application, for which there are no more appropriate attributes or elements. These attributes are not intended for use by software that is independent of the site that uses the attributes. [...] It would be inappropriate, however, for the user to use generic software not associated with that music site to search for tracks of a certain length by looking at this data. This is because these attributes are intended for use by the site's own scripts, and are not a generic extension mechanism for publicly-usable metadata.</blockquote>— <cite>[http://www.w3.org/TR/html5/semantics.html#embedding HTML5 · Embedding custom-non-visible data]</cite> | |||
# Microformats are designed around the principle that non-visible data is undesirable, harder to maintain, more prone to inaccuracy (as no-one will see the data on the page to notice errors). The <code>data-</code> attribute is explicitly designed for non-visible data. | |||
== Hidden Content == | |||
Related to <span id="Microformats_and_Spam">microformats and spam</span>. | |||
=== Q. ''Will crawlers get data from hidden content?'' === | |||
Q: ''If I markup some content inside of a block with display:none, will crawlers get data from it anyway?'' | |||
A. Crawlers and search engines frown upon hidden (e.g. display:none) content in general (e.g. see next FAQ about Google, hidden content, and spam). If some content doesn't fit into your visible design, then it's not worth microformatting it. Visible content is the only content you can reasonably trust/expect to be correct / up to date. Invisible content tends to rot, get out of date, fail to be checked etc., so don't waste any time publishing invisible content - it's going to die anyway. | |||
=== Q. ''Given that Google now looks at hidden content as potential spam, will invisible microformats be considered spam?''=== | === Q. ''Given that Google now looks at hidden content as potential spam, will invisible microformats be considered spam?''=== | ||
;shortlink | |||
:http://j.mp/gnohide | |||
A. It is advisable not to hide information in your site, regardless of whether it is microformatted or not. Microformats provide a mechanism for marking up ''visible'' content. Any mechanism for embedding ''invisible'' or hidden content risks being considered spam due to the fact that invisible (meta)data inevitably ends up being abused. Avoid invisible (meta)data. Publish visible data. | A. It is advisable not to hide information in your site, regardless of whether it is microformatted or not. Microformats provide a mechanism for marking up ''visible'' content. Any mechanism for embedding ''invisible'' or hidden content risks being considered spam due to the fact that invisible (meta)data inevitably ends up being abused. Avoid invisible (meta)data. Publish visible data. | ||
Google in particular have said: <blockquote><p>In general, Google won't display content that is not visible to the user. In other words, don't show content to users in one way, and use hidden text to mark up information separately for search engines and web applications. You should mark up the text that actually appears to your users when they visit your web pages.[http://support.google.com/webmasters/bin/answer.py?hl=en&answer=146897]</p></blockquote> | |||
The only 'hidden' data they support according to that article is specific use of the [[value class pattern]] <code>value-title</code> empty span with machine-readable information adjacent to a human-readable equivalent. | |||
== Design Patterns with Abbr & Title == | == Design Patterns with Abbr & Title == | ||
Line 248: | Line 396: | ||
In addition, microformats encourage the content to be visible and thus prefer the text of an element rather than using the 'title' attribute or any other less visible alternative. The exception is made for datetimes and abbr due to the fact that microformats are for humans first, machines second. Thus the content of the abbr element is used to provide human visible content and the machine equivalent is placed in the less visible (but still easily verifiable) 'title' attribute. | In addition, microformats encourage the content to be visible and thus prefer the text of an element rather than using the 'title' attribute or any other less visible alternative. The exception is made for datetimes and abbr due to the fact that microformats are for humans first, machines second. Thus the content of the abbr element is used to provide human visible content and the machine equivalent is placed in the less visible (but still easily verifiable) 'title' attribute. | ||
=== Q. ''Can I include information within the HTML element itself?'' === | |||
Longer: ''Can I include information within the HTML element itself? e.g. <span class="org" title="Foobar, Inc."></span>?'' [http://twitter.com/szarka/status/109723996223840256] | |||
A. You can't do that with the <code>span</code> element because there is no specific semantic connection between the element contents and its <code>title</code> other than being [http://www.w3.org/TR/html401/struct/global.html#h-7.4.3 "advisory information about the element"]. In addition, it's bad form (and penalized by Google) to include invisible data on web pages. | |||
Instead, you can use the <code>abbr</code> element and its <code>title</code> attribute to provide an expanded form of the information in cases where substituting the expanded form when reading the text in context reads correctly, e.g. inside an [[hCard]]: | |||
<syntaxhighlight lang="html"> | |||
<abbr class="region" title="Connecticut">CT</abbr> | |||
</syntaxhighlight> | |||
[http://twitter.com/microformats/status/112556548877844481] | |||
== Nesting of elements == | == Nesting of elements == | ||
Line 253: | Line 414: | ||
A. No. See [[hcard-faq#nesting-properties]]. | A. No. See [[hcard-faq#nesting-properties]]. | ||
== Usage/Verbiage == | |||
=== Q. ''Is '''Microformat''' a proper noun? Should it be capitalized?''=== | |||
A. Since the term "microformat" was established, it has been written in lowercase. This is a nod to its roots in the term "lowercase semantic web", in contrast to the uppercase "Semantic Web" which has long been tied to RDF and other technologies often viewed as impractical for the open web. In a few cases in the wild(citation needed), the term has been capitalized as "Microformat", perhaps due to proper noun capitalization conventions. | |||
=== Q. ''Can you use microformat as an adjective or verb, as in "microformatted content" or "can you please microformat that page with an hCard?"'' === | |||
A. Because the word ''microformat'' is derived from the word '''format''', it makes logical sense that one can use the term as an adjective or verb, just as one would use the word '''format'''. | |||
== Other == | |||
=== Q. '''How do I find an answer to a question not mentioned here?'' === | |||
A. Join [[irc]] and ask! | |||
== See Also == | == See Also == | ||
* [[misconceptions]] | * [[misconceptions]] |
Latest revision as of 23:00, 20 June 2024
This page document frequently asked questions about microformats. For frequently asked questions from the press, see press-faq.
If you're looking for a microformat for marking up FAQs, see question-answer.
How To
What microformats should I use to markup my blog
What microformats should I use to markup my blog?
A: Use a classic microformat on the body of each page. For your index page, use an h-card, since it's about you, and an h-feed for any recent updates you post there. For your individual permalink pages, use h-entry.
For all of the data on your pages, use microformats2.
From: http://indiewebcamp.com/faq#How_should_I_markup_my_blog
When should I use microformats2 or microformats1
On sites that don't currently have microformats, should microformats2 be utilized in or classic microformats? E.g. for a rather large site.
A: microformats2 use less markup (are even simpler) than classic (v1) microformats, so in general microformats2 is preferred for adding to sites.
You may also want to add one v1 microformat for each page that describes the primary subject of the page.
You can easily use both:
- if a page is about a person or company, add an hCard (and h-card) to markup the info about the person/company.
- Or if the page is for an event, add an hCalendar
vevent
(and h-event) about the event info. - Similarly with a page that is a review, product, blog post, or recipe.
See the list of specs and drafts for more recommended top level microformats.
For all other references to things on the page, links to or mentions of people/events/citations/products, etc. use microformats2.
What microformats should I use for backward compatibility
For backwards compatibility, e.g. with some search-engines, it's sufficient to include one v1 microformat for each page that best describes what that page is about. See above When should I use microformats2 or microformats1 for more details.
Common Details
Can you mix properties and the root class name
Can you put properties on the same element as the root class for a microformat? E.g. span class="h-card p-org"?
- No, property elements must be inside the root class name element.
Mixing will result in more confusion for parsers which may be parsing nested microformats. In this case in the question, you need two elements:
- WRONG:
<span class="h-card p-org">
- RIGHT:
<span class="h-card"><span class="p-org">
The only time you can put a root class name (like "h-card") and a property class name on the same element, is when the root class name is providing an entire object as the embedded value of that property which then belongs to some other object higher up the tree.
E.g. using an h-card for the location of an h-event
<span class="h-event">
<span class="p-name">HTML5 Developer Conference</span>,
<time class="dt-start">2013-04-01</time>...<time class="dt-end">2013-04-03</time>, at
<span class="p-location h-card">
<span class="p-name p-org">The Palace Hotel</span>,
<span class="p-locality">San Francisco</span>
</span>
</span>
Note the <span class="p-location h-card">
which specifies that:
- the
p-location
is a property of the surroundingh-event
- the value of that h-event’s
p-location
is an entire embeddedh-card
Another example, inside an h-entry, specifying the author as an h-card: <span class="p-author h-card">
Derived from: hcard-faq#Can_you_mix_properties_and_the_root_class_name
Wiki specific questions
Q: How do I create a username? Why won't it let me use my preferred username?
A: First, read this: http://en.wikipedia.org/wiki/Wikipedia:Username . Second, real names are preferred to pseudonyms/handles etc. Real names encourage better transparency and accountability. Third, the most common problem creating a user name is forgetting to capitalize the first letter of the user name. Try using a WikiCase version of your full name as username, e.g. RyanKing.
Q: How do I pass a reCAPTCHA V1
A: Do you feel that there's a part of you that's missing?
Email list
Why do I get You are not allowed to post to this mailing list
Q: I've tried sending email to the mailing list. Why do I get a bounce message stating: "You are not allowed to post to this mailing list. ..." ?
A: You must first subscribe to the microformats mailing list that you are trying to post to.
Q: I've joined the discussion mailing list but am not seeing my replies anywhere. Why?
A: There is no moderation on microformats-discuss, but it only accepts posts from subscribers. You MUST post to microformats-discuss using the email address you used to subscribe.
Q: What does "The message's content type was not explicitly allowed" mean?
A: Please go read mailinglists-policies. In particular note:
No HTML or RTF e-mail period, end of story, full stop. Your mail client should let you configure it so you can send plain text messages. Make use of this ability or else there are no guarantees that anyone will be able to read your email.
The mailing lists are set up to automatically reject email that is sent as text/html. Thus please configure your email client to send plain text (text/plain) email.
Basic Microformat Questions
Q: Who uses microformats?
A: See a list of sites using microformats and numerous tools that support microformats.
Q: When should I use a microformat? What are they for?
A: You are writing some HTML that contains useful human-readable information (such as a piece of contact information). You say to yourself: I would like to mark this up with some classes now for styling. You look up the relevant microformat, and you pull in the standard names. You don't have to make your own up, and now your page is machine-readable too. Bonus!
Microformats are designed to make the data you already publish for humans available to machines. It allows applications as simple as cut-and-paste or as complex as a search engine to use your data effectively.
Q: Should I use microformats or microdata?'
A: microformats require less markup, are easier to learn for common cases like people/events/etc., and are supported by more tools including search-engines.
If you're looking for minimal markup addition, just use microformats.
If you want to use both, you may do so because they don't interfere.
Q: Are microformats dependent upon (X)HTML?
A: No. Microformats work with the class attribute in HTML5, SVG etc., and can also be embedded in any XML (like Atom or RSS), as embedded XHTML.
Q: Microformats sound great. How can I help?
A: Take a look at get-started for how to implement microformats yourself, and the to-do list for things to help out with. See http://microformats.org/discuss to see some ways to join the conversations about microformats.
Q: I'd like to make a donation to the microformat cause. How can I do this?
A: Thank you for your willingness to support microformats. microformats.org is an all volunteer unpaid organization, and sponsor contributions really help the community. There are several ways to support microformats with donations:
- Donate to a microformats open source effort, e.g.
- DONATE to Operator - an essential Firefox extension
- Sponsor a microformats weekly meetup.
- Watch the events page for a weekly meetup near you, participate and sponsor dinner and or drinks!
- Sponsor a microformatsDevCamp like the recent devCamp in SF.
- Watch the events page for upcoming devCamps, vEvents, and other similar opportunities to sponsor.
Q: Which microformats have been implemented?
A: See the implementations page.
Q: Which microformats should I implement?
A: Chances are you that your website already has data very similar to several microformats. For example, you probably have people and/or their contact information somewhere. That information could be marked up with hCard, see the hCard authoring page for step by step instructions. If you are publishing press releases, try using hAtom.
Q: Do you have any link badges I can add to my website/blog?
A: There are some buttons but we can certainly use more! Please contribute what you come up with!
Q. Are there any tools that support microformats?
A. Yes...tons... implementations.
Q. What is the 'h' for, in front of Calendar and Card?
What's the meaning of the 'h' before the hCalendar and hCard microformats?
A. hCard and hCalendar are the HTML versions of vCard and iCalendar, hence the replacement of the leading lowercase 'v' or 'i' with 'h'. Origins: Tantek's Thoughts: "Semantic XHTML" slides posted.
See the hCard FAQ and the hCalendar faq for more specific questions on those microformats.
Q. Is there a way to indicate that a given web page contains markup that conforms to one or more microformats?
A. The HTML HEAD element's 'profile
' attribute alerts applications to the potential presence of microformats. The W3C HTML Specification describes more about the profile attribute, and the XMDP description documents how it is used.
Q: What do these specific jargon terms mean?
A: See our glossary.
Q. What about using new URI schemes instead of class names, e.g. for geo information?
A. In general, it is more work, and less content-publisher friendly, to ask publishers to use URI schemes instead of class names.
Authors aren't publishing links to geo information.
They're publishing *visible text* of geo information.
So the easiest thing to do, for the author, is to leave it as visible text.
Thus, it makes the most sense to do the simple thing of just wrapping that visible text with a little bit of markup, rather than asking the author to move (or copy) it into an attribute, which may or may not require a reformatting of the data as well.
It would make sense from a usability persepective to hyperlink geo information to a maps page or something, so that clicking it actually does something. If you forced them to use a hypothetical "geo:" protocol instead, then that would interfere, since you can only hyperlink something to one destination.
Q: Who controls microformats?
A: An open community. Microformats are open standards originally licensed under Creative Commons Attribution, and placed into the public domain since 2007-12-29. Much of the work here was begun on Technorati's Developer Wiki, and Technorati contributed the work done there to the microformats community when microformats.org was established. The microformats.org domain is registered to Rohit Khare (see Whois microformats.org), CommerceNet is graciously hosting the servers, but claims no control over microformat standards. Anyone may follow the established process and contribute towards the development of microformat standards.
Any required governance (and very little has been required) of the microformats IRC channel, wiki, and mailing lists is discussed by a group of volunteer administrators.
Q: Who is the registrar for microformats?
A: There is no central registry. Microformats are registered in a distributed manner using profiles. For more information on profiles see http://microformats.org/wiki/profile-uris and http://gmpg.org/xmdp/
Conflicts and interoperability are managed through social processes rather than a formal registry. Current microformat profiles can be found at http://gmpg.org, http://w3.org, and http://microformats.org.
Q: So multiple microformats with the same name can be valid?
A: Yes. The community at microformats.org can hopefully play a role in determining which is preferred by bringing interested folks together in one place and helping them resolve that question. As long as each microformat maintains a valid profile, each can be used effectively.
Q: How do I validate my microformated content?
A: See validators for a list of microformats validators.
Q: Why do microformats use English terms for property names?
A: Similar to how HTML uses English words like "class", "span" or "head", microformats re-uses English words for property names. As microformats property names are based on existing standards (see process, and naming-principles), this is another problem that is far outside the scope of microformats. As Ryan King put it, this is a pre-existing (unsolved) "problem" with English-based HTML, the English-based CSS, the English-based HTTP and so on. Note that this is NOT about the internationalization of the content and data itself - which is of course an excellent goal, advocated and promoted by microformats and the standards they are based on (e.g. W3C, IETF). This is purely about the names of the properties (and enumerated values) in the formats. See also internationalization and the en-US FAQ: why not use other spellings and languages for properties regarding the question of alternate (non-English) names in other (natural) languages, and mappings.
Q: How come microformats stay as drafts even though they seem usable?
A: This was discussed at the The Growth and Evolution of Microformats panel at SXSW 2007. The basic answer is it was important to at least have a basic software implementation -- even an experimental one -- before moving a format from Draft to Specification. It can sometimes be hard to recognize subtle inconsistencies within a format by eye; however, in the process of implementing a format-reader in code, inconsistencies (if any) can become much more noticeable (due to DRY / Don't Repeat Yourself, among other programming best practices). Then, once such tools have been created (in effect, confirming both the programmability of the format, and interoperability across tools), it can be considered for transition to a Specification. Using interoperable implementations as a measure of format quality is a long-standing practice of IETF and W3C.
Creating and Suggesting New Microformats
Q. I would like to author a new microformats open standards specification for my site/business. How do I get started?
A. The first thing to do before attempting a new microformat open standard is to make as much use of POSH and existing microformats open standards as possible in whatever site you are looking to mark up with your new microformat, as a way of learning what is left to be done. That is, at a minimum first:
- Mark up all people and organizations as hCards and add those pages to hcard-examples-in-wild
- Mark up all events and time based things as hCalendar events and add those pages to hcalendar-examples-in-wild
- Mark up all reviews as hReviews and add those pages to hreview-examples-in-wild
- etc.
Then join the microformats IRC channel and discuss list, and ask folks what they think of your use of the microformats and if it can be improved.
From that experience you will then be able to figure out what is left to be specified. Otherwise it is too hard to approach the "whole problem".
Once you have completed that, take a look at the microformats process for how to walk through the steps of creating a new microformat, and note the specific problem you are trying to solve to the microformats-discuss list. This will help you find more people to help you solve the problems you are trying to solve.
Q How do I know if an idea for a Microformat has already been suggested in the past?
A. Check the list of proposed and rejected microformats.
Q. What if I can't find real-world examples of a standard I'd like to propose?
A. If we can't find real-world examples of the types of data a proposal would address, it's probably not suitable for a microformat. If we only can't find real-world examples of the specific markup a proposal would use for that data, however, that's not really a problem. It's actually the lack of such standard markup in real-world publishing around a specific problem that suggests the need for increased consensus.
Specific Microformat Questions
If you have a question regarding a specific microformat, you may want to check the FAQ specific to that microformat.
- hatom-faq
- hcalendar-faq
- hcard-faq
- hreview-faq
- rel-faq
- rel-tag-faq
- xfn-faq
- xfolk-faq
- xmdp-faq
- xoxo-faq
Class interactions
Q. Are there issues with page styling when specific class values are used?
A. There might be. However, any such issues can be easily (trivially) worked around by using contextual selectors.
Q. How does the use of class values for semantics interact with the use of class values for attaching CSS styles?
A. The class attribute takes a space separated set of class names HTML4 reference. Thus both author and microformat defined class names may be used in the same class attribute. Experience has shown that the best practice is for authors to use their own class names for styling, and only use microformats class names for expressing microformats semantics. If the author is already using using specific class names, they can continue to do so. If the author is already using a class name that happens to also be a microformats class name, then the author may want to consider using contextual CSS class selectors to make sure to reduce any unintentional styling effects, or ideally use their own site-specific class names that are not microformats class names.
See also:
- A Touch Of Class
- Class For Meaning Not For Show
- Competant Classing, by Eric Meyer for discussion of choosing class names in (X)HTML
- Class attributes are about more than styling - Ryan King dispells common misconceptions about the HTML class attribute.
- Why you should say HTML classes, CSS class selectors, or CSS pseudo-classes, but not CSS classes
Q. Are class names case sensitive?
A: Yes, HTML class names (i.e. as used in microformats) are case-sensitive.
By convention, microformats use all lowercase classnames similar to CSS's approach. This way authors never have to guess about the capitalization of microformats properties - they're always all lowercase.
<div>
and <span>
semantics
Q. Can microformats use other elements besides divs?
A. Yes. Markup with microformats should use the most appropriate semantic HTML. For example if the name of an organization hCard is a top level heading, then:
<div class=vcard>
<h1 class="fn org">ACME Co.</h1>
</div>
is more appropriate than
<div class=vcard>
<div class="fn org">ACME Co.</div>
</div>
Q. Is it semantically meaningless to use divs?
A. Yes, both <div>
and <span>
have nearly no semantics. <div>
can be used to represent a "division" of the page content. Similarly <span>
can be used to reperesent that that "span" of text has some meaning, but the specifics of what that meaning is undefined by the <span>
.
Q. Does the use of <div>
and <span>
elements add any semantics to web pages?
A. According to the HTML 4 spec, <div>
and <span>
"offer a generic mechanism for adding structure to documents." Their only meaning is in dividing documents into sections, and as such, their presence implies that the content within has a specific, but undefined by the element markup, semantic. Thus they are nearly semantic-free.
Q. Why do the examples on the wiki use <span>
and <div>
for nearly everything?
A. <span>
and <div>
are generic elements in HTML. When you use microformats, you should pick the most specific semantic element available for the semantics you are trying to express. You might, for example, apply class="vevent"
to a <tr>
, or class="vcard"
to a <p>
. Here is an example using more semantic HTML with a definition list to mark-up an hCard:
<dl class="vcard">
<dt class="category">Restaurant</dt>
<dd class="fn org">
<a class="url" href="http://www.yelp.com/biz/crepes-n-more-fairfield">Crepes N More</a>
</dd>
<dt>Address</dt>
<dd class="adr">
<span class="street-address">620 Jackson st.</span>,
<span class="locality">Fairfield</span>,
<abbr class="region" title="California">CA</abbr>,
<span class="postal-code">94533</span>,
<abbr class="country-name" title="United States of America">USA</abbr>
</dd>
<dt>Phone</dt>
<dd class="tel">+1.707.428.2210</dd>
</dl>
Class semantics
Q. How will microformat class names impact page size?
A. You probably won't notice any impact on page size when authoring with microformats. Our experience is that people use comparably sized class names, and semantic class names are now considered an industry best practice. Some sites are successfully publishing millions of microformats, and we haven't heard any complaints yet. You are more likely to gain space savings by more fully adopting the principles of microformats, and eliminating tables for layout. TODO: Consider creating a new section for web authoring tips? Or at least linking to another site that advocates good authorship.
Q. Can an element have more than one class
A. Yes, the class attribute can contain a space delimited list of classes. For example:
<p class="todo idea">Write high quality and simple mark-up.</p>
See W3C HTML 4.01 Specification: 7.5.2 Element identifiers: the id and class attributes
Q. Does the order of class names matter?
A. No. The HTML class attribute is an unordered space separated set of class names. The order of classes in an class attribute do affect their meaning or use. E.g. these two divs' class names are equivalent:
<div class="a b">...</div>
<div class="b a">...</div>
Q. Do (X)HTML class names have semantics?
A. The HTML4 specification does not define any particular class values REF, nor does it define any particular semantic for class values REF, except that they "may be used for general user agent processing" REF. However, the " draft of "Hypertext Links in HTML", allows for a "profile" to define meanings for those classes. XMDP is a format for defining meta data profiles for (X)HTML, and thus an XMDP profile can be used to define the meanings of class names.
See also:
Q. I thought one of the main goals of CSS was to separate data from presentation. Isn’t this sneaking presentation back into data?
A. This is a quite commonly expressed objection to the way microformats uses class, but it's based on a misunderstanding of the way the class attribute in HTML was designed. Yes, class is very commonly,and appropriately used by web designers in conjunction with CSS to style pages, and in truth, it is often overused for that, but despite this, class, according to the HTML specification "has several roles in HTML", including "for general purpose processing by user agents".
Microformats utilize this second aspect of the class (and id) attribute, and do so legitimately. It is not an abuse of the class or id attribute to use it to add semantic context to a document. Nor is the use of class in and of itself presentational - in fact, it is an important mechanism for separating presentation from structured content.
For some more on using class semantically, here are some articles
- Competent Classing by Eric Meyer
- Use class with semantics in mind, W3C
- More about the class attribute, Tantek Çelik
Q. Should human readable data go into class names?
A. No. We should not put human readable data into the class
attribute, because it puts human-readable data in a spot that's no longer visible. See the principles.
Q. Follow-up. How is that different from putting human readable data into the title
attribute?
A. The title attribute is displayed in tool-tips in the overwhelming majority of browsers in use and thus is quite semi-visible, and thus human verifiable by casual users. The class attribute is not displayed in a tool-tip or any other user interface (not withstanding developer interfaces like view source).
Q. Why don't microformats use the HTML5 data-
attributes to embed data?
A:
- The HTML5
data-
attribute specification expressly forbids the microformats use-case:
— HTML5 · Embedding custom-non-visible dataCustom data attributes are intended to store custom data private to the page or application, for which there are no more appropriate attributes or elements. These attributes are not intended for use by software that is independent of the site that uses the attributes. [...] It would be inappropriate, however, for the user to use generic software not associated with that music site to search for tracks of a certain length by looking at this data. This is because these attributes are intended for use by the site's own scripts, and are not a generic extension mechanism for publicly-usable metadata.
- Microformats are designed around the principle that non-visible data is undesirable, harder to maintain, more prone to inaccuracy (as no-one will see the data on the page to notice errors). The
data-
attribute is explicitly designed for non-visible data.
Hidden Content
Related to microformats and spam.
Q: If I markup some content inside of a block with display:none, will crawlers get data from it anyway?
A. Crawlers and search engines frown upon hidden (e.g. display:none) content in general (e.g. see next FAQ about Google, hidden content, and spam). If some content doesn't fit into your visible design, then it's not worth microformatting it. Visible content is the only content you can reasonably trust/expect to be correct / up to date. Invisible content tends to rot, get out of date, fail to be checked etc., so don't waste any time publishing invisible content - it's going to die anyway.
- shortlink
- http://j.mp/gnohide
A. It is advisable not to hide information in your site, regardless of whether it is microformatted or not. Microformats provide a mechanism for marking up visible content. Any mechanism for embedding invisible or hidden content risks being considered spam due to the fact that invisible (meta)data inevitably ends up being abused. Avoid invisible (meta)data. Publish visible data.
Google in particular have said:
In general, Google won't display content that is not visible to the user. In other words, don't show content to users in one way, and use hidden text to mark up information separately for search engines and web applications. You should mark up the text that actually appears to your users when they visit your web pages.[1]
The only 'hidden' data they support according to that article is specific use of the value class pattern value-title
empty span with machine-readable information adjacent to a human-readable equivalent.
Design Patterns with Abbr & Title
Q. Why is ABBR being used when the title attribute is available on all HTML elements?
In the datetime design pattern the title attribute is used for the value of the property and the node value is used as the display value. <abbr title="value-here">Display-Here</abbr>.
A. The short answer is that <abbr> has the correct semantics.
The longer answer is that the value is often an abbreviated version of the formal value. Of course, if you don't want to use an <abbr>, you can use another element like this:
<abbr title="2006-12-31T12:59:59Z" class="dtstamp">New Year</abbr>
<span class="dtstamp">2006-12-31T12:59:59Z</span>
In addition, microformats encourage the content to be visible and thus prefer the text of an element rather than using the 'title' attribute or any other less visible alternative. The exception is made for datetimes and abbr due to the fact that microformats are for humans first, machines second. Thus the content of the abbr element is used to provide human visible content and the machine equivalent is placed in the less visible (but still easily verifiable) 'title' attribute.
Q. Can I include information within the HTML element itself?
Longer: Can I include information within the HTML element itself? e.g. <span class="org" title="Foobar, Inc."></span>? [2]
A. You can't do that with the span
element because there is no specific semantic connection between the element contents and its title
other than being "advisory information about the element". In addition, it's bad form (and penalized by Google) to include invisible data on web pages.
Instead, you can use the abbr
element and its title
attribute to provide an expanded form of the information in cases where substituting the expanded form when reading the text in context reads correctly, e.g. inside an hCard:
<abbr class="region" title="Connecticut">CT</abbr>
Nesting of elements
Q. It seems that <span class="vcard fn org" id="club">...</span>
should work. Is this correct?
A. No. See hcard-faq#nesting-properties.
Usage/Verbiage
Q. Is Microformat a proper noun? Should it be capitalized?
A. Since the term "microformat" was established, it has been written in lowercase. This is a nod to its roots in the term "lowercase semantic web", in contrast to the uppercase "Semantic Web" which has long been tied to RDF and other technologies often viewed as impractical for the open web. In a few cases in the wild(citation needed), the term has been capitalized as "Microformat", perhaps due to proper noun capitalization conventions.
Q. Can you use microformat as an adjective or verb, as in "microformatted content" or "can you please microformat that page with an hCard?"
A. Because the word microformat is derived from the word format, it makes logical sense that one can use the term as an adjective or verb, just as one would use the word format.
Other
Q. 'How do I find an answer to a question not mentioned here?
A. Join irc and ask!