- From: <bugzilla@jessica.w3.org>
- Date: Mon, 24 Feb 2014 18:11:00 +0000
- To: public-i18n-core@w3.org
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 on the CC list for the bug.
Received on Monday, 24 February 2014 18:11:05 UTC