"VK" <schools_ring@yahoo.com> wrote in message
news:3f7c8b04$0$19359$9b622d9e@news.freenet.de...[color=blue]
>09/30/03 Phil Powell posted his "Radio buttons do not
>appear checked" question.
>This question led to a long discussion about the naming rules
>applying to variables, objects, methods and properties in
>JavaScript/JScript and HTML/XML elements.
>Without trying to get famous :-) but thinking it would be
>interesting to others I decided to post the following summary:
>
>1. Variable names in JavaScript/JScript
>[ Here 'variable' means a name/value pair declared via the
>"var name = value" statement. ][/color]
<snip>[color=blue]
>ECMA-262, Edition 3 Final, paragraph 7.6 "Identifiers", my summary:
>
>Any variable name has to start with
>_ (underscore)
>$ (currency sign)
>a letter from [a-z][A-Z] range an Unicode letter in the
>form \uAABB (where AA and BB are hex values)
>
>This start can be followed by any combination of _, $,
>letters and numbers both in [a-z][A-Z] and \u form.[/color]
<snip>[color=blue]
>
>2. Names of objects on the page (HTML elements, form elements
>etc.) [ These names are set via "name" or "id" attributes
>inside tag] The rules for "name" and "id" are regulated by
>HTML specifications of W3 Consortium. The latest official
>release of HTML Specification can be obtained at
>
http://www.w3.org (this time for absolutely free!)
>
>HTML 4.01 Specification, paragraph 6.2, direct quote:
> 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 (".").
>(direct link
http://www.w3.org/TR/html401/types.html#h-6.2)[/color]
I was under the misguided impression that this paragraph from types.html
applied to HTML NAME attributes so it might be useful to clarify how
these restrictions do apply. There are two separate concepts here; NAME
and ID attributes and the NAME and ID "tokens" referred to in the
paragraph above. The HTML versions of the HTML 4 DTDs make the
relationship clear. For example:-
<!--============== Generic Attributes ====================-->
<!ENTITY % coreattrs
id ID #IMPLIED -- document-wide unique id --
...[color=blue]
>[/color]
- from the DTD defines the generic attribute - id - (lowercase) as
containing a string that conforms to the definition of the token - ID -
(uppercase) in types.html. This is clear because uppercase ID is a link
with href="../types.html#type-id" and the fragment identifier "#type-id"
is to be found in types.html in the paragraph quoted above. As a result
all HTML id attributes are restricted to the character set and sequence
described in that paragraph.
Similarly:-
<!ELEMENT META - O EMPTY -- generic metainformation -->
<!ATTLIST META
...
name NAME #IMPLIED -- metainformation name --
...[color=blue]
>[/color]
- associates the - name - (lowercase) attribute with the - NAME -
(uppercase) token and it links to href="../types.html#type-name", with
the "#type-name" fragment identifier also present in the above quoted
paragraph.
However:-
<!ELEMENT A - - (%inline;)* -(A) -- anchor -->
<!ATTLIST A
...
name CDATA #IMPLIED -- named link end --
...[color=blue]
>[/color]
- associates the - name - (lowercase) attribute with the - CDATA -
token. The CDATA link uses href="../types.html#type-cdata", and the
"#type-cdata" fragment identifier is to be found in types.html within
the LI element that precedes the LI element in which the above paragraph
appears. That means that the rules that apply to the contents of this
CDATA name attribute are specified by the preceding part of the HTML
specification and the comments about NAME and ID tokens do not apply to
it.
The majority of - name - attributes specified in the DTDs are associated
with the CDATA specification.
[color=blue]
>So these rules are much more strict than the ECMAScript rules.
>
>3. Identifier vs. Property confusion
>[ Special thanks to <Lasse Reichstein Nielsen> and <Richard
>Cornford> who spent their time and energy explaining it to me. ][/color]
But apparently still did not get across the important distinction
between ECMA Script Identifiers (to which the restrictions that you
quoted above do apply) and ECMA Script property names to which no
restrictions apply (according to the specification).
[color=blue]
>If you really want to, then sometimes you CAN give any
>imaginable name to any object.
>In IE for example you can create checkbox like this:
> <input type="checkbox" name="[:-)" value="0" checked>[/color]
And that one is valid HTML.
[color=blue]
>or a div:
><div id="^[:-) ]#">...</div>[/color]
But that one is not as the rules for the ID token apply to the id
attribute.
<snip>[color=blue]
>It happens because of the dual nature of the "name" and "id"
>attributes. From one side they are supposed to be the
>identifiers of the corresponding objects:[/color]
The values of the name an id attributes are not identifiers (in the
sense that ECMA Script defines Identifier), they will be used as
property names in the DOM but ECMA Script places no restrictions on
property names.
The ECMA Script definition of - Identifier - _only_ applies to ECMA
Script source code. It does not impact on the naming of properties in
the DOM (or any other ECMA Script objects).
<snip>[color=blue]
>So a good-hearted browser may say: "OK, it cannot be used as
>an identifier, but it's still a valid string value for a property,
>so let it be". I don't think it's right,[/color]
It conforms to the ECMA Specification so it is right and has nothing to
do with the browser being "good-hearted".
[color=blue]
>but it is what it is. Let's take the
><input type="checkbox" name="[:-)"> sample :[/color]
Valid HTML.
[color=blue]
> We cannot use its name as identifier:
> alert(document.forms[0].[:-).name) will make your script very[/color]
surprised.
It is a very obvious syntax error.
[color=blue]
>But we can access its name as a value:
>alert(document.forms[0].elements[0].name)[/color]
And you can access it as:-
document.forms[0]['[:-)'].name
-or-
document.forms[0].elements['[:-)'].name
- either of which are completely valid ECMA Script Property Accessors.
[color=blue]
>The question remains who and why would want to assign
>identifiers which cannot be used as identifiers?[/color]
That question should be "The question remains who and why would want to
assign *property names* which cannot be used as identifiers?". And the
answer is; anyone who wants to (as it is completely ECMA Script legal).
[color=blue]
>Another question: should browsers be so liberal? Maybe a
>better practice would be to force authors to follow HTML specs?[/color]
A question that should be addressed to the browser authors as ECMA
Script can cope with any character sequence in DOM property names so it
is not really relevant to this group if the browsers choose to allow
names/ids that are not valid HTML.
On the other hand, the paragraph you quoted still allows valid id
attributes that could not be valid ECMA Script Identifiers. Which means
that it would still be a good thing that ECMA Script allows any property
name to be used if browsers were strict in their interpretation of HTML.
[color=blue]
>4. End
>"Any name has to start with a letter and consist of any combination 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)".[/color]
The ECMA Script specification places no restrictions on the character
set or sequence in property names, only upon characters used as
Identifiers in ECMA Script source code.
[color=blue]
>Always and everywhere follow this simple rule, and you will never
>have to worry about boring standards and compatibility issues.
>At least not in the naming.[/color]
Otherwise understanding those standards would be the best plan.
Richard.
