hCard resolved issues

(Difference between revisions)

Jump to: navigation, search
(moved closed issues to hcard-issues-closed, added see also section.)
(resolved a few remaining issues that happened to be on the hCard feedback page)
Line 383: Line 383:
*# The "n" optimization rules (nickname, fn) should not apply where the fn is on part of adr or label: e.g <code><nowiki>     
*# The "n" optimization rules (nickname, fn) should not apply where the fn is on part of adr or label: e.g <code><nowiki>     
<span class="fn locality">New York</span></nowiki></code>; <code><nowiki><span class="fn label">Asia</span></nowiki></code>,  since, in these examples, "Asia" is not a nickname, "New" is not a given-name and "York" is not a family-name. (see also [[hcard-brainstorming#Named_locations]])
<span class="fn locality">New York</span></nowiki></code>; <code><nowiki><span class="fn label">Asia</span></nowiki></code>,  since, in these examples, "Asia" is not a nickname, "New" is not a given-name and "York" is not a family-name. (see also [[hcard-brainstorming#Named_locations]])
-
</div>
 
-
</div>
 
*#* ACCEPTED BRAINSTORMING. This both makes sense from the point of view of avoiding a shorthand optimization to represent a person in a case where clearly the markup represents a place, and for allowing one possible way to use hCard for named locations.
*#* ACCEPTED BRAINSTORMING. This both makes sense from the point of view of avoiding a shorthand optimization to represent a person in a case where clearly the markup represents a place, and for allowing one possible way to use hCard for named locations.
Line 390: Line 388:
*#We can't have a generic type name cause we have to localize in French. so, for us, hCard work phone number is: <nowiki><div class="tel"><span class="type">Travail</span> : <span class="value">0321596224</span></div></nowiki>. How will a bot recognize that type ? We cannot specify every types in every languages in the specification. That's why i think something like this would be better: <nowiki>Travail : <span class="telwork">0321596224</span></nowiki> Please, use class and id attributes ONLY for microformats specifications ! XML #cdata and #data are localized ! Thanks !
*#We can't have a generic type name cause we have to localize in French. so, for us, hCard work phone number is: <nowiki><div class="tel"><span class="type">Travail</span> : <span class="value">0321596224</span></div></nowiki>. How will a bot recognize that type ? We cannot specify every types in every languages in the specification. That's why i think something like this would be better: <nowiki>Travail : <span class="telwork">0321596224</span></nowiki> Please, use class and id attributes ONLY for microformats specifications ! XML #cdata and #data are localized ! Thanks !
*#* ACCEPTED ISSUE, REJECTED PROPOSAL. The localization issue is recognized and now addressed by the [[value-class-pattern]]. The proposal  for "telwork" is unnecessary, will contribute to vocabulary expansion for every other property that has a work subtype for example, illustrates a vocabulary anti-pattern, and is thus undesirable.
*#* ACCEPTED ISSUE, REJECTED PROPOSAL. The localization issue is recognized and now addressed by the [[value-class-pattern]]. The proposal  for "telwork" is unnecessary, will contribute to vocabulary expansion for every other property that has a work subtype for example, illustrates a vocabulary anti-pattern, and is thus undesirable.
 +
 +
* 2008-01-13 raised by Christopher Allen at OpenIDDevCamp (collected by [[User:Tantek|Tantek]]).
 +
*# What is the best practice for publishing your TZ in your hCard? As publishing just a fixed offset will likely result in 1 hour off error half the year for more people, given that the rest of the hCard is likely to be static.
 +
*#* ACCEPTED FAQ EXAMPLES. This is an excellent question, and a good subject to address as an example in [[hcard-authoring]] as well as on a page on [[date-time-authoring]] with perhaps a Q&A pointer from [[hcard-faq]].  For now, see [[value-class-pattern]] and Jakob Nielsen's post on [http://www.useit.com/alertbox/9608.html International Usability] which mentions time zone.
*  2008-02-02 raised by [[User:AndyMabbett|Andy Mabbett]]
*  2008-02-02 raised by [[User:AndyMabbett|Andy Mabbett]]
Line 478: Line 480:
*#* I raised this very issue on the mailing list about a month ago, but received no responses. Given that hCard claims to be a "a 1:1 representation of vCard (RFC2426) properties and values in semantic HTML or XHTML" (direct quote from [[hcard|spec]]), I think it's reasonable to infer that these types *are* allowed, but simply undocumented so far. I'll be including support for them in the next alpha of Cognition. [[User:TobyInk|TobyInk]] 23:59, 15 Jun 2008 (PDT)
*#* I raised this very issue on the mailing list about a month ago, but received no responses. Given that hCard claims to be a "a 1:1 representation of vCard (RFC2426) properties and values in semantic HTML or XHTML" (direct quote from [[hcard|spec]]), I think it's reasonable to infer that these types *are* allowed, but simply undocumented so far. I'll be including support for them in the next alpha of Cognition. [[User:TobyInk|TobyInk]] 23:59, 15 Jun 2008 (PDT)
*#* '''ACCEPTED.''' Indeed this is an unintentional omission from the [[hCard]] specification. In the [[hcard#Property_List|hCard list of properties]], the entry for "label" should be changed to "label (type, value)" and the section on [[hcard#adr_tel_email_types|adr tel email types]] should be renamed to "adr email label tel types" and a list item should be added as follows: "* label type: INTL, POSTAL, PARCEL, WORK, dom, home, pref".
*#* '''ACCEPTED.''' Indeed this is an unintentional omission from the [[hCard]] specification. In the [[hcard#Property_List|hCard list of properties]], the entry for "label" should be changed to "label (type, value)" and the section on [[hcard#adr_tel_email_types|adr tel email types]] should be renamed to "adr email label tel types" and a list item should be added as follows: "* label type: INTL, POSTAL, PARCEL, WORK, dom, home, pref".
 +
 +
* 2008-06-16 raised by [[User:Kornel|Kornel]]
 +
*# In the rfc2426 the KEY property defaults to binary. hCard profile suggests to use &lt;abbr&gt; for the key. Shouldn't it recommend data: URI with application/pgp-keys type or HTTP URL to a PGP/GPG key file? Key in &lt;abbr&gt; can't be copied/saved without dedicated hCard parser. And I'm not sure if line-breaks (removed by attribute whitespace normalisation) aren't neccessary for parsing key file.
 +
*#* ACCEPTED FAQ EXAMPLES. How to author a "key" property value should be better addressed as indicated, in both [[hcard-examples]] and [[hcard-authoring]] with perhaps a Q&A pointer from [[hcard-faq]].
* 2008-12-11 raised by [[User:mephtu|mephtu]]
* 2008-12-11 raised by [[User:mephtu|mephtu]]

Revision as of 02:36, 5 June 2009

Contents

resolved issues

Issues that are resolved but may have outstanding to-do items.

As issues are resolved, they will be moved from the Issues list to this section.

As actions are taken according to the resolutions noted in the issues, they are moved to hcard-issues-closed.

resolved 2005

Note: As the resolutions are enacted and the issues are closed, it may be worth moving this year of issues to its own page.

<span class="adr">
<span class="type">work</span>:
...
</span>
<span class="tel">
<span class="type">work</span>:
<span class="value">123.456.7890</span>
</span>

the TYPE needs to be a sub-element of the property (adr, tel, etc) NOTE: EMAIL does NOT have many TYPE attributes, only INTERNET and X400


resolved 2006

Note: As the resolutions are enacted and the issues are closed, it may be worth moving this year of issues to its own page.

TODO: please add appropriate context and history of this issue from the mailing list. Sign your name to your comments.

resolved 2007

Note: As the resolutions are enacted and the issues are closed, it may be worth moving this year of issues to its own page.

<p>
<span class="vcard">
<span class="fn">Christina Hope</span>& nbsp;& nbsp;& nbsp;
<span class="department">Information Technology</span>& nbsp;& nbsp;& nbsp;
<span class="role">Website Coordinator</span>& nbsp;& nbsp;& nbsp;
<span display="none" class="region"></span>
<span class="tel"> x3408</span> & nbsp;& nbsp;& nbsp;
<span class="email"><a href="mailto:chope@example.com">chope@example.com</a></span>
</span></p>
Try
<p class="vcard">
<span class="fn">Christina Hope</span>
<span class="department">Information Technology</span>
<span class="role">Website Coordinator</span>
<abbr class="tel" title="+44123 456 7890 x 3408"> x3408</abbr>
<a class="email" href="mailto:chope@example.com">chope@example.com</a>
</p>
Note: apply classes to existing elements; use abbr to give the phone number in full, in international format. Also, use CSS, not non- breaking spaces, for spacing.
Andy Mabbett 08:34, 22 Jan 2007 (PST)


<span class="tel" xml:lang="es">
  <abbr class="type" title="home">Casa</abbr> (<span class="type">pref</span>erido):
  <span class="value">+1.415.555.1212</span>
</span>
<span class="tel home pref" xml:lang="es">
  Casa (preferido):
  <span class="value">+1.415.555.1212</span>
</span>

It could be argued that somehow this solution violates the microformats principle of visible data. Maybe it does, but i18n should come first because otherwise microformats violates the first rule: solve a specific problem (and the last: "enable and encourage decentralized and distributed development, content, services: explicitly encourage the original 'spirit of the Web'"). -Xavier Badosa


<h2>Pizza Shops in Burlingame, California</h2> <ul> <li>Round Table - 231 Burlingame Avenue</li> <li>Village Host - 303 Broadway</li> <li>Pizza Hut - 43423 El Camino Real</li> </ul>

As specified, there'd be a lot of repeated information here.

However, if adr allowed use of locality, region, postcode and country as ancestors of the more specific address tags, it would save a lot of bits -- and help adoption of these microformats in this kind of case (which is quite common).

resolved 2008

Note: As the resolutions are enacted and the issues are closed, it may be worth moving this year of issues to its own page.


see also

hCard resolved issues was last modified: Wednesday, December 31st, 1969

Views