faq: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(Added FAQ about indicating the presence of a microformat)
(s/<source>/<syntaxhighlight>/)
(133 intermediate revisions by 27 users not shown)
Line 1: Line 1:
(削除) = (削除ここまで)Microformats (削除) wiki (削除ここまで)FAQ (削除) = (削除ここまで)
(追記) {{DISPLAYTITLE: (追記ここまで)Microformats FAQ (追記) }} (追記ここまで)


(削除) == wiki specific (削除ここまで)questions (削除) == (削除ここまで)
(追記) This page document frequently asked (追記ここまで)questions (追記) about microformats. For frequently asked questions from the [[press]], see [[press-faq]]. (追記ここまで)


(削除) Q: (削除ここまで)'(削除) 'How do I create (削除ここまで)a (削除) username? Why won't it let me use my preferred username?'' (削除ここまで)
(追記) If you (追記ここまで)'(追記) re looking for (追記ここまで)a (追記) microformat for marking up FAQs, see [[question-answer]]. (追記ここまで)


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 (削除) caplitalize (削除ここまで)the first letter of the user name.
(追記) == 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>&lt;span class="h-card p-org"></code> (追記ここまで)
(追記) * RIGHT: <code>&lt;span class="h-card">&lt;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>&lt;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>&lt;span class="p-author h-card"></code> (追記ここまで)
(追記) 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 [http://microformats.org/mailinglists-policies/ mailinglists-policies]. In particular note: (追記ここまで)
(追記) <blockquote> (追記ここまで)
(追記) '''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. (追記ここまで)
(追記) </blockquote> (追記ここまで)
(追記) 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 ==
== Basic Microformat Questions ==
(追記) ===Q: ''Who uses microformats?'' === (追記ここまで)


(削除) Q (削除ここまで): (削除) ''Are (削除ここまで)microformats (削除) dependent upon (X)HTML?'' (削除ここまで)
(追記) A (追記ここまで): (追記) See a list of [[examples-in-wild|sites using (追記ここまで)microformats(追記) ]] and [[implementations|numerous tools]] that support microformats. (追記ここまで)


(削除) A (削除ここまで): (削除) Microformats (削除ここまで)are (削除) made to be embeddable. They can be embedded in (X)HTML, RSS, Atom or anywhere (X)HTML is allowed. (削除ここまで)
(追記) ===Q (追記ここまで): (追記) ''When should I use a microformat? What (追記ここまで)are (追記) they for?''=== (追記ここまで)


(削除) Q (削除ここまで): (削除) ''Microformats sound great (削除ここまで). (削除) How can (削除ここまで)I (削除) help?' (削除ここまで)'
(追記) 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! (追記ここまで)


(削除) A: First of all, take (削除ここまで)a (削除) look at http://microformats.org/discuss (削除ここまで)to (削除) see some ways to join the conversations about microformats (削除ここまで).
(追記) 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: ''I'(削除) d like to make a donation to the microformat cause. How can I do this? (削除ここまで)''
(追記) === (追記ここまで)Q: ''(追記) Should (追記ここまで)I (追記) use microformats or microdata? (追記ここまで)'''(追記) === (追記ここまで)


A: (削除) Thank you for your willingness to support (削除ここまで)microformats(削除) . We (削除ここまで)'(削除) ve only recently started this site and have decided that while we (削除ここまで)are (削除) figuring out exactly how (削除ここまで)to (削除) accept donations, we will be passing along donations to other good causes (削除ここまで). (削除) Please consider donating to another cause like Red Cross (削除ここまで), (削除) perhaps directed to help victims of recent natural disasters (削除ここまで).
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]] (追記ここまで).


(削除) Q: (削除ここまで)'(削除) 'Which (削除ここまで)microformats (削除) have been implemented?'' (削除ここまで)
(追記) If you (追記ここまで)'(追記) re looking for minimal markup addition, just use (追記ここまで)microformats(追記) . (追記ここまで)


(削除) See the [[implementations]] page (削除ここまで).
(追記) If you want to use both, you may do so because they don't interfere (追記ここまで).


Q: ''(削除) Which (削除ここまで)microformats (削除) should I implement (削除ここまで)?''
(追記) === (追記ここまで)Q: ''(追記) Are (追記ここまで)microformats (追記) dependent upon (X)HTML (追記ここまで)?''(追記) === (追記ここまで)


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]]. If you are publishing press releases (削除ここまで), (削除) try using [[hatom]] (削除ここまで).
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: ''Do you have any link badges I can add to my website/blog?'' (削除ここまで)


(削除) A (削除ここまで): (削除) Not yet, but we (削除ここまで)'(削除) ll post them when we do.. (削除ここまで).
(追記) ===Q (追記ここまで): '(追記) 'Microformats sound great (追記ここまで). (追記) How can I help?''=== (追記ここまで)


(削除) Q (削除ここまで). (削除) ''Are there any tools that support (削除ここまで)microformats(削除) ?'' (削除ここまで)
(追記) 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(追記) . (追記ここまで)


(削除) A. Yes... [[implementations]]. (削除ここまで)


Q(削除) . (削除ここまで)''(削除) What about using new URI schemes instead of class names, e.g (削除ここまで). (削除) for geo information (削除ここまで)?''
(追記) === (追記ここまで)Q(追記) : ' (追記ここまで)'(追記) I (追記ここまで)'(追記) d like to make a donation to the microformat cause (追記ここまで). (追記) How can I do this (追記ここまで)?''(追記) === (追記ここまで)


A. In general, it is more work, and less content-publisher friendly, to ask (削除) them (削除ここまで)to use URI schemes instead of class names.
(追記) 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?'' === (追記ここまで)
(追記) 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|hCard]], see the [[hcard-authoring|hCard authoring]] page for step by step instructions. If you are publishing press releases, try using [[hatom|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 <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?'' === (追記ここまで)
(追記) 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?''=== (追記ここまで)
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.
Authors aren't publishing links to geo information.
Line 53: Line 186:


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.
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 [[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]] (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|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. (追記ここまで)
(追記) (追記ここまで)
(追記) == 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 [[hcard|hCards]] and add those pages to [[hcard-examples-in-wild]] (追記ここまで)
(追記) * 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]] and add those pages to [[hreview-examples-in-wild]] (追記ここまで)
(追記) * etc. (追記ここまで)
(追記) 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". (追記ここまで)
(追記) (追記ここまで)
(追記) 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. (追記ここまで)
(追記) * [[rejected-formats]] (追記ここまで)
(追記) (追記ここまで)
(追記) ===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]] (追記ここまで)
(追記) * [http://gmpg.org/xfn/faq xfn-faq] (追記ここまで)
(追記) * [[xfolk-faq]] (追記ここまで)
(追記) * [[xmdp-faq]] (追記ここまで)
(追記) * [[xoxo-faq]] (追記ここまで)


== 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. (削除) In addition, microformat (削除ここまで)class names (削除) provide the author with a consistent set of (削除ここまで)class names (削除) to use (削除ここまで)for (削除) styling (削除ここまで). If the author is already using using specific class names, they can continue to do so(削除) , and include microformat class names (削除ここまで). If the author is already using a class name that happens to also be a (削除) microformat (削除ここまで)class name, then the author may want to consider using contextual CSS class selectors to make sure (削除) that avoid (削除ここまで)any unintentional styling effects.
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 69: 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>&lt;div&gt;</code> and <code>&lt;span&gt;</code> semantics ==
== <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> semantics ==


Q. Is it semantically meaningless to use divs?
(追記) === (追記ここまで)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>&lt;div class=vcard&gt;<br/><strong>&lt;h1 class="fn org"&gt;ACME Co.&lt;/h1&gt;</strong><br/>&lt;/div&gt;</code></p> is more appropriate than <p><code>&lt;div class=vcard&gt;<br/><strong>&lt;div class="fn org"&gt;ACME Co.&lt;/div&gt;</strong><br/>&lt;/div&gt;</code></p> (追記ここまで)
(追記) === Q. '' (追記ここまで)Is it semantically meaningless to use divs?(追記) '' === (追記ここまで)


A. Yes, both <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> have nearly no semantics. <code>&lt;div&gt;</code> can be used to represent a "division" of the page content. Similarly <code>&lt;span&gt;</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>&lt;span&gt;</code>.
A. Yes, both <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> have nearly no semantics. <code>&lt;div&gt;</code> can be used to represent a "division" of the page content. Similarly <code>&lt;span&gt;</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>&lt;span&gt;</code>.


Q. Does the use of <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> elements add any semantics to web pages?
(追記) === (追記ここまで)Q. (追記) '' (追記ここまで)Does the use of <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> elements add any semantics to web pages?(追記) ''=== (追記ここまで)
(追記) A. According to the [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.4 HTML 4 spec], <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> "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. (追記ここまで)


(削除) A. According to the [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.4 spec], <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> "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 <code class="element">&lt;span&gt;</code> and <code class="element">&lt;div&gt;</code> for nearly everything?(追記) ''=== (追記ここまで)
(削除) (削除ここまで)
Q. Why do the examples on the wiki use <code class="element">&lt;span&gt;</code> and <code class="element">&lt;div&gt;</code> for nearly everything?


A. <code class="element">&lt;span&gt;</code> and <code class="element">&lt;div&gt;</code> are generic elements in HTML. When you use microformats, you should pick the most specific semantic element available.
A. <code class="element">&lt;span&gt;</code> and <code class="element">&lt;div&gt;</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 ==


Q. ''Do (X)HTML class names have 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|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 [[microformats#the_microformats_principles|the principles of microformats]], and eliminating tables for layout. (追記ここまで)
(追記) <span class="todo">''TODO: Consider creating a new section for web authoring tips? Or at least linking to another site that advocates good authorship.''</span> (追記ここまで)
(追記) ===Q. ''Can an element have more than one class''=== (追記ここまで)
(追記) A. Yes, the class attribute can contain a space delimited list of classes. For example: (追記ここまで)
(追記) &lt;p class=&quot;todo idea&quot;&gt;Write high quality and simple mark-up.&lt;/p&gt; (追記ここまで)
(追記) 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?''(追記) === (追記ここまで)


A. The HTML4 specification does not define any particular class values [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF], nor does it define any particular semantic for class values [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF], except that they "may be used for general user agent processing" [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF]. However, the [http://www.w3.org/TR/WD-htmllink-970328#profile" draft of "Hypertext Links in HTML"], allows for a "profile" to define meanings for those classes. [http://gmpg.org/xmdp/ 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.
A. The HTML4 specification does not define any particular class values [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF], nor does it define any particular semantic for class values [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF], except that they "may be used for general user agent processing" [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF]. However, the [http://www.w3.org/TR/WD-htmllink-970328#profile" draft of "Hypertext Links in HTML"], allows for a "profile" to define meanings for those classes. [http://gmpg.org/xmdp/ 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.
Line 94: Line 337:
* [http://www.w3.org/TR/WD-htmllink-970328 Hypertext Links in HTML]
* [http://www.w3.org/TR/WD-htmllink-970328 Hypertext Links in HTML]


== (削除) Indicating (削除ここまで)a page (削除) contains microformat (削除ここまで)markup ==
==(追記) =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 [http://www.w3.org/TR/html4/struct/global.html#h-7.5.2 "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 (追記ここまで)
(追記) * [http://meyerweb.com/eric/thoughts/2004/07/18/competent-classing Competent Classing by Eric Meyer] (追記ここまで)
(追記) * [http://www.w3.org/QA/Tips/goodclassnames Use class with semantics in mind, W3C] (追記ここまで)
(追記) * [http://tantek.com/log/2004/07.html#d20t2359 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 <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?''=== (追記ここまで)
(追記) ;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: <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 &amp; 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. &lt;abbr title="value-here"&gt;Display-Here&lt;/abbr&gt;. (追記ここまで)
(追記) A. The short answer is that &lt;abbr&gt; 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 &lt;abbr&gt;, you can use another element like this: (追記ここまで)
(追記) &lt;abbr title="2006年12月31日T12:59:59Z" class="dtstamp"&gt;New Year&lt;/abbr&gt; (追記ここまで)
(追記) &lt;span class="dtstamp"&gt;2006年12月31日T12:59:59Z&lt;/span&gt; (追記ここまで)
(追記) 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. &lt;span class="org" title="Foobar, Inc."&gt;&lt;/span&gt;?'' [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 == (追記ここまで)
(追記) === Q. ''It seems that <code>&lt;span class=&quot;vcard fn org&quot; id=&quot;club&quot;&gt;...&lt;/span&gt;</code> 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. (削除) Is there a way to indicate (削除ここまで)that (削除) a given web (削除ここまで)page (削除) contains markup that conforms to one or more microformats (削除ここまで)?
(追記) === (追記ここまで)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. (削除) The HTML HEAD Profile 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 (削除ここまで).
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''' (追記ここまで).


== (削除) Microformats and Spam (削除ここまで)==
== (追記) Other == (追記ここまで)
(追記) === Q. '''How do I find an answer to a question not mentioned here?'' = (追記ここまで)==


(削除) Q (削除ここまで). (削除) Given that Google now looks at hidden content as potential spam, will microformats be considered spam? (削除ここまで)
(追記) A (追記ここまで). (追記) Join [[irc]] and ask! (追記ここまで)


(削除) A. Microformats aren't meant to disguise semantics -- only provide a mechanism for marking up the content you intend to make visible on a page, typically no more and no less. Where we embed semantic equivalents in the tags themselves (i.e. GMT times in abbr tags for times), it doesn't seem logical that such data could be considered spam. (削除ここまで)
(追記) == See Also == (追記ここまで)
(追記) * [[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 surrounding h-event
  • the value of that h-event’s p-location is an entire embedded h-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:

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:

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.

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:

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

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:

  1. The HTML5 data- attribute specification expressly forbids the microformats use-case:[引用]

    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.

    — HTML5 · Embedding custom-non-visible data
  2. 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. 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?

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月31日T12: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>

[3]

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!

See Also

Retrieved from "http://microformats.org/wiki/index.php?title=faq&oldid=70690"