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