hCard resolved issues

Jump to: navigation, search


resolved issues

hCard 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.

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.

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.

<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>
<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>
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 class="tel home pref" xml:lang="es">
  Casa (preferido):
  <span class="value">+1.415.555.1212</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.

resolved 2009

resolved issue 2009-218 raised by Singpolyma

  • Format for key. What format should be used for key? I suggest the following:
    <a class="key" type="application/pgp-keys" href="https://path.to/key">My PGP Key</a>
    With MIME type obviously changed based on type of key.
    • RESOLVED ACCEPTED FAQ EXAMPLES. This seems reasonable to me, and we should update hcard-examples and hcard-faq accordingly. Thanks for the suggestion. Tantek 02:57, 26 August 2009 (UTC)

resolved issue 2009-09-10 raised by TomMorris

  • Parsing UTF-8 'special' space characters in telephone fields. I recently designed a page that used an hCard with a span containing the tel value. To space the phone number appropriately, I used the U+8201 (THIN SPACE) character &#8201;. Operator's hCard parser coughed up on this and refused to read both the contents of the tel span but also an a element containing the email property that was contained in the parent p element. I cannot find a clear definition of what is acceptable content for the tel property. There seems to be two ways of resolving this: (1) instruct authors of microformat parsing libraries to normalise the Unicode characters U+8194 (EN SPACE), U+8195 (EM SPACE), U+8196 (THREE-PER-EM SPACE), U+8197 (FOUR-PER-EM SPACE), U+8198 (SIX-PER-EM SPACE), U+8199 (FIGURE SPACE), U+8200 (PUNCTUATION SPACE), U+8201 (THIN SPACE), U+8202 (HAIR SPACE), U+8203 (ZERO WIDTH SPACE) and other similar characters (including the HTML entities &ensp;, &emsp;, &thinsp; and &nbsp;) so that, for the purpose of parsing the microformat they are treated as a standard space (U+0020) or (2) instructing microformat authors to not use any other space character than U+0020 (and to use the CSS word-spacing property for manipulating tel properties). Which of these is best? Anyone want to survey the current implementations to see how they currently parse telephone numbers with unexpected characters in them? Part of the problem may be that there doesn't seem to be any clear specification of what a valid telephone number is, so far as I can see—which is just from reading RFC 2426 §3.3, which says that it should simply be the telephone format defined in X.500 (RFC 1274), but there is no explicit definition in X.500 except to say it is "telephoneNumberSyntax", which is defined in RFC 1778 §2.16 as simply being a printable string. Perhaps I've gone off down a blind alley! (Do we need a page for character encoding/Unicode issues?)
    • ACCEPTED FAQ, parsing. microformats depend on the character parsing of the language they are in. In this case, let's for example see what HTML4 and HTML5 say, and advise accordingly in hcard-faq and hcard-parsing. Tantek 08:56, 9 October 2009 (UTC)

resolved 2010

resolved issue 2010-02-03 raised by Philip Jägenstedt

see also

hCard resolved issues was last modified: Tuesday, July 20th, 2010