[Bug 18022] New: i18n-ISSUE-105: compatibility caseless matching


           Summary: i18n-ISSUE-105: compatibility caseless matching
           Product: HTML WG
           Version: unspecified
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P3
         Component: other Hixie drafts (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: contributor@whatwg.org
         QAContact: contributor@whatwg.org
                CC: ian@hixie.ch, mike@w3.org, annevk@annevk.nl,

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

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.

Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Wednesday, 18 July 2012 15:42:02 UTC