- From: <bugzilla@jessica.w3.org>
- Date: Thu, 17 Jan 2013 07:48:52 +0000
- To: public-i18n-core@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16970
John Daggett <jdaggett@mozilla.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
URL| |http://people.mozilla.org/~
| |jdaggett/tests/radiobuttonn
| |amecase.html
CC| |jdaggett@mozilla.com
Resolution|WONTFIX |---
--- Comment #5 from John Daggett <jdaggett@mozilla.com> ---
(In reply to comment #4)
> Rationale: Unfortunately, compatibility caseless matching is necessary
> for compat with the extant Web corpus.
Actually, this isn't implemented consistently at all across user agents. I've
included a link to a testcase for radio button groups. Webkit browsers do a
case-sensitive match, Opera and Firefox do some sort of adhoc Unicode case
sensitive match (i.e. they don't completely match), while IE8/IE9 use an
OS-level compare function that does some normalization and some case handling.
But *none* of these actually use the default compatibility caseless match
algorithm described in the Unicode spec.
While it's certainly better that the spec requires an explicit Unicode-defined
algorithm, I'm not sure it's worth the effort. How much content in the real
world is actually using a variety of string forms across inputs, some with
diacritics, some with precomposed characters?!?
Since this effectively introduces a *new* casing algorithm into all browsers
(even IE which is clearly using a Windows platform string matching function
since results vary across Windows versions, WinXP vs. Win7), I think more
effort should be put into determining whether there's actually content that
requires *any* form of case insensitive matching. If there isn't, specify case
sensitive matching. If there is, then would Unicode caseless matching (with
*no* normalization) be better?
--
You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 17 January 2013 07:48:53 UTC