[Bug 12839] @id: Define how Unicode normalization affects the 'unique identifier' status

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12839

--- Comment #6 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-06-01 23:57:23 UTC ---
(In reply to comment #4)

Regarding NFC normalization:

> I can almost guarantee you that getElementById(), CSS selectors, etc. operate
> on sequences of 16-bit code points without normalization, so making the
> conformance requirement for id different doesn't sound like a good idea.

YES! UAs behave like that. But should it be *valid* for authors to behave like
that? 
NO! Validator.nu and Validator.w3.org do not behave like that - they perform
unicode normalization. To verity that validators perform normalization, paste
this code into Validator.nu or Validator.w3.org [crossing the fingers that
neither Bugzilla or anything normalize anything]:

<!DOCTYPE html><title>I</title><p title="a&#x30a;" id="å">NFD<p title="&#xe5;"
id="å" >NFC

If it the spec would say that the @id-s of the above p-elements are *unique*,
then it should probably be considered a *bug* in the validators that they
normalize the @id values before they compare the strings!

(Unfortunately, the validators have a bug: if you replace the directly typed
letters with character references, then they do not  perform normalization
anymore. E.g. try pasting this into the validator instead: <!DOCTYPE
html><title>I</title><p title="a&#x30a;" id="a&#x30a;">NFD<p title="&#xe5;"
id="&#xe5;" >NFC )

Conclusion: 
  EITHER: the spec should take normalization into the validity definition of
@id - such a solution opens for the posibility of differentiating between
"unique" from "valid".
        OR: the spec should *point out* that  normalization does not matter
w.r.t.  validity  - and also does not matter w.r.t. uniqueness.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 1 June 2011 23:57:27 UTC