18022 2012-07-18 15:41:54 +0000 i18n-ISSUE-105: compatibility caseless matching 2012-10-01 22:34:10 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WONTFIX P3 normal Unsorted 1 contributor ian addison annevk ian mike public-i18n-core contributor oldest_to_newest 70512 0 contributor 2012-07-18 15:41:54 +0000 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. ================================================================================ 74986 1 ian 2012-10-01 22:34:10 +0000 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.