- From: <bugzilla@jessica.w3.org>
- Date: Wed, 12 Feb 2014 03:49:04 +0000
- To: public-i18n-core@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16970 --- Comment #8 from Addison Phillips <addison@lab126.com> --- Thanks John. I think I18N would be quite unhappy with ASCII case-insensitive (ACI) in this case. I know I am unhappy with it. While you are probably correct about the limitations on having actually functional legacy pages, we must *also* think about all of the future page authors affected by our choices. Applying ACI to a Unicode namespace leads to fairly odious usability problems. The example you'll recall from before is: GREEN matches green, but... GRÜN doesn't match grün, while... GRüN matches grün (usw) Users of non-ASCII scripts (replace above with a Cyrillic example) are discomfited by "features" of HTML5 that ignore the identifiers that they find most natural. Now, in this case, we have a set of *general* definitions for matching in HTML5 that is then used in *specific* cases (radio buttons are one such). If we are going to define a caseless matching for non-ASCII namespaces that existing HTML5, I think that ACI is not the way to go. We can define a single, straight-forward caseless matching that does not involve Unicode Normalization or language-specific tailoring. This is explainable, understandable, consistent, and compatible with the original *intent*. We might, separately, decide to apply different matching schemes to specific items. However, for Unicode namespaces, applying an "ASCII-only" caseless match seems restrictive on future authors in ways that are unnecessary. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Wednesday, 12 February 2014 03:49:06 UTC