hcard-issues-closed - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:26:31Z

Replace <entry-title> with {{DISPLAYTITLE:}}

← Older revision		Revision as of 16:26, 18 July 2020
Line 1:		Line 1:
	~~<entry-title>~~hCard closed issues~~</entry-title>~~		{{DISPLAYTITLE:hCard closed issues}}

	== closed issues ==		== closed issues ==

Tantek: typo

2011-10-26T21:52:23Z

typo

← Older revision		Revision as of 21:52, 26 October 2011
Line 2:		Line 2:

	== closed issues ==		== closed issues ==
	[[hCard]] <span id="Closed_Issues">closed issues that have no further actions to take.</span>.		[[hCard]] <span id="Closed_Issues">closed issues that have no further actions to take.</span>

	=== closed 2005 ===		=== closed 2005 ===

Oli: /* closed 2008 */ adding link to #fn-opt-i18n

2010-07-20T02:50:03Z

closed 2008: adding link to #fn-opt-i18n

← Older revision		Revision as of 02:50, 20 July 2010
Line 238:		Line 238:
	* 2008-02-07 raised by [[User:AndyMabbett\|Andy Mabbett]] in [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011552.html microformats-discuss/2008-February/011552.html]		* 2008-02-07 raised by [[User:AndyMabbett\|Andy Mabbett]] in [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011552.html microformats-discuss/2008-February/011552.html]
	*# "<code>nickname</code>" and "<code>fn</code>" optimization 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 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). '''Comment from people fluent in such languages would be welcome.'''		*# "<code>nickname</code>" and "<code>fn</code>" optimization 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 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). '''Comment from people fluent in such languages would be welcome.'''
	# REJECTED DUPLICATE. This is a duplicate of issue raised 2007-03-28 ~~by James Craig~~.		# REJECTED DUPLICATE. This is a duplicate of [[hcard-issues-resolved#fn-opt-i18n\|previous issue raised by James Craig 2007-03-28]].

	* 2008-12-16 raised by [[User:Tantek\|Tantek Çelik]]		* 2008-12-16 raised by [[User:Tantek\|Tantek Çelik]]

Tantek: /* closed 2008 */ implemented resolution to issue 2008-12-16 n optimization.

2010-04-16T02:22:38Z

closed 2008: implemented resolution to issue 2008-12-16 n optimization.

← Older revision		Revision as of 02:22, 16 April 2010
Line 239:		Line 239:
	*# "<code>nickname</code>" and "<code>fn</code>" optimization 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 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). '''Comment from people fluent in such languages would be welcome.'''		*# "<code>nickname</code>" and "<code>fn</code>" optimization 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 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). '''Comment from people fluent in such languages would be welcome.'''
	# REJECTED DUPLICATE. This is a duplicate of issue raised 2007-03-28 by James Craig.		# REJECTED DUPLICATE. This is a duplicate of issue raised 2007-03-28 by James Craig.

			* 2008-12-16 raised by [[User:Tantek\|Tantek Çelik]]
			*# 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. <code><nowiki><span class="fn">Tantek <abbr>Ç.</abbr></span></nowiki></code>
			#* Could retain the rule when a comma or semicolon is found between the two parts though. [[User:TobyInk\|TobyInk]] 22:39, 16 December 2008 (UTC)
			#** At this point, unless sufficient real world sites are documented which use that practice of "a comma or semicolon is between the two parts", it is preferable to drop it, for simplicity. [[User:Tantek\|Tantek]] 23:17, 3 June 2009 (UTC)
			# ACCEPTED. Resolution: Drop "WORD C." "n" optimization rule, noting the past examples of Pownce (formerly at <nowiki>http://pownce.com</nowiki>) and Dodgeball (formerly at <nowiki>http://dodgeball.com/</nowiki>), and the more recent example of [http://foursquare.com/ Foursquare] (originally at http://playfoursquare.com).
			# CLOSED. Resolution implemented in [[hCard]]. [[User:Tantek\|Tantek]] 02:22, 16 April 2010 (UTC)

	=== closed 2009 ===		=== closed 2009 ===

Tantek: /* closed 2006 */ resolve a 2006-12-15 issue re: invisible data - all follow-up actions were completed.

2009-11-24T07:03:53Z

closed 2006: resolve a 2006-12-15 issue re: invisible data - all follow-up actions were completed.

@@ Line 202: / Line 202: @@
 *#**** The vCard spec is updated by RFC, for example [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770]. [[User:AndyMabbett|Andy Mabbett]] 06:22, 12 Jan 2007 (PST)
 *#***** A: COLLECTED AND CLOSED. The suggestion has been documented in [[vcard-suggestions]] and it's now up to vCard 4 to see it is adopted or not.  If it is, then hCard 1.1 can consider adding it.
 === closed 2007 ===

Tantek: /* closed 2006 */ closed 2006-11-16

2009-11-10T09:10:06Z

closed 2006: closed 2006-11-16

← Older revision		Revision as of 09:10, 10 November 2009
Line 194:		Line 194:
	#* Second, as of 2009 many (most?) profile pages have some form of live or updating content, and thus it makes functional sense to include a link to the page itself labeled something like "reload" or "refresh". When the user clicks the link, it's not that "nothing happens" as claimed above, but rather, the user is shown new content. If the site provides updates dynamically (e.g. via XHR), then when doing so they can also use javascript+CSS that hides any such manual reload/refresh link.		#* Second, as of 2009 many (most?) profile pages have some form of live or updating content, and thus it makes functional sense to include a link to the page itself labeled something like "reload" or "refresh". When the user clicks the link, it's not that "nothing happens" as claimed above, but rather, the user is shown new content. If the site provides updates dynamically (e.g. via XHR), then when doing so they can also use javascript+CSS that hides any such manual reload/refresh link.
	#* Third, for profile pages which neither link to themselves as part of their design, nor have any live/updating content, the author can include an empty hyperlink with an empty href attribute (which is resolved as a relative URL to the page itself) to provide an invisible hyperlink to the page itself which is thus both not typically clickable (since it takes up no space), nor has any content which could be erroneously read by a screen reader. E.g. <code><a class="url" href=""></a></code>. This authoring suggestion is probably good enough to handle this third, now perhaps rarest case, though it would be useful to to have some test cases that can be run in various browsers / assistive technologies to see what they do. Another (lengthier) suggestion would be to use [[value-class-pattern]] value-title technique, e.g.: <code><nowiki><span class="url"><span class="value-title" title="http://example.com/user/john"> </span></span></nowiki></code>.		#* Third, for profile pages which neither link to themselves as part of their design, nor have any live/updating content, the author can include an empty hyperlink with an empty href attribute (which is resolved as a relative URL to the page itself) to provide an invisible hyperlink to the page itself which is thus both not typically clickable (since it takes up no space), nor has any content which could be erroneously read by a screen reader. E.g. <code><a class="url" href=""></a></code>. This authoring suggestion is probably good enough to handle this third, now perhaps rarest case, though it would be useful to to have some test cases that can be run in various browsers / assistive technologies to see what they do. Another (lengthier) suggestion would be to use [[value-class-pattern]] value-title technique, e.g.: <code><nowiki><span class="url"><span class="value-title" title="http://example.com/user/john"> </span></span></nowiki></code>.

			* 2006-11-16 raised by [[User:AndyMabbett\|Andy Mabbett]]
			*# ''The "type" for "tel" lacks a "textphone" option (for the devices used by, e.g., people who are deaf or have speech difficulties. Example: [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)].''
			#A: REJECTED. This is a vCard issue, as the "type" taxonomy for "tel" is determined by vCard. We are not presently extending hCard beyond the properties and values in vCard.
			#* ''I'm not clear how you can "reject" a provably factual statement. What's the process of suggesting an update to vCard? [[User:AndyMabbett\|Andy Mabbett]]''
			#**A: ACCEPTED PARTIAL RESOLVED. Unfortunately it is not clear what the process is for updating vCard. However, we can at least capture suggestions for improvement to vCard from this community which may be helpful once the process for updating vCard is understood. I've created [[vcard-suggestions]] for this purpose and added this suggestion. - Tantek
			#*** The vCard spec is updated by RFC, for example [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770]. [[User:AndyMabbett\|Andy Mabbett]] 06:22, 12 Jan 2007 (PST)
			#**** A: COLLECTED AND CLOSED. The suggestion has been documented in [[vcard-suggestions]] and it's now up to vCard 4 to see it is adopted or not. If it is, then hCard 1.1 can consider adding it.

	=== closed 2007 ===		=== closed 2007 ===

Tantek: /* closed 2006 */ close issue 2006-10-21 with completion of hcard-authoring addition

2009-11-10T06:50:57Z

closed 2006: close issue 2006-10-21 with completion of hcard-authoring addition

@@ Line 181: / Line 181: @@
 *#** [[process#Document_Current_Behavior|process: Document Current Behavior]]
 *#** [[process-faq#Where_are_the_real-world_publishing_examples_and_analysis_of_properties_implied_in_hCard_and_hCalendar|process FAQ: on hCard on hCalendar]]
 === closed 2007 ===

Tantek: /* closed 2006 */ close issue 2006-04-10 with additional documentation.

2009-11-10T03:21:53Z

closed 2006: close issue 2006-04-10 with additional documentation.

← Older revision		Revision as of 03:21, 10 November 2009
Line 150:		Line 150:
	*# ''Few systems contemplate the altitude component of a coordinate, yet it exists. Altitude becomes important when working with 3D mapping software such as Google Earth. Indeed, the geocoding service that Google Earth uses returns a three-dimensional coordinate. I suggest that hCard provide explicit support for altitude.''		*# ''Few systems contemplate the altitude component of a coordinate, yet it exists. Altitude becomes important when working with 3D mapping software such as Google Earth. Indeed, the geocoding service that Google Earth uses returns a three-dimensional coordinate. I suggest that hCard provide explicit support for altitude.''
	# REJECTED POSTPONED. Not in vCard. There is no "altitude" component in vCard (RFC 2426), and thus (certainly for now) there won't be any in hCard. If a new version of vCard were to come out with altitude, then we would add it to hCard. At some point we may also consider adding explicit extensions beyond vCard, but if we were to do so, we would capture them first on the [[hcard-brainstorming]] page. See [[vcard-suggestions#Elevation\|vCard suggestions: elevation]], and [[geo-extension-elevation]].		# REJECTED POSTPONED. Not in vCard. There is no "altitude" component in vCard (RFC 2426), and thus (certainly for now) there won't be any in hCard. If a new version of vCard were to come out with altitude, then we would add it to hCard. At some point we may also consider adding explicit extensions beyond vCard, but if we were to do so, we would capture them first on the [[hcard-brainstorming]] page. See [[vcard-suggestions#Elevation\|vCard suggestions: elevation]], and [[geo-extension-elevation]].


	* 2006-02-19 raised by Miika Mäkinen.		* 2006-02-19 raised by Miika Mäkinen.
	*# ''Couldn't the types for tel numbers be specified in a class? Now, for a phone number one needs to add the type as "visible" text, which is not always preferred. For example, type "Work", many times more suitable label could be "Office" or similar and sometimes you might not want to display any type information at all.''		*# ''Couldn't the types for tel numbers be specified in a class? Now, for a phone number one needs to add the type as "visible" text, which is not always preferred. For example, type "Work", many times more suitable label could be "Office" or similar and sometimes you might not want to display any type information at all.''
	# REJECTED TRIED ALREADY. Using class names for the "type" of a tel or adr [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was attempted], and failed in many situations. In addition, the "type" information is actual data, not just a property name, and thus deserves to be in the ''visible'' markup. Note that you can use abbreviations, e.g. <code><nowiki><abbr class="type" title="work">W:</abbr></nowiki></code> in order to present the type in a way that may better fit in with the rest of your presentation. Update (2009-312) see also the [[value-class-pattern]] for how to provide tel 'type' information with other labels. - [[User:Tantek\|Tantek]] 05:11, 9 November 2009 (UTC)		# REJECTED TRIED ALREADY. Using class names for the "type" of a tel or adr [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was attempted], and failed in many situations. In addition, the "type" information is actual data, not just a property name, and thus deserves to be in the ''visible'' markup. Note that you can use abbreviations, e.g. <code><nowiki><abbr class="type" title="work">W:</abbr></nowiki></code> in order to present the type in a way that may better fit in with the rest of your presentation. Update (2009-312) see also the [[value-class-pattern]] for how to provide tel 'type' information with other labels. - [[User:Tantek\|Tantek]] 05:11, 9 November 2009 (UTC)


	* 2006-02-23 raised by [http://www.thefutureoftheweb.com/ Jesse Skinner] and [http://www.thefutureoftheweb.com/blog/2006/1/hcard#comment1 Ben Buchanan].		* 2006-02-23 raised by [http://www.thefutureoftheweb.com/ Jesse Skinner] and [http://www.thefutureoftheweb.com/blog/2006/1/hcard#comment1 Ben Buchanan].
Line 159:		Line 161:
	# RESOLVED FAQ: Multiple URLs are allowed. Some consuming agents (Apple's AddressBook.app among them) don't have an interface for producing multiple URLs, but they are still valid in vCard and therefore hCard. --[[User:RyanKing\|RyanKing]] 17:58, 12 Jun 2006 (PDT)		# RESOLVED FAQ: Multiple URLs are allowed. Some consuming agents (Apple's AddressBook.app among them) don't have an interface for producing multiple URLs, but they are still valid in vCard and therefore hCard. --[[User:RyanKing\|RyanKing]] 17:58, 12 Jun 2006 (PDT)
	# FAQ documented: [[hcard-faq#Can_an_hCard_have_multiple_URLs\|hCard FAQ: can an hCard have multiple URLs]]		# FAQ documented: [[hcard-faq#Can_an_hCard_have_multiple_URLs\|hCard FAQ: can an hCard have multiple URLs]]


	* 2006-03-07 raised by [http://tantek.com Tantek].		* 2006-03-07 raised by [http://tantek.com Tantek].
Line 165:		Line 168:
	#* [http://www.vanderwal.net/ Thomas Vander Wal]		#* [http://www.vanderwal.net/ Thomas Vander Wal]
	#* [http://hajollyha.net/ Amy van der Hiel]		#* [http://hajollyha.net/ Amy van der Hiel]


	* 2006-04-06 raised by [[User:Evan\|Evan]].		* 2006-04-06 raised by [[User:Evan\|Evan]].
Line 170:		Line 174:
	# ACCEPTED. Categories can optionally be represented as tags. The classname 'category' should always be used, but rel="tag" can optionally be used (in addition to the category classname). In the case that a rel-tag tag is used, the tag (as defined by [[rel-tag]]) is used for the category. Examples: (1) <code><nowiki><span class="category">food</span></nowiki></code> and (2) <code><nowiki><a class="category" rel="tag" href="http://example.com/food">Food!</a></nowiki></code>. --[[User:RyanKing\|RyanKing]] 15:16, 13 Jun 2006 (PDT)		# ACCEPTED. Categories can optionally be represented as tags. The classname 'category' should always be used, but rel="tag" can optionally be used (in addition to the category classname). In the case that a rel-tag tag is used, the tag (as defined by [[rel-tag]]) is used for the category. Examples: (1) <code><nowiki><span class="category">food</span></nowiki></code> and (2) <code><nowiki><a class="category" rel="tag" href="http://example.com/food">Food!</a></nowiki></code>. --[[User:RyanKing\|RyanKing]] 15:16, 13 Jun 2006 (PDT)
	# FAQ: [[hcard-faq#How_are_category_and_rel-tag_related\|hCard FAQ: How are category and rel-tag related]]		# FAQ: [[hcard-faq#How_are_category_and_rel-tag_related\|hCard FAQ: How are category and rel-tag related]]


			* 2006-04-10 raised by [[User:ScottReynen\|Scott Reynen]].
			*# ''When someone looks at the [[hcard\|hCard]] pages, one sees no collection of real-world publishing of contact data nor discussion of the properties implied by such examples, I think it's far too easy to infer that microformats come from other formats more than actual behavior. There's nothing on the [[process]] nor the hCard pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places.''
			# ACCEPTED. Agreed. Part of this is now documented in [[hcard-design-methodology]], but to do: document additional specifics in the [[process]] and [[process-faq]] accordingly. - Tantek. 2009-313 Update by [[User:Tantek\|Tantek]] 03:21, 10 November 2009 (UTC) - wrote up additional specifics in:
			#* [[process#Document_Current_Behavior\|process: Document Current Behavior]]
			#* [[process-faq#Where_are_the_real-world_publishing_examples_and_analysis_of_properties_implied_in_hCard_and_hCalendar\|process FAQ: on hCard on hCalendar]]

	=== closed 2007 ===		=== closed 2007 ===

Tantek: /* closed 2006 */ close issue from 2006-02-23, 2006-03-07, 2006-04-06

2009-11-09T05:45:10Z

closed 2006: close issue from 2006-02-23, 2006-03-07, 2006-04-06

@@ Line 154: / Line 154: @@
 *# ''Couldn't the types for tel numbers be specified in a class? Now, for a phone number one needs to add the type as "visible" text, which is not always preferred. For example, type "Work", many times more suitable label could be "Office" or similar and sometimes you might not want to display any type information at all.''
 *#* REJECTED TRIED ALREADY. Using class names for the "type" of a tel or adr [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was attempted], and failed in many situations. In addition, the "type" information is actual data, not just a property name, and thus deserves to be in the ''visible'' markup. Note that you can use abbreviations, e.g. <code><nowiki><abbr class="type" title="work">W:</abbr></nowiki></code> in order to present the type in a way that may better fit in with the rest of your presentation. Update (2009-312) see also the [[value-class-pattern]] for how to provide tel 'type' information with other labels. - [[User:Tantek|Tantek]] 05:11, 9 November 2009 (UTC)
 === closed 2007 ===

Tantek: /* closed 2006 */ closed issue from 2006-02-19

2009-11-09T05:11:02Z

closed 2006: closed issue from 2006-02-19

← Older revision		Revision as of 05:11, 9 November 2009
Line 150:		Line 150:
	*# ''Few systems contemplate the altitude component of a coordinate, yet it exists. Altitude becomes important when working with 3D mapping software such as Google Earth. Indeed, the geocoding service that Google Earth uses returns a three-dimensional coordinate. I suggest that hCard provide explicit support for altitude.''		*# ''Few systems contemplate the altitude component of a coordinate, yet it exists. Altitude becomes important when working with 3D mapping software such as Google Earth. Indeed, the geocoding service that Google Earth uses returns a three-dimensional coordinate. I suggest that hCard provide explicit support for altitude.''
	# REJECTED POSTPONED. Not in vCard. There is no "altitude" component in vCard (RFC 2426), and thus (certainly for now) there won't be any in hCard. If a new version of vCard were to come out with altitude, then we would add it to hCard. At some point we may also consider adding explicit extensions beyond vCard, but if we were to do so, we would capture them first on the [[hcard-brainstorming]] page. See [[vcard-suggestions#Elevation\|vCard suggestions: elevation]], and [[geo-extension-elevation]].		# REJECTED POSTPONED. Not in vCard. There is no "altitude" component in vCard (RFC 2426), and thus (certainly for now) there won't be any in hCard. If a new version of vCard were to come out with altitude, then we would add it to hCard. At some point we may also consider adding explicit extensions beyond vCard, but if we were to do so, we would capture them first on the [[hcard-brainstorming]] page. See [[vcard-suggestions#Elevation\|vCard suggestions: elevation]], and [[geo-extension-elevation]].

			* 2006-02-19 raised by Miika Mäkinen.
			*# ''Couldn't the types for tel numbers be specified in a class? Now, for a phone number one needs to add the type as "visible" text, which is not always preferred. For example, type "Work", many times more suitable label could be "Office" or similar and sometimes you might not want to display any type information at all.''
			# REJECTED TRIED ALREADY. Using class names for the "type" of a tel or adr [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was attempted], and failed in many situations. In addition, the "type" information is actual data, not just a property name, and thus deserves to be in the ''visible'' markup. Note that you can use abbreviations, e.g. <code><nowiki><abbr class="type" title="work">W:</abbr></nowiki></code> in order to present the type in a way that may better fit in with the rest of your presentation. Update (2009-312) see also the [[value-class-pattern]] for how to provide tel 'type' information with other labels. - [[User:Tantek\|Tantek]] 05:11, 9 November 2009 (UTC)

	=== closed 2007 ===		=== closed 2007 ===