- From: <bugzilla@jessica.w3.org>
- Date: Wed, 01 Jun 2011 23:57:25 +0000
- To: public-html-bugzilla@w3.org
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="å" id="å">NFD<p title="å"
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="å" id="å">NFD<p title="å"
id="å" >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