- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Mon, 30 May 2011 03:00:03 +0200
- To: www-validator@w3.org, www-international@w3.org
Leif Halvard Silli, Mon, 30 May 2011 02:06:19 +0200: > Clearly, HTML5 and the HTML5 validator should help authors avoid > gotchas. But, when thinking trouch some scenarios, it seems to be > difficult to give the right kind of warning/advice in a validator. > > Example: > > * For the Apache2 version that comes with Mac OS X, one might in > principle use composed as well as decomposed links even if the file > names are decomposed. In Apache on Mac OS X, there is, however, a > single problem: cool, composed IRIs. E.g. > <http://example.com/%C3%A5.html> works, while > <http://example.com/%C3%A5> does not work. May be this is an Apache > bug. > * In order to fix the above problem, which also lead customers to react > when files were placed online, I started to use decomposed links: > <http://example.com/a%CC%8A> 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. * in case of a de-composed cool IRI, it will not work at all. This is probably because Safari for Windows normalizes the cool IRI first: As already told, cool IRI is do not seem to work (whenever they contain decomposed letters). So, may be Safari on Windows shows why normalization must be handled with care ... -- Leif Halvard Silli
Received on Monday, 30 May 2011 01:01:35 UTC