W3C home > Mailing lists > Public > www-international@w3.org > April to June 2011

Re: HTML5 and Unicode Normalization Form C

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Mon, 30 May 2011 04:38:57 +0200
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: www-international@w3.org
Message-ID: <20110530043857480225.cb59a8af@xn--mlform-iua.no>
Bjoern Hoehrmann, Mon, 30 May 2011 03:16:02 +0200:
> * Leif Halvard Silli wrote:
>> Just discoverd, though, that Safari on Windows (but not on Mac) handles 
>> decomposed values in a unique way:
>> 
>> * in case of a de-composed fragment link, then Safari on Windows will 
>> target the composed identifier. If there is no composed identifier, 
>> then it will target nothing. Chrome, Safari-on-Mac and "all other" 
>> browsers treat them differently.
> 
> There has never been much consistency in this area as far as I am aware,
> e.g. <http://lists.w3.org/Archives/Public/www-html/2002Oct/0002.html>.

Those test results are of course interesting. A retest where you looked 
at today's browsers would be interesting too!

But nevertheless, that test is not completely relevant to the issue at 
hand. HTML5 says that URLs are to be resolved in accordance with the 
encoding. And HTML5 does not say that de-composed and composed values 
should be treated equally either.

The tests I have performed are not experiments where I try to test 
whether values that should (or should not) be seen as equal really are 
seen as equal, with the goal of discovering as many bugs as possible. 
Instead, I accept how UAs treat NFC and NFD differently. (I all started 
when I tried to discover why on earth links that worked find on my mac 
did not work elsewhere.)

Safari on Windows is an odd exception, even in the Webkit family. I 
mentioned it only because (I think) it sheds some light on other issues 
that I meanted. It is, as well, an example of how using NFC really 
*can* improve browser compatibility.
-- 
Leif H Silli
Received on Monday, 30 May 2011 02:39:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 May 2011 02:39:27 GMT