This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 18022 - i18n-ISSUE-105: compatibility caseless matching
Summary: i18n-ISSUE-105: compatibility caseless matching
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
Depends on:
Reported: 2012-07-18 15:41 UTC by contributor
Modified: 2012-10-01 22:34 UTC (History)
5 users (show)

See Also:


Description contributor 2012-07-18 15:41:54 UTC
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 <>

 #0   Addison Phillips                                2012-05-07 17:42:10 +0000 
2.3 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) (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.
Comment 1 Ian 'Hixie' Hickson 2012-10-01 22:34:10 UTC
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.