On Wed, 1 Oct 2003 01:35:37 +0100, "Richard Cornford"
<Ri*****@litote s.demon.co.uk> wrote:
"Andy Hassall" <an**@andyh.co. uk> wrote in message
news:n6******* *************** **********@4ax. com... On Wed, 1 Oct 2003 01:02:33 +0200, "VK" <sc**********@y ahoo.com>wrote:
<snip>Any name has to start with a letter and consist of any
combinatio n of letters, numbers and underscores to the
total length of 255 characters. (Where the "letter" means
any character from the a-z, A-Z range)
Not true, see below.
<snip>
The message linked says [] in an input name is invalid, the
replies disprove this.
I don't think that the discussion that you referenced does prove the
general suggestion that [ and ] are invalid in HTML 4 name attribute
strings is incorrect. If I look at the HTM versions of the DTDs I find
that the Name attributes are described as CDATA and the term CDATA is
linked to:-
<quote cite="http://www.w3.org/TR/html4/types.html#type-cdata">
...
For some HTML 4 attributes with CDATA attribute values, the
specificatio n imposes further constraints on the set of legal values for
the attribute that may not be expressed by the DTD.
...
ID and NAME tokens must begin with a letter ([A-Za-z]) and may be
followed by any number of letters, digits ([0-9]), hyphens ("-"),
underscores ("_"), colons (":"), and periods (".").
The name attribute of input is not one of the ID or NAME types, so that
restriction doesn't apply.
There are attributes that are declared as ID or NAME; input's name attribute
is not one of them.
...
</quote>
- which is part of the HTML 4 specification and "imposes further
constraints" on the contents of name attribute strings beyond the normal
definition of CDATA.
No, the restriction on the NAME and ID types don't apply to the CDATA type.
Quoting the whole lot:
"
* CDATA is a sequence of characters from the document character set and may
include character entities. User agents should interpret attribute values as
follows:
Replace character entities with characters,
Ignore line feeds,
Replace each carriage return or tab with a single space.
User agents may ignore leading and trailing white space in CDATA attribute
values (e.g., " myval " may be interpreted as "myval"). Authors should not
declare attribute values with leading or trailing white space.
For some HTML 4 attributes with CDATA attribute values, the specification
imposes further constraints on the set of legal values for the attribute that
may not be expressed by the DTD.
Although the STYLE and SCRIPT elements use CDATA for their data model, for
these elements, CDATA must be handled differently by user agents. Markup and
entities must be treated as raw text and passed to the application as is. The
first occurrence of the character sequence "</" (end-tag open delimiter) is
treated as terminating the end of the element's content. In valid documents,
this would be the end tag for the element.
* ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by
any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons
(":"), and periods (".").
* IDREF and IDREFS are references to ID tokens defined by other attributes.
IDREF is a single token and IDREFS is a space-separated list of tokens.
* NUMBER tokens must contain at least one digit ([0-9]).
"
So, it's saying that if you look through the specification on some of the
attributes that are of CDATA type, there are then further notes on restrictions
not expressed by it being of type CDATA.
There are no further restrictions listed for input's name attribute that I can
find - if you can see one please post it!
There then follows descriptions of the ID, NAME, IDREF, IDREFS and NUMBER
types; none of which are CDATA, they're separate types.
For example:
http://www.w3.org/TR/html4/struct/li...ml#adef-name-A
The name attribute of the <a> tag is of type CDATA, but it says here that it
is restricted to the namespace of the id attribute, which is of type 'name'.
That's a "further constraint on the set of legal values for the attribute that
may not be expressed by the DTD"
Individual languages may have trouble with non-alphabetic
characters as part of a name attribute, but it's valid HTML
and so should really be possible to deal with it in any
language working with HTML.
Valid HTML or not, JavaScript can access properties with names that do
not represent valid identifiers in JavaScript by using square bracket
notation instead of dot notation:-
<URL: http://jibbering.com/faq/#FAQ4_25 >
-and-
<URL: http://jibbering.com/faq/#FAQ4_39 >
Sounds good.
--
Andy Hassall (an**@andyh.co. uk) icq(5747695) (
http://www.andyh.co.uk)
Space: disk usage analysis tool (
http://www.andyhsoftware.co.uk/space)
