hcard-issues: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(Added FN required issue in hCard in HTML tables)
m (Replace <entry-title> with {{DISPLAYTITLE:}})
 
(42 intermediate revisions by 15 users not shown)
Line 1: Line 1:
<h1> hCard issues </h1>
{{DISPLAYTITLE: hCard issues }}
{{TOC-right}}
 
These are externally raised issues about [[hcard|hCard]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documedabnted 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.  
These are externally raised issues about [[hcard|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|hCard FAQ]] and the [[hcard-issues-resolved|hCard resolved issues]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.
'''IMPORTANT''': Please read the [[hcard-faq|hCard FAQ]] and the [[hcard-issues-resolved|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. — [http://tantek.com/ Tantek]
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. — [[User:Tantek|Tantek]]


For matters relating to the vCard specification itself, see [[vcard-errata]] and [[vcard-suggestions]].
For matters relating to the vCard specification itself, see [[vcard-errata]] and [[vcard-suggestions]].
See other [[issues]] also.


== closed issues ==
== closed issues ==
See: [[hcard-issues-resolved]]
See: [[hcard-issues-closed]]


== resolved issues ==
== resolved issues ==
Line 18: Line 16:


== issues ==
== issues ==
<span id="Issues">Please add new issues</span> to the '''bottom''' of the list by copy and pasting the [[hcard-issues#Template|Template]].  Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues.  Duplicate issue additions will be reverted.
<span id="Issues">Please add new issues</span> to the '''bottom''' of the list by copy and pasting the [[#template|template]].  Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues.  Duplicate issue additions will be reverted.
 
=== 2006 ===
 
* {{OpenIssue}} 2006-10-21 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''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?) --[[User:DavidCary|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. [[User:AndyMabbett|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. [[User:Tantek|Tantek]] 15:11, 10 Apr 2007 (PDT)
*#** Examples in the wild where the URL of an hCard is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html 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:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html 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-issues|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:
*#*** [http://www.amazon.com/exec/obidos/ASIN/0553380958 Snow Crash (Bantam Spectra Book) (Paperback) on Amazon] (millions of potential hReview items/products with reviews on their item pages).
 
=== 2007 ===
* {{OpenIssue}} 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# 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. <strong>abbr-design-pattern</strong> would suggest using abbr, but 'Casa' is not an abbreviated form of 'home', therefore the currently recommended version (below) is not valid.<pre><nowiki>
<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>
</nowiki></pre>
*#* 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 [[http://microformats.org/wiki?title=accessibility&oldid=12943 original raising]]).
*#*# Though erroneously first raised on the accessibility page, this is not an accessibility issue. It is an HTML semantics issue for internationalization. <code>abbr[title]</code> should be an expanded form of <code>abbr</code> contents, in the same language.
*#*# There are real-world non-English examples in the current Mac OS 10.5 (Leopard) developer seed. This code example illustrates the point sufficiently.
*#*# 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]]
 
<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2007-03-19</span> raised by <span class="fn">[[User::ChristinaHope|Christina Hope]]</span></span>
<div class="description">
*# ''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.)
</div>
</div>
 
<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2007-03-31</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# The [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84 scehma] used as a default by <code>geo</code> will not remain valid forever. Fortunately, the proposed [[geo-extension-strawman|geo extension]], originally intended for lunar/ Martian coordinates, also provides a facility for the specification of other, Earth-bound schema, which will alleviate this problem. [[User:AndyMabbett|Andy Mabbett]] 13:00, 31 Mar 2007 (PDT)
*#* Note also the forthcoming [http://www.euref-iag.net/ European Terrestrial Reference System 89 schema] (See also [http://en.wikipedia.org/wiki/European_Terrestrial_Reference_System_1989 Etrs89 on Wikipedia]. [[User:AndyMabbett|Andy Mabbett]] 03:11, 5 Apr 2007 (PDT)
</div>
</div>
 
<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2007-04-19</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*#How should we handle [http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates Old Style and New Style dates] (i.e. Julian calendar vs. Gregorian), in DoB? For instance, [http://en.wikipedia.org/wiki/Boris_Pasternak 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: <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>?
</div>
</div>
 
===2008===


<div class="vevent">
===2010===
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-01-01</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011182.html microformats-discuss/2008-January/011182.html]</span>
* none.
<div class="description">
===2011===
*# The "n" optimisation rules (nickname, fn) should not apply where the fn is on part of adr or label: e.g <code><nowiki>
* none currently.
<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>
 
<div class="vevent">
* {{OpenIssue}} <span class="summary"><span class="dtstart">2008-01-09</span> <span id="tel-type-lang">2008- moved from vcard-suggestions</span></span>
<div class="description">
*#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 micro formats specifications ! XML #cdata and #data are localized ! Thanks !
</div>
</div>
 
<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-02</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# The "<code>n</code>" optimisation rules (<code>nickname</code>, <code>fn</code>) should not apply where the <code>fn</code> is also the <code>role</code> or <code>title</code>: e.g <code><nowiki>
<span class="fn role">Webmaster</span></nowiki></code>; <code><nowiki><span class="fn title">Duty Manager</span></nowiki></code>,  since, in these examples, "Webmaster" is not a nickname, "Duty" is not a given-name and "Manager" is not a family-name.
</div>
</div>
 
<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-06</span> raised by <span class="fn">[[User:Guillaume Lebleu| Guillaume Lebleu]]</span></span>
<div class="description">
*# 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.
</div>
</div>
 
<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-07</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# The "<code>fn</code>" optimisation rule should not apply where the full <code>fn</code> is also the <code>nickname</code>: e.g <code><nowiki><span class="fn nickname">Plastic Bertram</span></nowiki></code>, 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)"?)
</div>
</div>
 
<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-07</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011552.html microformats-discuss/2008-February/011552.html]</span>
<div class="description">
*# Is "n" optional or mandatory? The spec says yes (with exceptions) the cheat-sheet says no. Parsers and common practice seem to indicate not.
</div>
</div>
 
<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-07</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011552.html microformats-discuss/2008-February/011552.html]</span>
<div class="description">
*# "<code>nickname</code>" and "<code>fn</code>" optimisation does not work for some or all names in Asian languages. See [http://zh.wikipedia.org/wiki/%E6%B9%AF%E5%A7%86%C2%B7%E5%85%8B%E9%AD%AF%E6%96%AF Tom Cruise on Chinese Wikipedia], where the <code>fn</code> and nickname are the same. This could be partly remedied by not applying such optimisation 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.'''
</div>
</div>
 
<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-08</span> raised by <span class="fn">[[User:Guillaume Lebleu| Guillaume Lebleu]]</span></span>
<div class="description">
*# The required FN makes it difficult to use hCard in HTML Tables without resorting to hiding information (as in http://www.bo.ingv.it/contents/INGV-Bologna/Staff.html) or using the [[include-pattern]]. Perhaps FN should not be required if some N are present. Originally raised in [http://rbach.priv.at/Microformats/IRC/2008-02-08#T181749]
</div>
</div>


== template ==
== template ==
{{issues-format}}
{{issues-format}}


== related pages ==
== related pages ==
{{hcard-related-pages}}</nowiki>
{{hcard-related-pages}}

Latest revision as of 16:26, 18 July 2020


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.

closed issues

See: hcard-issues-closed

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.

2010

  • none.

2011

  • none currently.

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=69846"