Microformats Wiki - User contributions [en]

hcard-faq

2006-12-17T04:03:17Z

JoshieSurber: /* Should I use ADDRESS for hCards */

<h1> hCard FAQ </h1>

This page is for documenting Q&A about [[hcard|hCard]]. If you have a new question to ask, please consider first asking your question on the [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] mailing list.

<h2>Editing this Page</h2>
Please do not use "?" or other punctuation in the headers - it helps to keep the URLs to their fragment identifiers shorter and easier to read, copy/paste etc. See [[how-to-play]] for more wiki editing guidelines.

<h2> Q&A </h2>

=== Should I use ADDRESS for hCards ===
''Should I use the more semantic <code><nowiki><address></nowiki></code> element for my hCards?''
* The <code><nowiki><address></nowiki></code> element is more semantic, but it is ''too'' specifically semantic for most hCard uses. The poorly named <code><nowiki><address></nowiki></code> element really means <contact-info-for-this-web-page>. The [http://www.w3.org/TR/html401/struct/global.html#h-7.5.6 HTML4 definition of the ADDRESS element] says it is used "to supply contact information for a document or a major part of a document such as a form." Therefore, <code><nowiki><address></nowiki></code> should be used for an hCard ONLY IF that hCard represents the contact information for the page or major part thereof. One example of such a usage is on [http://tantek.com/log/ Tantek's blog]. Another way of saying this is the following two statements: Every <address> on a page SHOULD be an hCard. But not every hCard should be an <code><nowiki><address></nowiki></code>. <br /> In short, '''DO NOT''' use <code><nowiki><address></nowiki></code> to markup addresses in general. Only use it to markup the contact information for the page (or major part thereof), and when doing so, use it to markup ''the entire'' contact information (via <address class="vcard">), not just the address of the contact.

=== Why is adr property necessary ===
''What is the point of class="adr" when we have the <address> element?.''- 2006-12-04 asked by [[User:JoshieSurber|Joshie]] [http://joshie.surber.us Surber].
* First, '''<address> DOES NOT MEAN "address"''' Second, "adr" is about physical addresses, whereas <address> is meant specifically for the contact information for the page or major part thereof. They are totally different.

=== Why is url property necessary ===
''Why is it necessary to put class name "url" on URL elements in the hCard when those hyperlinks already start with "http://", and that is enough to distinguish them from email links?''
* The classname "url" is necessary to explicitly distinguish hyperlinks that are URL elements for the hCard, from other hyperlinks that may be related to the item or otherwise in the same containing element but should not be included in the hCard. Common links that may appear in the document but not be contact information are action related links (download data, add to friends list, etc.) contact hyperlinks (email, internal site messaging, autodialers), as well as hyperlinks to photos, or other random hyperlinks that happen to be inside the hCard.

=== How do I support an existing vCard URL ===
''I already have a vCard that I keep up-to-date. I don't want to change any references to it because it might break something else, what can I do?''
* You can use .HTACCESS to rewrite links to your vCard to a webservice that converts a page to the vCard dynamically, to do this you need to add something similar to your .htaccess file
<pre>
RewriteRule ^path/to/old.vcf http://suda.co.uk/projects/X2V/get-vcard.php\?uri=http://example.com/hCard_encoded.htm&filename=old.vcf
</pre>

Now you shouldn't have to do anything else, all links to the "old.vcf" are redirected to the webservice and will return a new vCard that is dynamially generated from your page.

I think that using 'Redirect' is better than using mod_rewrite (is not enabled on some hosts) --Robert Bachmann
<pre>
Redirect /path/to/old.vcf http://suda.co.uk/projects/X2V/get-vcard.php?uri=http://example.com/hCard_encoded.htm&filename=old.vcf
</pre>

=== What are plural hCard properties ===
''Is there a list of all hCard properties which can be plural?''<br />
''Is there a list of all the properties which can have multiple instances?''
* There is the [[hcard#Property_List|list of hCard properties]], and the list of [[hcard#Singular_properties|singular hCard properties]]. Everything that is not singular is plural. This list was presented explicitly (after much analysis of RFC2426) because it was too hard to read RFC2426 and reliably grok which properties were singular vs. plural. See also [[hcard-cheatsheet]].

Old previous answer:
* We have avoided *duplicating* (or providing a shortcut for) the "can this property occur multiple times or not" deliberately in order to avoid repeating a constraint from RFC 2426 vCard, and thus potentially getting it wrong. Here is the way to determine whether or not a particular property can occur multiple times (is a plural property / may have multiple instances or values).
* Check the [[hcard-profile|hCard XMDP profile]] for the property definition.
* If the property definition references a plural form in RFC 2426 (e.g. honorific-suffix references honorific suffixes), then the property is a plural property.
* Else go check the referenced section in RFC 2426 which should state explicitly whether or not the property is plural or singular.
* Else (if RFC 2426 is *not* explicit) then the property is plural.

=== What does FN stand for ===

''What does FN stand for?''
* FN stands for "Formatted Name." From Section 3.1.1 of the RFC:
<blockquote>Type purpose: To specify the formatted text corresponding to the name of the object the vCard represents.</blockquote>
* The reasoning behind this seems to be that, while N gives us a structured name, FN gives us the human-readable, formatted name which is assembled from its structured parts in a culturally dependant way.

=== How is gender represented ===
''How do you represent gender in hCard?''
* There is no GENDER property in [http://www.ietf.org/rfc/rfc2426.txt vCard RFC2426]. [[hcard|hCard]] is following the schema from vCard for interoperability reasons. It is possible to represent gender implicitly in the honorific-prefix field, e.g. Mr. for male, and Ms. for female:
<pre><nowiki>
<span class="honorific-prefix">Mr.</span>
</nowiki></pre>
or
<pre><nowiki>
<span class="honorific-prefix">Ms.</span>
</nowiki></pre>

This approach does have the limitation that "Mr." and "Ms." (or "Miss"/ "Mrs.") may conflict with a higher-ranking, gender-neutral honorific, such as "Dr." or "Rev." for the person, as it is unusual to refer to someone as "Mr. Dr." or "Mrs. Rev." for example. See [[hcard-issues]].

Note that there is also a [http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/vcard_name.asp page on MSDN that mentions vCard and "gender"]. Not sure what to make of that.

Gender could be represented with a [[genealogy-formats|genealogical microformat]], but that seems like overkill.

Instead, you could use tags/categories to tag people's hCards with their gender, "male", "female", or any other tag you feel is appropriate. See [http://en.wikipedia.org/wiki/Gender_identity gender identity] for more on the topic.

See also [[vcard-suggestions#Gender]].

=== Can a hCard contain extra elements ===
''Is it OK for an hCard node to contain extra elements?''
* Yes, parsers will ignore anything they don't understand.

=== Can a GEO be inferred from an ADR in an hCard ===
''Can I automatically add GEO from an address when transforming an hCard to vCard if it is not present?''
* No, an address represents a building which is a polygon, whereas a GEO only represents a single point

=== X2V does not convert email with name as plain text ===
''X2V doesn't convert my email address correctly, it is in the form href="FirstName LastName <Email@example.com>"''
* While that form of email address works for some programs such as outlook, it is not a valid mailto: value (see [http://www.faqs.org/rfcs/rfc2368.html RFC2368]) the FirstName and LastName should be omitted.

One possible valid hCard markup would be:

<pre><nowiki>
<span class="vcard">
<span class="fn">Firstname Lastname</span>
&lt;<a class="email" href="mailto:Email@example.com">Email@example.com</a>&gt;
</span>
</nowiki></pre>



This might be displayed as:
<div style="border: thin dashed black">
Firstname Lastname <[http://email@example.com email@example.com]>
</div>

=== What hCard properties are required ===
''What properties are required in an hCard?''
* The only required properties are 'fn' (the formatted name) and 'n' (the structured name), but 'n' can under certain circumstances be inferred from the <code>fn</code> property. See the [[hcard#Implied_.22n.22_Optimization|Implied N Optimization]] for details. See also [[hcard-cheatsheet]].

=== Does N property require all sub-properties ===
''If I use the 'n' property, do I have to use ALL of the sub-properties?''
* No, You can use as many or as few as you need to mark-up the name, but at a minimum you should at least use the 'given-name' and 'family-name' sub-properties if at all possible. If all you have is a nickname/handle/userid, then consider simply marking it up as an 'fn' property and taking advantage of the [http://microformats.org/wiki/hcard#Implied_.22nickname.22_Optimization Implied "nickname" Optimization]. See also [[hcard-cheatsheet]].

=== Do FN and N need to be on same element ===
''Do the 'fn' and 'n' properties have to be on the same element?''
* No, you can have two separate elements, for example:
<pre><nowiki>
<p class="vcard">My name is
<span class="n">
<span class="honorific-prefix">Mr.</span>
<span class="given-name">John</span>
<span class="additional-name">Q</span>
<span class="family-name">Public</span>
</span>
but you can just call me
<span class="fn">Johnny</span>
</p>
</nowiki></pre>

=== How do you convert a vCard to an hCard ===
''Is there a way to convert a vCard to an hCard?''
* There is no canonical conversion from a vCard to an hCard because you can construct an hCard in many different ways while expressing the same semantics. If you would like to recommend a suggested template hCard to use when displaying vCards in a browser, please propose it to the [http://microformats.org/discuss mailing list].

=== Are descendant elements recognized in a microformat ===
''Are descendants recognized in a microformat property?''
* Yes, for example:
<pre><nowiki>
<span class="country-name">United States <small>of</small> America</span>
</nowiki></pre>
The output would be "United States of America".

=== Do properties like TEL use all descendants ===
''Do properties like TEL use all descendants?'' e.g. <pre><nowiki><span class="tel"><span class="type">Home</span>:<span class="value">+1.234.567.8900</span></span></nowiki></pre><br>''Shouldn't that output be "TEL:Home: +1.234.567.8900"?''
* No. class="value" is used to denote a sub-element which is used for the value of the property. See [[hcard#Value_excerpting|Value excerpting]] for more details.

=== Can you have multiple value elements ===
''Can you have multiple class="value" elements inside a property and what happens to them?''
* Sure, for example:
<code><nowiki><span class="tel"><span class="type">Home</span>:<span class="value">+1</span>.<span class="value">234</span>.<span class="value">567</span>.<span class="value">8900</span></span>
</nowiki></code><br> would output: "+12345678900".

=== 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. class="vcard fn"?</span>''
* No, for several reasons:
** It breaks the simple contextual CSS selector rule for finding and styling property values: .rootname .propertyname which will make it more difficult to write scoped CSS for the properties. For more on why this is important see the [[faq#Class_interactions|microformats FAQ regarding class interactions]].
** It will result in more confusion for parsers which may be parsing nested microformats.

=== Can you mix a property and its sub-properties ===
''Can singular sub-properties be mixed with parents?''
* No, all sub-properties MUST be on elements inside their parents.

=== Can you use query strings on email ===
''What happened to the Query String on my email address?''
* Query strings are removed from email addresses because they are not valid for importing to vCards

=== Are ADR and TEL types case sensitive ===
''Is the list of possible types for an ADR and TEL case sensitive?''
* No, enumerated values are case-'''in'''sensitive, therefore Home, home, HOME, etc. are all equivalent.

=== How does GEO work with ABBR ===
''What happens to the GEO sub-properties when GEO is used with ABBR?''
* The GEO property can be represented two different ways:
<pre>
<nowiki>
<span class="geo">
<span class="latitude">123.45</span>
<span class="longitude">67.89</span>
</span>

<abbr class="geo" title="123.45;67.89">My House</abbr>
</nowiki>
</pre>
When used with an <abbr> element the latitude and longitude are separated by a semicolon.

=== Why is the root class name vcard ===
''Why is the root class="vcard" and not 'hcard'?''
* The reason is historical, hCard is based off of the vCard specification.

=== How do you mark up a phone extension ===
''How do I mark up a phone extension in hCard?''
There doesn't seem to be a way to declare a telephone extension in the vCard RFC 2426 spec, the suggested way is currently:
<pre><nowiki>
<span class="tel">
<span class="type">work</span>: <span class="value">800 555-1212 x 1234</span>
</span>
</nowiki></pre>

RFC 3966 suggests that an extension be indicated with ";ext=" for example:
<pre><nowiki>
<span class="tel">
<span class="type">work</span>: <span class="value">800 555-1212;ext=1234</span>
</span>
</nowiki></pre>
although that is more relevant when used as a URI:
<pre><nowiki>
<span class="tel">
<span class="type">work</span>: <a class="value" href="tel:+18005551212;ext=1234">800 555-1212;ext=1234</a>
</span>
</nowiki></pre>

[http://groups.google.com/group/comp.std.internat/msg/24fc32228689a620?dmode=source ITU-T Recommendation E.123 1.6] specifies the use of the word "extension" or abbreviation thereof:

Telephone International +22 607 123 4567 ext. 876

The above example may be better as:

<pre><nowiki>
<span class="tel">
<span class="type">work</span>: <a class="value" href="tel:+18005551212;ext=1234">800 555-1212 ext. 1234</a>
</span>
</nowiki></pre>

=== How do you encode IM accounts ===
''How do I encode my IM account in hCard?''
* see [[hcard-examples#New_Types_of_Contact_Info|hCard examples: New Types of Contact Info]]

=== Can you hCard the deceased ===
''How do you make an hCard for the deceased?''
* As you normally would, and add the tag "deceased".
* vCards and thus hCard does not have a date-of-death property. You may wish to explore the biographical or [[genealogy-formats]] microformats efforts.
* See also [[vcard-suggestions#Deceased]]

=== Any plans for xparams ===
''Are there plans to include x-parameters in future versions of hCard?''
* No. The problem is that each of these x-parameters are vendor specific and are not part of the RFC. Secondly, there is no way to be 100% sure that 'x-foobar' is not just a content-specific HTML class name that the publisher is using for CSS styling.

=== What is a word in implied optimizations ===
''What constitutes a "word" for the purpose of 'implied-n optimization'?''
* "N" can be implied from "FN" when the content of "FN" is broken into two "words" separated by whitespace. For this purpose, a "word" is any sequence of non-whitespace characters including but not limited to low- and high-range alphanumerics and punctuation. A "word" can be characterised by the following regular expression: <pre><nowiki>/\S+/</nowiki></pre>

=== How do you create non English tooltips ===
''My website is not in English and i want the tooltips to be in my native language''
* Properties such as class="type" require an enumerated list of English words. It is possible to use your native language for the displaying tooltip, but still use the English work for the class="type" without it being shown.
<pre><nowiki>
<abbr class="type" title="home">
<span title="[your native word for home here]">
to my home
</span>
</abbr>
</nowiki>
</pre>
Having an span with a title attribute inside the abbr element will only display the title on the span, where you have the text (your native word for home here).

<h2> Related Pages </h2>
{{hcard-related-pages}}

User:JoshieSurber

2006-12-04T13:58:24Z

JoshieSurber:

Find my website at http://joshie.surber.us

hcard-feedback

2006-12-04T13:57:24Z

JoshieSurber: /* Feedback */

<h1> hCard feedback </h1>

General feedback about [[hcard|hCard]] may be provided here, and the editor(s) will do their best to try to accomodate such feedback. The more specific the feedback the better chance it will be handled. For specific issues with the spec (as opposed to general problems and feedback), please use the [[hcard-issues|hCard issues]] page.

Feedback may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Use the provided template and add your feedback to the end of the Feedback section. Write your feedback well. — [http://tantek.com/log/ Tantek]

__TOC__

== Feedback ==

* 2006-11-15 raised by [http://lachy.id.au/ Lachy] in [irc://freenode/whatwg #whatwg] (an IRC channel on [http://freenode.net/ freenode] about [http://whatwg.org/ The WHATWG]).
*# ''I think the whole [[hcard|hCard]] specification needs to be restructured.''
*# ''It's incredibly difficult to work out what each class name means and how to use them properly.''

* 2006-11-15 raised by hsivonen in #whatwg.
*# ''Without knowing iCalendar or vCard, it is totally non-obvious to see what hCards or hCalendars would be conforming. The normative part is extremely short and doesn't seem to establish clear enough a mapping between the microformats and the RFCs.''
*#* This (and Lachy's 2nd feedback point above) should be addressed by clarifying the mapping with better use of the [[hcard-profile|hCard profile]] which does clearly map the class names to vCard properties and the sections of the vCard specification that defines them. - Tantek

* 2006-11-15 raised by Hixie in #whatwg (and agreed by [http://lachy.id.au/ Lachy] and hsivonen).
*# ''The [[hcard|hCard]] spec basically reads as a brainstorm, not a normative spec.''

* 2006-11-17 raised by [http://lachy.id.au/ Lachlan Hunt].
*# Semantic XHTML Design Princples: This section should go. Guidelines for how to write a microformats specification do not belong in the spec itself.
*# Format - More Semantic Equivalents: Explanations of how to use each property correctly should be given with each and every property, not just list a few at the top before the properties have even been defined.
*# Singlular vs. Plural: It is unclear what is meant by singular vs. plural properties. Ordinarily, a plural is word that refers to multiple objects, but in this spec, it's being used to designate a property that can be used more than once. It doesn't make sense because the property itself isn't a plural. Besides, this section should go. The number of times a property can be used should be listed with each individual property description.
*# Plural Properties Singularized: What the...? After attempting to read that paragraph several times, I still can't comprehend what on earth it's trying to say.
*# Human vs. Machine Readable: This title only makes some sense for the use of the abbr element. Everything in this section should be moved to a Conformance Requirements section, which explains how to extract values from the markup. It should also use RFC 2119 terminology that describes exactly what a UA has to do. Presently, it's written to informatively, rather than normatively (particularly for the abbr element).
*# Property List: This section is almost useless, it's effectively written like an index of properties but doesn't link to or help define, in any way whatsoever, what the actual meaning of a property is, nor how to use it. For every single property, all of the following information should be listed
*#* Property name
*#* Expansion (e.g. it's not clear from this section what fn stands for. First Name? Family Name? Full Name? Flight Number?)
*#* Definition. (e.g. either copy the definition directly from vCard or provide a short summary, and also a link to the relevant vCard section. Saying just "See section #.#.# of RFC 2426.", as done in the profile, is not so easy to do.)
*#* Usage
*#** Contexts in which this property may be used
*#** Content model (e.g. list of sub properties, expected elements, text, or whatever)
*#** Syntax of the value (i.e. plain text, number, URI, etc.)
*#** Elements this property may be used on
*#* How to interpret the value (may link to relevant section in Conformance Requirements)
**I second all of the above. [[User:AndyMabbett|Andy Mabbett]] 07:15, 17 Nov 2006 (PST)

* 2006-12-04 raised by [[User:JoshieSurber|Joshie]] [http://joshie.surber.us Surber] .
*# ''What is the point of class="adr" when we have the <address> element?.''

== Template ==

Please use this format (copy and paste this to the end of the list to add your feedback):
* YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Here is the first general feedback I have.''
*# ''Here is the second general feedback I have.''

== Related Pages ==
{{hcard-related-pages}}

hcard-feedback

2006-12-04T13:56:44Z

JoshieSurber: /* Feedback */

<h1> hCard feedback </h1>

General feedback about [[hcard|hCard]] may be provided here, and the editor(s) will do their best to try to accomodate such feedback. The more specific the feedback the better chance it will be handled. For specific issues with the spec (as opposed to general problems and feedback), please use the [[hcard-issues|hCard issues]] page.

Feedback may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Use the provided template and add your feedback to the end of the Feedback section. Write your feedback well. — [http://tantek.com/log/ Tantek]

__TOC__

== Feedback ==

* 2006-11-15 raised by [http://lachy.id.au/ Lachy] in [irc://freenode/whatwg #whatwg] (an IRC channel on [http://freenode.net/ freenode] about [http://whatwg.org/ The WHATWG]).
*# ''I think the whole [[hcard|hCard]] specification needs to be restructured.''
*# ''It's incredibly difficult to work out what each class name means and how to use them properly.''

* 2006-11-15 raised by hsivonen in #whatwg.
*# ''Without knowing iCalendar or vCard, it is totally non-obvious to see what hCards or hCalendars would be conforming. The normative part is extremely short and doesn't seem to establish clear enough a mapping between the microformats and the RFCs.''
*#* This (and Lachy's 2nd feedback point above) should be addressed by clarifying the mapping with better use of the [[hcard-profile|hCard profile]] which does clearly map the class names to vCard properties and the sections of the vCard specification that defines them. - Tantek

* 2006-11-15 raised by Hixie in #whatwg (and agreed by [http://lachy.id.au/ Lachy] and hsivonen).
*# ''The [[hcard|hCard]] spec basically reads as a brainstorm, not a normative spec.''

* 2006-11-17 raised by [http://lachy.id.au/ Lachlan Hunt].
*# Semantic XHTML Design Princples: This section should go. Guidelines for how to write a microformats specification do not belong in the spec itself.
*# Format - More Semantic Equivalents: Explanations of how to use each property correctly should be given with each and every property, not just list a few at the top before the properties have even been defined.
*# Singlular vs. Plural: It is unclear what is meant by singular vs. plural properties. Ordinarily, a plural is word that refers to multiple objects, but in this spec, it's being used to designate a property that can be used more than once. It doesn't make sense because the property itself isn't a plural. Besides, this section should go. The number of times a property can be used should be listed with each individual property description.
*# Plural Properties Singularized: What the...? After attempting to read that paragraph several times, I still can't comprehend what on earth it's trying to say.
*# Human vs. Machine Readable: This title only makes some sense for the use of the abbr element. Everything in this section should be moved to a Conformance Requirements section, which explains how to extract values from the markup. It should also use RFC 2119 terminology that describes exactly what a UA has to do. Presently, it's written to informatively, rather than normatively (particularly for the abbr element).
*# Property List: This section is almost useless, it's effectively written like an index of properties but doesn't link to or help define, in any way whatsoever, what the actual meaning of a property is, nor how to use it. For every single property, all of the following information should be listed
*#* Property name
*#* Expansion (e.g. it's not clear from this section what fn stands for. First Name? Family Name? Full Name? Flight Number?)
*#* Definition. (e.g. either copy the definition directly from vCard or provide a short summary, and also a link to the relevant vCard section. Saying just "See section #.#.# of RFC 2426.", as done in the profile, is not so easy to do.)
*#* Usage
*#** Contexts in which this property may be used
*#** Content model (e.g. list of sub properties, expected elements, text, or whatever)
*#** Syntax of the value (i.e. plain text, number, URI, etc.)
*#** Elements this property may be used on
*#* How to interpret the value (may link to relevant section in Conformance Requirements)
**I second all of the above. [[User:AndyMabbett|Andy Mabbett]] 07:15, 17 Nov 2006 (PST)
* 2006-12-04 raised by [[User:JoshieSurber|Joshie]] [http://joshie.surber.us Surber] .
*# ''What is the point of class="adr" when we have the <address> element?.''

== Template ==

Please use this format (copy and paste this to the end of the list to add your feedback):
* YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Here is the first general feedback I have.''
*# ''Here is the second general feedback I have.''

== Related Pages ==
{{hcard-related-pages}}

hcard-feedback

2006-12-04T13:55:49Z

JoshieSurber: /* Feedback */

<h1> hCard feedback </h1>

General feedback about [[hcard|hCard]] may be provided here, and the editor(s) will do their best to try to accomodate such feedback. The more specific the feedback the better chance it will be handled. For specific issues with the spec (as opposed to general problems and feedback), please use the [[hcard-issues|hCard issues]] page.

Feedback may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Use the provided template and add your feedback to the end of the Feedback section. Write your feedback well. — [http://tantek.com/log/ Tantek]

__TOC__

== Feedback ==

* 2006-11-15 raised by [http://lachy.id.au/ Lachy] in [irc://freenode/whatwg #whatwg] (an IRC channel on [http://freenode.net/ freenode] about [http://whatwg.org/ The WHATWG]).
*# ''I think the whole [[hcard|hCard]] specification needs to be restructured.''
*# ''It's incredibly difficult to work out what each class name means and how to use them properly.''

* 2006-11-15 raised by hsivonen in #whatwg.
*# ''Without knowing iCalendar or vCard, it is totally non-obvious to see what hCards or hCalendars would be conforming. The normative part is extremely short and doesn't seem to establish clear enough a mapping between the microformats and the RFCs.''
*#* This (and Lachy's 2nd feedback point above) should be addressed by clarifying the mapping with better use of the [[hcard-profile|hCard profile]] which does clearly map the class names to vCard properties and the sections of the vCard specification that defines them. - Tantek

* 2006-11-15 raised by Hixie in #whatwg (and agreed by [http://lachy.id.au/ Lachy] and hsivonen).
*# ''The [[hcard|hCard]] spec basically reads as a brainstorm, not a normative spec.''

* 2006-11-17 raised by [http://lachy.id.au/ Lachlan Hunt].
*# Semantic XHTML Design Princples: This section should go. Guidelines for how to write a microformats specification do not belong in the spec itself.
*# Format - More Semantic Equivalents: Explanations of how to use each property correctly should be given with each and every property, not just list a few at the top before the properties have even been defined.
*# Singlular vs. Plural: It is unclear what is meant by singular vs. plural properties. Ordinarily, a plural is word that refers to multiple objects, but in this spec, it's being used to designate a property that can be used more than once. It doesn't make sense because the property itself isn't a plural. Besides, this section should go. The number of times a property can be used should be listed with each individual property description.
*# Plural Properties Singularized: What the...? After attempting to read that paragraph several times, I still can't comprehend what on earth it's trying to say.
*# Human vs. Machine Readable: This title only makes some sense for the use of the abbr element. Everything in this section should be moved to a Conformance Requirements section, which explains how to extract values from the markup. It should also use RFC 2119 terminology that describes exactly what a UA has to do. Presently, it's written to informatively, rather than normatively (particularly for the abbr element).
*# Property List: This section is almost useless, it's effectively written like an index of properties but doesn't link to or help define, in any way whatsoever, what the actual meaning of a property is, nor how to use it. For every single property, all of the following information should be listed
*#* Property name
*#* Expansion (e.g. it's not clear from this section what fn stands for. First Name? Family Name? Full Name? Flight Number?)
*#* Definition. (e.g. either copy the definition directly from vCard or provide a short summary, and also a link to the relevant vCard section. Saying just "See section #.#.# of RFC 2426.", as done in the profile, is not so easy to do.)
*#* Usage
*#** Contexts in which this property may be used
*#** Content model (e.g. list of sub properties, expected elements, text, or whatever)
*#** Syntax of the value (i.e. plain text, number, URI, etc.)
*#** Elements this property may be used on
*#* How to interpret the value (may link to relevant section in Conformance Requirements)
**I second all of the above. [[User:AndyMabbett|Andy Mabbett]] 07:15, 17 Nov 2006 (PST)
* 2006-12-04 raised by [http://joshie.surber.us Joshie] [[User:JoshieSurber|Surber]].
*# ''What is the point of class="adr" when we have the <address> element?.''

== Template ==

Please use this format (copy and paste this to the end of the list to add your feedback):
* YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Here is the first general feedback I have.''
*# ''Here is the second general feedback I have.''

== Related Pages ==
{{hcard-related-pages}}