- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 15 Jul 2009 09:25:32 +0000
- To: public-html@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6746
Nick Levinson <Nick_Levinson@yahoo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
Status|RESOLVED |REOPENED
Resolution|WONTFIX |
--- Comment #16 from Nick Levinson <Nick_Levinson@yahoo.com> 2009-07-15 09:25:31 ---
I've identified where the need lies and provide a proposal.
Enumerated attributes' values must be case-insensitive under section 2.4.3.
Enumerated attributes exist for:
--- the input element's type attribute's radio keyword, for radio buttons
(section 4.10.4), which I assume is to itemize a list of radio buttons in a
single group, so that each radio button may have a name that could be drawn
from any natural language and therefore in non-ASCII characters to suit
non-English Internet website users;
--- the meta element's name attribute (sec. 4.2.5), for which only a few names
are already defined, others being registrable as extensions (sec. 4.2.5.2), an
important use of which is to support search engines including engines in many
non-English-speaking nations, some of which may prioritize their own criteria
for ranking consistent with local needs, so that website owners, especially for
non-English websites, should consider what non-U.S. search engines might seek
for meta tags' name-content pairs, including names being spelled with non-Roman
characters (this proposal being to provide early infrastructural support for
future meta tags when they're registered); and
--- some other elements which are not very important for this issue, because
they are for attributes already fully named and listed, their names all spelled
within ASCII.
Proposal:
--- Amend sec. 2.3:
--- --- to duplicate the third paragraph but with "ASCII" absent from the
phrase "ASCII case-insensitivity" so it reads "case-insensitivity" in the
otherwise-duplicate paragraph; and
--- --- to specify more character pairs, the same additional pairs in each
paragraph of that section (if this concept is accepted, the list of additional
pairs can be agreed on and inserted later), with the result that the paragraphs
to thus get more character pairs are the new paragraph and the paragraphs
beginning "Converting a string to uppercase . . . ." and "Converting a string
to lowercase . . . .".
--- Amend sec. 4.2.5.2, under the heading "Keyword", to replace "differing only
in case" (which is discouraged) with "it should be case-insensitive" (same
meaning). (To restate this change: edit "The name should not be confusingly
similar to any other defined name (e.g. differing only in case)." to "The name
should not be confusingly similar to any other defined name (e.g., it should be
case-insensitive)." (also adding a comma expected in English syntax).)
--- Review secs. 4.10.4 for the table of the type attribute's keywords (see the
data type for the keyword "radio") and 4.10.4.1.16 regarding radio buttons. I'm
not familiar with Unicode compatibility caselessness. If case-sensitivity is
acceptable for radio button names, no change is proposed. If case-insensitivity
is needed, then add a sentence somewhere that reads something like "An
attribute value for a button name must be a case-insensitive match to its
keyword.".
--- Amend sec. 2.4.3, the paragraph beginning "If an enumerated attribute is
specified . . . .", to add "or a case-insensitive match" so that the middle of
the sentence reads ". . . the attribute's value must be an ASCII
case-insensitive match or a case-insensitive match for one of the given
keywords . . . .".
--- Later, add specific character pairs based on case-pairing.
(The citations refer to the W3C Working Draft 23 April 2009 single-page file.)
Thanks.
--
Nick
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Wednesday, 15 July 2009 09:25:42 UTC