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


--- 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

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