hcard-issues

From Microformats Wiki
Revision as of 10:52, 20 May 2009 by MirkoGustony (talk | contribs) (→‎2007: Changed source code listing to be displayed properly)
Jump to navigation Jump to search

<entry-title> hCard issues </entry-title>

These are externally raised issues about hCard with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

IMPORTANT: Please read the hCard FAQ and the hCard resolved issues before giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — Tantek

For matters relating to the vCard specification itself, see vcard-errata and vcard-suggestions.

See other issues also.

closed issues

See: hcard-issues-resolved

resolved issues

See: hcard-issues-resolved

issues

Please add new issues to the bottom of the list by copy and pasting the Template. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

2006

  • open issue! 2006-10-21 raised by Andy Mabbett
    1. There should be some way to say that the URL of an hCard or hCalendar event is the URL of the page itself, without having to include a redundant, and accessibility-damaging link to that page, on the page itself.
      • Quite often I see "a" webpage accessible with several different URLs. Typically 1 URL is the "preferred" URL, expected to have a long lifetime. Sometimes other URLs are "convenience" URLs that may have been linked to in the past, but are expected to go away soon, which resolve to the same file (the "latest version"). Then there are "archive" URLs that show an exact copy of that webpage as it appeared some time in the past. I think we want to always use the "preferred" URL, no matter which of those URLs we happen to stumble upon first -- so the URL is not actually redundant. (How exactly is it "accessibility-damaging" for a page to link to itself? Could you explain or add a link to an explanation?) --DavidCary 17:44, 5 Apr 2007 (PDT)
        • "How exactly is it "accessibility-damaging" for a page to link to itself?" - Novice user clicks on link; nothing (it appears) happens. Repeat ad infinitum, until user leaves site to do something else. Andy Mabbett 02:43, 6 Apr 2007 (PDT)
      • A: ACCEPTED THEORETICAL. While I tend to agree with the accessibility guidelines/issues noted herein in theory, to make this a real world issue worthy of higher priority, we need documentation of examples in the wild where the URL of an hCard or hCalendar event is the URL of the page itself, so that we can use those examples to inform brainstorming towards a solution. Tantek 15:11, 10 Apr 2007 (PDT)
        • Examples in the wild where the URL of an hCard is the URL of the page itself:
          • The Pipettes page at SXSW 2007 (1 of 1000+ bands). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCard for The Pipettes to indicate that the page itself is the URL for the hCard.
          • See also the proposal to use this pattern in representative-hcard
        • Examples in the wild where the URL of an hCalendar event is the URL of the page itself:
          • The Pipettes at La Zona Rosa page at SXSW 2007 (1 of 1000+ concerts, yes, same page as the page for The Pipettes the org). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCalendar event for The Pipettes at La Zona Rosa to indicate that the page itself is the URL for the hCalendar event.
        • This is also an hReview issue and any other microformat which has a "url" property. Examples where the URL of an (potential) hReview *item* is the URL of the page itself:

2007

  • open issue! 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
    1. RFC2426 'type' values cannot be localized/internationalized in hCard. In the example below, there is no solution to mark the Spanish version with a type of 'home' since the RFC2426 values are defined in English. abbr-design-pattern would suggest using abbr, but 'Casa' is not an abbreviated form of 'home', therefore the currently recommended version (below) is not valid.
<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>
      • REJECTED. TOO LITTLE INFORMATION. Please provide the precise URL to the specific statement on the accessify forum discussion that asserts that using abbr is not valid. Please also provide a precise URL to a *real world* (as opposed to an artificially constructed test case) example in the wild of an non-English hCard which attempts to specify RFC2426 type information on a "tel" property and fails to do so.
      • REOPENED and clarified (Also removed Accessify reference pulled from [original raising]).
        1. Though erroneously first raised on the accessibility page, this is not an accessibility issue. It is an HTML semantics issue for internationalization. abbr[title] should be an expanded form of abbr contents, in the same language.
        2. There are real-world non-English examples in the current Mac OS 10.5 (Leopard) developer seed. This code example illustrates the point sufficiently.
        3. Please leave the clarification as-is even if you feel you must RE-REJECT (add-on, don't revert). My original points were lost when they were taken out of context and moved here. -[[User::JamesCraig|JamesCraig]]
    2. To avoid i18n issues, microformats should keep its hands off content (this also affects hReview). abbr-design-pattern doesn't seem the right solution here. Someone from France suggested elsewhere to use the class value telwork, etc. but again it's a dubious solution (remember that a tel can have a type of voice and work at the same time). I suggest considering:
<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

  • open issue! 2007-03-19 raised by [[User::ChristinaHope|Christina Hope]]
    1. Does Microsoft Outlook 2003 allow the use of the "role" property? I have added it to all of my hCards and it is not appearing. Am I doing something wrong?
        • URL? (if no URL to a demonstrative example is provided within a year of this issue being raised, it will be closed as REJECTED INSUFFICIENT INFORMATION.)
    1. How should we handle Old Style and New Style dates (i.e. Julian calendar vs. Gregorian), in DoB? For instance, Boris Pasternak, born "10 February [O.S. January 29] 1890". Should the hCard spec. specify New Style, using the abbr-design-pattern (or its successor) if necessary: <abbr title="1890-02-10">29 January 1890</abbr>?

2008

    1. The "n" optimization rules (nickname, fn) should not apply where the fn is on part of adr or label: e.g <span class="fn locality">New York</span>; <span class="fn label">Asia</span>, 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)
  • open issue! 2008-01-09 2008- moved from vcard-suggestions
    1. We can't have a generic type name cause we have to localize in French. so, for us, hCard work phone number is: <div class="tel"><span class="type">Travail</span> : <span class="value">0321596224</span></div>. 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: Travail : <span class="telwork">0321596224</span> Please, use class and id attributes ONLY for micro formats specifications ! XML #cdata and #data are localized ! Thanks !
    1. The "n" optimization rules (nickname, fn) should not apply where the fn is also the role or title: e.g <span class="fn role">Webmaster</span>; <span class="fn title">Duty Manager</span>, since, in these examples, "Webmaster" is not a nickname, "Duty" is not a given-name and "Manager" is not a family-name.
    1. It seems to me that FN has been reused beyond its original vCard scope of person names, to cover any name. This led to the fn/title debate, but it seems some implementors are confused between following the vCard semantics (FN only for person names) or the hCard ones (FN for any name). See. http://cinematreasures.org/theater/365/, which uses an empty FN, resulting in their vCard not being detected by Operator, only the address.
    1. The "fn" optimization rule should not apply where the full fn is also the nickname: e.g <span class="fn nickname">Plastic Bertram</span>, since a given-name+family-name pair is not usually a nickname. (But how to deal with pseudonyms such as "Maurice Micklewhite (known professionally as Michael Caine)"?)
    1. Is "n" optional or mandatory? The spec says yes (with exceptions) the cheat-sheet says no. Parsers and common practice seem to indicate not.
    1. "nickname" and "fn" optimization does not work for some or all names in Asian languages. See Tom Cruise on Chinese Wikipedia, where the fn and nickname are the same. This could be partly remedied by not applying such optimization when the page's (or element's) language is set to one of a set of affected languages (may also apply to other languages, such as Greek). Cpmment from people fluent in such languages would be welcome.
  • open issue! 2008-06-01 raised by Kornel
    1. I need clarification how should "more semantic equivalents" be interpreted inside values (when they don't have relevant class name, but are inside another parsed element)
      • <span class="email"><a href="mailto:href">nodetext</a></span> – is it "href", "nodetext" or an error? What if there are multiple links inside?
        • Parsed as "nodetext" TobyInk 08:30, 1 Jun 2008 (PDT)
      • <span class="fn"><abbr title="title">nodetext</abbr></span> – is it "title" or "nodetext"?
        • Parsed as "nodetext" TobyInk 08:30, 1 Jun 2008 (PDT)
      • <span class="fn"><img alt="alt">nodetext</span> – is it "alt", "nodetext" or both?
        • A matter of debate recently. Some parsers as "nodetext", others as "altnodetext". TobyInk 08:30, 1 Jun 2008 (PDT)
      • <span class="fn"><abbr title="title"><span class="value">nodetext</span></abbr></span> – "title", "nodetext" or both?
        • Parsed as "nodetext" TobyInk 08:30, 1 Jun 2008 (PDT)
      • <span class="url"><img src="src" alt="alt">nodetext</span> – "src", "alt", "nodetext" or "altnodetext"?
        • A matter of debate recently. Some parsers as "nodetext", others as "altnodetext". TobyInk 08:30, 1 Jun 2008 (PDT)
      • <div class="category"><a rel="tag bookmark" href="href">nodetext</a></div> – is it a tag? What if there are multiple links inside?
        • Not sure how other parsers treat this, but Cognition will create two categories based on this. One because of the [rel-tag], based on the final component of the URL; and the second category because of class=category, based on the node text. TobyInk 08:30, 1 Jun 2008 (PDT)
    2. Does agent property has to be a hCard?
      • Is <span class="agent">Joe Sixpack</span> allowed?
        • Yes. TobyInk 08:30, 1 Jun 2008 (PDT)
      • Is <span class="agent"><div class="vcard">…</div></span> ok?
        • Cognition doesn't specifically support this format - they'll be parsed as two separate hCards. The "outer" hCard will have an "agent" property containing the unparsed node text for the inner hCard, as if you'd used a plain string for the agent as per the previous example. If you want to provide an hCard for the agent, and have it parsed as such, Cognition requires that you use: <div class="agent vcard">…</div>. (There is also the separate issue that it is illegal in HTML to nest a DIV within a SPAN.) TobyInk 08:30, 1 Jun 2008 (PDT)
      • What about <a class="agent" href="card.vcf">…</a>?
        • I don't think many hCard parsers also parse vCard. If they support vCard it's probably as an output format rather than input. TobyInk 08:30, 1 Jun 2008 (PDT)
    3. Is value of <abbr> without title empty or should it be interpreted like <span>?
      • I think consensus is that the node text should be used. TobyInk 08:30, 1 Jun 2008 (PDT)
    4. Does <acronym> work like <abbr>?
      • Not as per spec, but some parsers do treat it like <abbr>. TobyInk 08:30, 1 Jun 2008 (PDT)
    5. Is this allowed: <div class="photo">http://example.com/photo.jpg</div>?
      • Yes, though it may cause problems for some naive parsers, and is probably less useful for humans viewing the page. TobyInk 08:30, 1 Jun 2008 (PDT)
    6. Is it allowed to use http:// URLs in email? or mailto: in url?
      • Non-SMTP e-mail addresses can be used - the presence of a e-mail "type" of "x400" confirms this - so e-mail addresses which don't start with "mailto:" and do not contain an @-sign are theoretically possible. But given the prevalence of SMTP for mail delivery on the modern Internet, I don't see why this would be useful. For "url" it is often useful to encode non-HTTP URIs, such as FTP addresses or URIs for use with various instant messaging protocols, but given the existence of the "email" property, I don't see that it makes sense to encode "mailto" URIs. TobyInk 08:30, 1 Jun 2008 (PDT)
    7. Is it allowed/required to use mailto: when e-mail is in non-<a>, e.g. <span class="email">mailto:joe@example.com</span>
      • Yes, but for copy-and-pastability I'd recommend leaving out the "mailto:" prefix. TobyInk 08:30, 1 Jun 2008 (PDT)
    8. If value of a property is empty (<span class="email"></span>) should it be interpreted as unknown value? ignored completely like it didn't exist? an error?
    9. Can hCard contain nested hCard anywhere? or only outside any property or only inside agent?
      • Yes, though naive parsers may have problems. TobyInk 08:30, 1 Jun 2008 (PDT)
    10. Can organisation-name (note spelling) be interpreted by parsers?
      • It should not. TobyInk 08:30, 1 Jun 2008 (PDT)
    11. Is type class ignored in values anywhere? It is ignored in <div class="tel"><span class="type">Work</span> 555</div>, but is it in <div class="fn"><span class="type">Work</span> Joe</div>?
      • It doesn't have any special meaning within "fn", so should not be ignored. That is, the person's name would be parsed as "Work Joe". TobyInk 08:30, 1 Jun 2008 (PDT)
  • open issue! 2008-06-15 raised by Kornel
    1. RFC 2426 allows TYPE for LABEL, however hCard cheatsheet does not list any subproperties for label. Is this intentional? Is label's type allowed in hCard?
    • 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 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. TobyInk 23:59, 15 Jun 2008 (PDT)
  • open issue! 2008-12-11 raised by mephtu
  • I am concerned that hCard usage will foster widespread abuse of personal datamining by scrapers/spammers, as a standard markup of personal information formalizes the structure of such information which until now has been loosely encoded as formatting markup (e.g. HTML).
    • The nice thing about microformats is that you are not required to publish everything. If you are not comfortable publishing your email, address, phone or other information, then you don't have to. If you are already publishing it on the web, then by adding microformats you are disambiguating a plain string of text and a string as meaning your name. Brian 08:56, 12 Dec 2008 (UTC)
      • That is true, but it does more tightly associate e-mail addresses with other information. Spammers could use this to tie an e-mail address to other personal/contact details and make their messages less spammy in an attempt to fool filters. For example, some filters will raise the spam score of a message if the "To" field contains just an e-mail address, and not the recipient's name - hCard provides spammers with a fairly reliable way of finding out that name. I don't think this is a huge concern, but it is a slight concern which shouldn't be entirely dismissed. TobyInk 16:37, 12 December 2008 (UTC)


    1. The "n" optimization rule for turning an fn of "WORD C." into an n given-name initial of "C" and family-name of "WORD" should be dropped, as it was not based on sufficient usage in practice (based on why I put it in there in the first place), and (a) it actually interferes with some broad usage in historical practice, e.g. on Pownce user's names were abbrevated as "GIVEN F." where GIVEN was their given-name and F was there family-name initial and (b) may have problems with non-Western name abbreviations also.
      • suggested resolution: drop respective "n" optimization rule, and suggest markup for any use of abbreviated name components with abbr tag, e.g. <span class="fn">Tantek <abbr>Ç.</abbr></span>
        • Could retain the rule when a comma or semicolon is found between the two parts though. TobyInk 22:39, 16 December 2008 (UTC)
  • open issue! 2008-12-16 raised by TobyInk
    1. n is listed as a required property. Sometimes this is implicit from the fn, and that's fine. However, when <span class="fn">Foo</span> is found, "Foo" is implicitly a nickname, so the hCard still has no n property — does such an hCard still need an explicit n added?


template

Consider using this format (copy and paste this to the end of the list to add your issues; replace ~~~ with an external link if preferred) to report issues or feedback, so that issues can show up in hAtom subscriptions of this issues page. If open issues lack this markup, please add it.

Please post one issue per entry, to make them easier to manage. Avoid combining multiple issues into single reports, as this can confuse or muddle feedback, and puts a burden of separating the discrete issues onto someone else who 1. may not have the time, and 2. may not understand the issue in the same way as the original reporter. 

<div class="hentry">
{{OpenIssue}} 
<span class="entry-summary author vcard">
 <span class="published">2011-MM-DD</span> 
 raised by <span class="fn">~~~</span>
</span>
<div class="entry-content discussion issues">
* <strong class="entry-title">«Short title of issue»</strong>. «Description of Issue»
** Follow-up comment #1
** Follow-up comment #2
</div>
</div>

related pages

The hCard specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. These thoughts, issues, and questions are kept in separate pages.

Retrieved from "http://microformats.org/wiki/index.php?title=hcard-issues&oldid=38770"