hcard-issues - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:26:30Z

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

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

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

Tantek: Reverted edits by ABIDEEN10 (Talk) to last version by Tantek

2013-04-07T04:59:12Z

Reverted edits by ABIDEEN10 (Talk) to last version by Tantek

Show changes

ABIDEEN10 at 02:29, 7 April 2013

2013-04-07T02:29:56Z

Show changes

Tantek: Protected "hcard-issues" [edit=autoconfirmed:move=sysop]

2013-04-04T00:52:11Z

Protected "hcard-issues" [edit=autoconfirmed:move=sysop]

← Older revision	Revision as of 00:52, 4 April 2013
(No difference)

Tantek: Reverted edits by ABIDEEN1 (Talk) to last version by Tantek

2013-04-04T00:48:06Z

Reverted edits by ABIDEEN1 (Talk) to last version by Tantek

Show changes

ABIDEEN1 at 00:14, 4 April 2013

2013-04-04T00:14:02Z

Show changes

Tantek: auto-toc, no issues raised in 2010, none so far in 2011

2011-10-26T23:57:29Z

auto-toc, no issues raised in 2010, none so far in 2011

← Older revision		Revision as of 23:57, 26 October 2011
Line 1:		Line 1:
	<entry-title> hCard issues </entry-title>		<entry-title> hCard issues </entry-title>
	~~__TOC__~~
	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.		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.

Line 19:		Line 19:

	===2010===		===2010===
			* none.
	* none currently		===2011===
			* none currently.

	== template ==		== template ==

Tantek: /* 2010 */ resolve one outstanding issue and move to hcard-issues-resolved

2010-04-16T00:23:10Z

2010: resolve one outstanding issue and move to hcard-issues-resolved

← Older revision		Revision as of 00:23, 16 April 2010
Line 20:		Line 20:
	===2010===		===2010===

	~~<div class="hentry">~~		* none currently
	~~{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2010-02-03</span> raised by <span class="fn">[http://foolip.org/ Philip Jägenstedt]</span></span>~~
	~~<div class="entry-content discussion issues">~~
	* <strong class="entry-title">Implied "n" Optimization</strong>. The [[hcard#Implied_.22n.22_Optimization\|hCard spec]] and the derived [http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#conversion-to-vcard microdata vCard spec] has some magic intended to derive N from FN when it is not given explicitly, as N is required by the vCard spec. The guessing employed will fail for at least Vietnamese names (e.g. Phương Thanh => N:Thanh;Phương;;;), Chinese names (e.g. 冯小刚 => N:;冯小刚;; and Feng Xiaogang => N:Xiaogang;Feng;;;) and Japanese/Korean names for the same reasons. The problem is both that family-name and given-name are reversed and that Chinese is written without space, so the whole name is interpreted as family name. If the only issue is that N is mandatory, simply outputting N:;;;; seems the safest. Although it's technically possible to add markup to avoid the guessing, that's not going to be an option when microdata/microformats are used in a template and the user isn't asked for both the full name and all of its components. This issue was previously raised on [http://microformats.org/discuss/mail/microformats-discuss/2010-February/013187.html microformats-discuss].
	~~</div>~~
	~~</div>~~

	== template ==		== template ==

Foolip: /* 2009 */ Implied "n" Optimization

2010-02-03T09:35:31Z

2009: Implied "n" Optimization

← Older revision		Revision as of 09:35, 3 February 2010
Line 18:		Line 18:
	<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.		<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.

	===~~2009~~===		===2010===

	* ... ~~none currently~~		<div class="hentry">
			{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2010-02-03</span> raised by <span class="fn">[http://foolip.org/ Philip Jägenstedt]</span></span>
			<div class="entry-content discussion issues">
			* <strong class="entry-title">Implied "n" Optimization</strong>. The [[hcard#Implied_.22n.22_Optimization\|hCard spec]] and the derived [http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#conversion-to-vcard microdata vCard spec] has some magic intended to derive N from FN when it is not given explicitly, as N is required by the vCard spec. The guessing employed will fail for at least Vietnamese names (e.g. Phương Thanh => N:Thanh;Phương;;;), Chinese names (e.g. 冯小刚 => N:;冯小刚;; and Feng Xiaogang => N:Xiaogang;Feng;;;) and Japanese/Korean names for the same reasons. The problem is both that family-name and given-name are reversed and that Chinese is written without space, so the whole name is interpreted as family name. If the only issue is that N is mandatory, simply outputting N:;;;; seems the safest. Although it's technically possible to add markup to avoid the guessing, that's not going to be an option when microdata/microformats are used in a template and the user isn't asked for both the full name and all of its components. This issue was previously raised on [http://microformats.org/discuss/mail/microformats-discuss/2010-February/013187.html microformats-discuss].
			</div>
			</div>

	== template ==		== template ==

Tantek: /* 2009 */ resolved a recent issue

2009-10-09T08:58:00Z

2009: resolved a recent issue

← Older revision		Revision as of 08:58, 9 October 2009
Line 20:		Line 20:
	===2009===		===2009===

	~~<div class="hentry">~~		* ... none currently
	~~{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-09-10</span> raised by <span class="fn">[[User:TomMorris\|TomMorris]]</span></span>~~
	~~<div class="entry-content discussion issues">~~
	* ~~<strong class="entry-title">Parsing UTF-8 'special' space characters in telephone fields</strong>~~. ~~I recently designed a page that used an hCard with a <code>span</code> containing the <samp>tel</samp> value~~. ~~To space the phone number appropriately, I used the U+8201 (THIN SPACE) character <code>&#8201;</code>~~. [[operator\|Operator's]] hCard parser coughed up on this and refused to read both the contents of the <samp>tel</samp> <code>span</code> but also an <code>a</code> element containing the <samp>email</samp> property that was contained in the parent <code>p</code> element. I cannot find a clear definition of what is acceptable content for the <samp>tel</samp> 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 <code>&ensp;</code>, <code>&emsp;</code>, <code>&thinsp;</code> and <code>&nbsp;</code>) 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 [http://www.w3.org/TR/CSS21/text.html#spacing-props CSS <code>word-spacing</code> property] for manipulating <samp>tel</samp> 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 [http://www.ietf.org/rfc/rfc2426.txt RFC 2426] §3.3, which says that it should simply be the telephone format defined in X.500 ([http://www.ietf.org/rfc/rfc1274.txt RFC 1274]), but there is no explicit definition in X.500 except to say it is "telephoneNumberSyntax", which is defined in [http://www.ietf.org/rfc/rfc1778.txt 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?)
	~~</div>~~
	~~</div>~~

	== template ==		== template ==