This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 16970 as part of operation convergence. Originally filed: 2012-05-07 17:42:00 +0000 Original reporter: Addison Phillips <addison@lab126.com> ================================================================================ #0 Addison Phillips 2012-05-07 17:42:10 +0000 -------------------------------------------------------------------------------- 2.3 Case-sensitivity and string comparison http://www.w3.org/TR/html5/infrastructure.html#case-sensitivity-and-string-comparison -- Comparing two strings in a compatibility caseless manner means using the Unicode compatibility caseless match operation to compare the two strings. -- a. The specific reference to compatibility caseless matching should be provided (D146 in chapter 3). b. I am unsure that compatibility caseless matching is desirable. It is only used twice in the whole document that I can find: 2.5.9 (hashname reference value matching) 4.10.7.1.17 (radio button name attribute matching) In both cases, name attributes defined in the document are being matched. I think that compatibility decomposition in the matching operation would be a surprise to users, who might expect, for example, these to be separate values: ①⑴⒈. More to the point, the Korean Hangul script has a complex relationship with compatibility decomposition. I18N would suggest replacing compatibility caseless matching with canonical caseless matching. c. It seems that this might be a stab at making 'name' attributes into 'identifiers', in which case compatibility decomposition is to be desired, with identifier caseless matching (which does use compatibility normalization but is slightly simpler). ================================================================================ #1 Anne 2012-05-08 18:41:30 +0000 -------------------------------------------------------------------------------- Did you test implementations? What we really wanted was ASCII case-insensitive everywhere, but that was not possible because implementations did something else. I forgot to what length this was tested though. ================================================================================ #2 Ian 'Hixie' Hickson 2012-05-10 17:50:58 +0000 -------------------------------------------------------------------------------- Please file only one issue per bug report. ================================================================================
a. Click on the term to get a list of references. b. It's definitely not desirable. When it comes to back-compat, that's not really one of the things that we consider, sadly. c. Not sure what this means.