- From: <bugzilla@jessica.w3.org>
- Date: Mon, 07 May 2012 17:42:11 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16970
Summary: i18n-ISSUE-105: compatibility caseless matching
Product: HTML WG
Version: unspecified
Platform: PC
OS/Version: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: HTML5 spec (editor: Ian Hickson)
AssignedTo: ian@hixie.ch
ReportedBy: addison@lab126.com
QAContact: public-html-bugzilla@w3.org
CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
public-html@w3.org
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).
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 7 May 2012 17:42:14 UTC