[Bug 16970] i18n-ISSUE-105: compatibility caseless matching

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

--- Comment #14 from Addison Phillips <addison@lab126.com> ---
In our most recent teleconference [1], the I18N WG discussed this issue
in-depth and, as a result, I have [I18N-ACTION-289] to split this bug between
the "radio button group" and "hash-name reference" bits. I'm going to comment
first and then create a subsidiary bug.

Re: [Comment 13], I agree that we want to remove the complexity of
compatibility caseless. It's way way too complicated and provides little if any
benefit (and some serious downside) for users. The I18N WG is wondering where
the specific use of compatibility caseless came from, since it doesn't appear
that browsers actually do this.

At the same time, I disagree that switching to ASCII case insensitive (ACI) is
a good idea without careful thought. The I18N WG recommends that, unless
required for compatibility purposes, case *sensitive* matching is the way to
go.

For radio button groups, where the @name matching seems to work for (some
flavor of) Unicode case folding, but compatibility decomposition never appears
to be applied or at least is applied haphazardly, it seems like switching to
Unicode C+F case folding would be the most straight forward response. It would
potentially break an unknown (but probably not vast) number of pages to go to
either ACI or (more vastly) case sensitive matching.

For hash-name references, I note that the current WHATWG version [2] specifies
exact (e.g. case sensitive) matching. And this appears to be what browsers
actually do, at least for fragment identifiers. I have not tested other
occurrences of hash-name reference, such as image maps, yet.

If radio-button groups are the *only* place where Unicode case insensitivity is
needed in the whole of HTML, my suspicion would be that using ACI there with an
appropriate health warning could be a viable approach, since radio buttons are
not by themselves a compelling reason for implementing and maintained a
different casefold match. If hash-name references (which are more widely used)
must remain case insensitive, then I would suggest incorporating UCI for both.

Assuming, for the moment, that we can remove case insensitivity from hash-name
reference, I would suggest the following actions here:

1. Remove all reference to "compatibility caseless"
2. Make hash-name reference case sensitive
3. Make radio button groups ASCII case insensitive (for compatibility) with a
health warning to use consistent case


[1] http://www.w3.org/2014/02/20-i18n-minutes.html#item05
[2] http://developers.whatwg.org/common-microsyntaxes.html#syntax-references

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 24 February 2014 18:11:05 UTC