RE: HTML5 and Unicode Normalization Form C

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