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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18022

           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,
                    public-i18n-core@w3.org


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.
================================================================================

-- 
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