Unsafe Names for HTML Form Controls

[dhtml]

I have written an article "Unsafe Names for HTML Form Controls".

<URL: http://jibbering.com/faq/names/ >

I would appreciate any reviews, technical or otherwise.

Garrett

--
comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >

[Dr J R Stockton]

In comp.lang.javascript message <ge**********@registered.motzarella.org>
, Sat, 25 Oct 2008 23:38:55, dhtml <dh**********@gmail.composted:

>I have written an article "Unsafe Names for HTML Form Controls".

A straightforward rule is that one should never choose for a name of any
sort any string which might be used for any purpose in a programmer-
visible interface of the system, whether as identifiers or as language
elements.

One method of doing this is to use non-English words (though I did once
read of a French Algol dialect in which the reserved words had been
translated).

Another can be to use unconventional capitalisation.

Another is to include one or more digits, though not 0 & 1 where they
may look like letters.

In any section on debugging, there should be mention of the possibility
of a newly-introduced name clashing with one in the same scope created
long ago. ISTR introducing a JavaScript/VBScript variable which matched
a pre-existing anchor.

--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk BP7, Delphi 3 & 2006.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.bancoems.com/CompLangPascalDelphiMisc-MiniFAQ.htmclpdmFAQ;
NOT <URL:http://support.codegear.com/newsgroups/>: news:borland.* Guidelines

[RobG]

On Oct 26, 4:38*pm, dhtml <[e-mail]:

I have written an article "Unsafe Names for HTML Form Controls".

<URL:http://jibbering.com/faq/names/>

I would appreciate any reviews, technical or otherwise.

I apologise in advance if these comments are late to the party, Google
Groups has been slow with updates lately. Comments below.
The use of colloquial terms like "clobber" are out of place in a
technical article, a better term would be “overwrite” or “replace”.

First sentence:

“An HTML FORM element...implements many interfaces, and has a rich
number of features”.

Would be better as:

“HTML FORM elements implement the HTMLFormElement Interface and have a
rich set of features”

Where the word HTMLFormElement is a link to the relevant part of the
DOM 2 HTML spec. The phrase “rich number” is inappropriate, “rich
set” is better.

<URL: http://www.w3.org/TR/DOM-Level-2-HTM...ml#ID-40002357 >

Second sentence:

“...as properties to the FORM.”

might be better as properties *of* the FORM”

In the section “What kind of Collection is a Form”, I have serious
reservations about calling a form a collection. It isn’t, it a DOM
object with certain properties. You can't access the controls as
form[i], whereas you can use form.elements[i] because its elements
property really is a collection.

The sentence:

“The FORM...provides direct access to the contained input elements”

Is misleading, a form has direct access to all named form controls,
not just input elements. Also, this point has been made earlier when
stating that references to named controls are added as properties of
the form. Further, the elements collection gives access to all
controls, not just the named ones.

I don’t think there should be any reference to the form as a
collection - since you can’t access the named properties by index, it
isn’t any kind of collection (mystery solved).

The “leak” example seems confusing. Why not simply state that once a
named property has been replaced by some other value, removing the
other value doesn’t restore the original. That behaviour is
consistent with javascript object properties and variables and
shouldn’t come as a big surprise.
--
Rob

[David Mark]

On Oct 26, 2:38*am, dhtml <[e-mail]:

I have written an article "Unsafe Names for HTML Form Controls".

<URL:http://jibbering.com/faq/names/>

I would appreciate any reviews, technical or otherwise.

I had to read this sentence a couple of times:

"Accessing a form control as a FORM property is like accessing a FORM
element directly off the document."

If I get it, you are saying they are both non-standard shortcuts and
therefore bad. I certainly agree, but it took a bit to understand the
analogy.

I don't understand the "simple leak example" at all. I would flesh
out the explanation of that.

"Some browsers also have a tags property on the elements collection"

That is a new one on me. What does it do?

The section titled "The elements Collection is Live" is a quote and
reference to a Mozilla bug report. I see the connection, but it
doesn't seem to work as a section.

I recently noticed that all of the FAQ documents are loose HTML. I
imagine they have always been, but it seems silly to transition the
site forever.

[Richard Cornford]

dhtml wrote:

RobG wrote:

>On Oct 26, 4:38 pm, dhtml wrote:

>>I have written an article "Unsafe Names for HTML Form Controls".

<snip>

I did not agree with all of your feedback though.

You probably won't agree with mine either, but we will have to wait as
it will be a while before i have time to write them all down.

<snip>

>In the section “What kind of Collection is a Form”, I have
serious reservations about calling a form a collection. It
isn’t, it a DOM object with certain properties. You can't
access the controls as form[i], whereas you can use
form.elements[i] because its elements property really is
a collection.

It's right in the spec.

No it is not.

<snip>

>“The FORM...provides direct access to the contained input
elements”

Is misleading, a form has direct access to all named form
controls, not just input elements. Also, this point has been
made earlier when stating that references to named controls
are added as properties of the form. Further, the elements
collection gives access to all controls, not just the named
ones.

The quote is from DOM 1.

http://www.w3.org/TR/2000/WD-DOM-Lev...ml#ID-40002357

>I don’t think there should be any reference to the form as a
collection - since you can’t access the named properties by index, it
isn’t any kind of collection (mystery solved).

Not calling a form a collection because it doesn't allow access by
index is not a good argument. First of all, it isn't true.

The DOM specification says that a form encompasses behavior of a
collection.

You are reading more into the text than it actually says. In the spec,
the ECMAScript bindings documents make assertions about the mapping of
bracket notation property accessors to collection interface methods. No
such assertions are made about the HTMLFormElement interface, and it
also has no methods that could be mapped to the property accessors. Thus
there is no DOM specified behaviour for - formElement[0] - or -
formElement['someName'] -.

That is a true statement. Named properties are accessed by name.
Indexed properties, by index. That's two types of ways
to index a form control.

But neither are defined in the (ECMAScript bindings for) the
specification.

Second, a map, such as NamedNodeMap, can be a collection.
Not all collections are indexed.

<snip>

That would depend on how you defined a collection (the DOM specification
doesn't).

The term 'collection', in this context, comes from early Netscape
browser documentation, and was also adopted by Microsoft to describe
corresponding structures/objects. The HTML DOM formalises (most of)
those 'collection' objects as the HTMLCollection interface, but a
NamedNodeMap is not an HTMLCollection.

Richard.

[dhtml]

Richard Cornford wrote:

dhtml wrote:

>RobG wrote:

>>On Oct 26, 4:38 pm, dhtml wrote:
I have written an article "Unsafe Names for HTML Form Controls".

<snip>

>I did not agree with all of your feedback though.

You probably won't agree with mine either, but we will have to wait as
it will be a while before i have time to write them all down.

I'll try to get to these comments over the weekend.

<snip>

>>In the section “What kind of Collection is a Form”, I have
serious reservations about calling a form a collection. It
isn’t, it a DOM object with certain properties. You can't
access the controls as form[i], whereas you can use
form.elements[i] because its elements property really is
a collection.

It's right in the spec.

No it is not.

spec says it is:

http://www.w3.org/TR/DOM-Level-2-HTM...ml#ID-40002357

| The FORM element encompasses behavior similar to a collection and
| an element.
And we can see that a form control can be referenced right off the form:-

document.forms[0][0]

If something has behavior of a collection, then it can be called a
collection. Not an "HTMLCollection" but some sort of collection that is
vaguely described by the spec.

of course that's not the only thing a form is. It's also an EventTarget
in most modern browsers.

<snip>

>>“The FORM...provides direct access to the contained input
elements”

Is misleading, a form has direct access to all named form
controls, not just input elements. Also, this point has been
made earlier when stating that references to named controls
are added as properties of the form. Further, the elements
collection gives access to all controls, not just the named
ones.

The quote is from DOM 1.

http://www.w3.org/TR/2000/WD-DOM-Lev...ml#ID-40002357

>>I don’t think there should be any reference to the form as a
collection - since you can’t access the named properties by index, it
isn’t any kind of collection (mystery solved).

Not calling a form a collection because it doesn't allow access by
index is not a good argument. First of all, it isn't true.

The DOM specification says that a form encompasses behavior of a
collection.

You are reading more into the text than it actually says. In the spec,
the ECMAScript bindings documents make assertions about the mapping of
bracket notation property accessors to collection interface methods. No
such assertions are made about the HTMLFormElement interface, and it
also has no methods that could be mapped to the property accessors. Thus
there is no DOM specified behaviour for - formElement[0] - or -
formElement['someName'] -.

You seem to interpret that as the property accessors map to either item
or namedItem method. But we can see that when using a string as a
property, the indexed element is returned.

>That is a true statement. Named properties are accessed by name.
Indexed properties, by index. That's two types of ways
to index a form control.

But neither are defined in the (ECMAScript bindings for) the specification.

I really don't think I'm reading more into the spec. This is what it says:-

| Functions of objects that implement the HTMLCollection interface:
|
| item(index)
| This *function* returns an object that implements the Node
| interface.
| The index parameter is a Number.
| Note: This *object* can also be dereferenced using square
| bracket notation (e.g. obj[1]). Dereferencing with an integer
| index is equivalent to invoking the item function with that
| index.
| namedItem(name)
| This function returns an object that implements the Node
| interface.
| The name parameter is a String.
| Note: This object can also be dereferenced using square
| bracket notation (e.g. obj["foo"]). Dereferencing using a string
| index is equivalent to invoking the namedItem function with that
| index.

Where the spec says "Note: This *object* can also be dereferenced using
square bracket notation (e.g. obj[1])", that does define how property
accessors work on a form, even though they defined it wrong.

The square bracket property accessors do not do type checking. Not on
native objects and not when used on DOM elements. The Expression is
converted to a string.

That's why I pointed out:
http://jibbering.com/faq/names/extra...#StandardWrong

And the example shows that
document.forms[0]["0"] is the same as document.forms[0][0];

There is no equivalent of "namedItem" being called. It doesn't work that
way.

>Second, a map, such as NamedNodeMap, can be a collection.
Not all collections are indexed.

<snip>

That would depend on how you defined a collection (the DOM specification
doesn't).

Right.

The term 'collection', in this context, comes from early Netscape
browser documentation, and was also adopted by Microsoft to describe
corresponding structures/objects. The HTML DOM formalises (most of)
those 'collection' objects as the HTMLCollection interface, but a
NamedNodeMap is not an HTMLCollection.

Right. Its a collection in the general sense. For example, a
java.util.Map is part of the "Collections Framework". Granted, we're not
talking about Java, but in the general sense of the word "collection" a
map fits the description.

Richard.

--
comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >

[dhtml]

David Mark wrote:

On Oct 29, 9:35 am, Richard Cornford <[e-mail]>
wrote:

>On Oct 28, 3:36 am, David Mark wrote:
<snip>"Some browsers also have a tags property on the elements

>>collection"
That is a new one on me. What does it do?

<snip>

The - tags - property is a method of the collection objects. It takes
a string value representing a tag name as its argument and returns a
collection/array of all the elements in its collection that have a
corresponding tag name. (Here 'collection' means the pre-DOM
collections, so - elementRef.children - has a - tags - method but -
elementRef.childNodes - does not

I don't have IE here, but in Opera:-
javascript:document.write(document.body.childNodes .tags);document.close();

Result:
Opera
function tags() { [native code] }
For a more complete example, we can see on the form.elements collection:-

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
<title>elements-tags.html</title>
</head>
<body>
<form action="">
</form>
<script type="text/javascript">
document.write(document.forms[0].elements.tags);
</script>

</body>
</html>
Opera, Safari:-
function tags() { [native code] }

I don't have IE here and I'm too busy at work to check this.

Garrett

--
comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >

[Richard Cornford]

On Oct 31, 6:36 am, dhtml wrote:

Richard Cornford wrote:

>dhtml wrote:

>>RobG wrote:
On Oct 26, 4:38 pm, dhtml wrote:
I have written an article "Unsafe Names for HTML Form
Controls".

<snip>

>>I did not agree with all of your feedback though.

>You probably won't agree with mine either, but we will have
to wait as it will be a while before i have time to write
them all down.

I'll try to get to these comments over the weekend.

As it looks like it will be unlikely that I will have time to write
them before Monday it will be interesting to see how you do that.

><snip>

>>>In the section “What kind of Collection is a Form”, I have
serious reservations about calling a form a collection. It
isn’t, it a DOM object with certain properties. You can't
access the controls as form[i], whereas you can use
form.elements[i] because its elements property really is
a collection.

>>It's right in the spec.

>No it is not.

spec says it is:

No it dosn't.

http://www.w3.org/TR/DOM-Level-2-HTM...ml#ID-40002357

| The FORM element encompasses behavior similar to a collection
| and an element.

Being a collection would be a recognisable absolute state, while being
similar to a collection is at best ambiguous. Having a - length -
property that dynamically reflects the number of form controls
contained in a form is being similar, not having any form control
retrieval methods represents not being the same as a collection.

And we can see that a form control can be referenced right off
the form:-

document.forms[0][0]

Yes, but as a product of facilitating back-compatibility rather than
as a result of the W2C DOM specification.

If something has behavior of a collection,

The DOM specification does not provide it with the behaviour of a
collection, just some (one) of the properties of a collection.

then it can be called a collection.

The representations of FORM Element in web browsers certainly can be
called 'collections', but that is because there were collections
before there was a W3C DOM standard for them.

Not an "HTMLCollection" but some sort of collection that is
vaguely described by the spec.

Specifications are not in the business of vaguely describing things.
If they don't specify something then it is not part of the
specification, and the form elements are not specified as having any
form control retrieval methods.

of course that's not the only thing a form is. It's also an
EventTarget in most modern browsers.

Except IE (7 and 8 reasonably qualify as 'modern', as 'modern' only
suggest chronological criteria (most lists of "modern" browsers
includes IE 6, but excludes the much more recent Opera 7)).

><snip>

>>>“The FORM...provides direct access to the contained input
elements”

<snip>

>>The DOM specification says that a form encompasses behavior
of a collection.

>You are reading more into the text than it actually says. In
the spec, the ECMAScript bindings documents make assertions
about the mapping of bracket notation property accessors to
collection interface methods. No such assertions are made
about the HTMLFormElement interface, and it also has no
methods that could be mapped to the property accessors. Thus
there is no DOM specified behaviour for - formElement[0]
- or - formElement['someName'] -.

You seem to interpret that as the property accessors map to
either item or namedItem method.

That is what the ECMAScript bindings say they must do for the
HTMLCollection interface.

But we can see that when using a string as a
property, the indexed element is returned.

The initial nature of the value of the expression used in a bracket
notation property accessor is irrelevant as they are always type-
converted into strings in property accessor algorithm. The ECMAScript
bindings for the DOM don't get any say in that, they can only suggest
that (like the Array [[Put]] method) some action is taken based on the
value (characters in) of that string.

>>That is a true statement. Named properties are accessed by name.
Indexed properties, by index. That's two types of ways
to index a form control.

>But neither are defined in the (ECMAScript bindings for) the
specification.

I really don't think I'm reading more into the spec. This is what it says:-

| Functions of objects that implement the HTMLCollection interface:
|
| item(index)
| This *function* returns an object that implements the Node
| interface.
| The index parameter is a Number.
| Note: This *object* can also be dereferenced using square
| bracket notation (e.g. obj[1]). Dereferencing with an integer
| index is equivalent to invoking the item function with that
| index.
| namedItem(name)
| This function returns an object that implements the Node
| interface.
| The name parameter is a String.
| Note: This object can also be dereferenced using square
| bracket notation (e.g. obj["foo"]). Dereferencing using a string
| index is equivalent to invoking the namedItem function with that
| index.

Where the spec says "Note: This *object* can also be dereferenced
using square bracket notation (e.g. obj[1])", that does define how
property accessors work on a form,

No it does not. That section is (as it clearly sates) is about the
HTMLCollection interface. At no point in the spec does it say that
object implementing the HTMLFormElement interface also implement the
HTMLCollection interface. So, as I have already pointed out, the
HTMLFormElement interface has no methods for form control retrieval
and no mapping of those methods to bracket notation property accessors
(obviously without the former the latter would not be possible).

even though they defined it wrong.

The square bracket property accessors do not do type checking.
Not on native objects and not when used on DOM elements. The
Expression is converted to a string.

<snip>

And the example shows that
document.forms[0]["0"] is the same as document.forms[0][0];

As the ECMAScript specification requires it to be.

There is no equivalent of "namedItem" being called. It doesn't
work that way.

How it works does not influence the meaning of the specification. If
accessing form controls by indexing the objects implementing the
HTMLFormElement interface were specified there would have to be method
in the interface to do that retrieval, and a mapping of property
accessors to those method in the ECMAScript bindings. These things
are absent from the specification, and so the ability to reference
form controls as properties of implementing the HTMLFormElement
interface is not specified.

It is not what can be done that is being disputed here, but only
whether the ability to do it is specified; it is not.

>>Second, a map, such as NamedNodeMap, can be a collection.
Not all collections are indexed.

<snip>

>That would depend on how you defined a collection (the DOM
specification doesn't).

Right.

>The term 'collection', in this context, comes from early
Netscape browser documentation, and was also adopted by
Microsoft to describe corresponding structures/objects.
The HTML DOM formalises (most of) those 'collection' objects
as the HTMLCollection interface, but a NamedNodeMap is not
an HTMLCollection.

Right. Its a collection in the general sense. For example, a
java.util.Map is part of the "Collections Framework". Granted,
we're not talking about Java, but in the general sense of the
word "collection" a map fits the description.

We can talk about Java in this context because the HTML DOM Java
bindings are also pertinent when considering intentions regarding the
HTMLFormElement interface. Java has no equivalent of bracket notation
property accessors so when it accesses a collection it has to use
methods. The Java bindings for HTMLCollection have those methods (as
do NodeList, etc.), but the bindings for HTMLFormElement do not. It is
hardly reasonable to assert that a specification framed in IDL and
provided with bindings for ECMAScript and Java should only be
referring only to ECMAScript implementations when saying "encompasses
behaviour similar to a collection", and as an interpretation of that
text that suggests the HTMLFormElement be a collection is contradicted
by the omissions in the Java bindings (in addition to the ECMAScript
bindings) it becomes necessary to read the text as having another
intended meaning.

Ricahrd.

[Peter Michaux]

On Oct 25, 11:38*pm, dhtml <[e-mail]:

I have written an article "Unsafe Names for HTML Form Controls".

<URL:http://jibbering.com/faq/names/>

New articles should only go on the jibbering server after they are
approved by the group.

<URL:http://jibbering.com/faq/>

The two URLs above point to the same file which seems wrong.

Peter

[dhtml]

Richard Cornford wrote:

On Oct 31, 6:36 am, dhtml wrote:

>Richard Cornford wrote:

>>dhtml wrote:
RobG wrote:
On Oct 26, 4:38 pm, dhtml wrote:

>
Being a collection would be a recognisable absolute state, while being
similar to a collection is at best ambiguous. Having a - length -
property that dynamically reflects the number of form controls
contained in a form is being similar, not having any form control
retrieval methods represents not being the same as a collection.

The spec says:-
It provides direct access to the contained input elements as well as the
attributes of the FORM element.

Being similar to a collection is not descriptive enough (vague). The
length property is not significant to being similar to a collection.

A collection is, in the general sense of the word, an object that holds
other objects, either indexed or keyed. Describing a form element as
being similar to a collection, first and foremost, solely on the basis
that it has a length property would be misplaced.

It would be shorter to say that the form has length property, however,
the length property is not that significant to warrant placement as the
first sentence in the under the heading HTMLFormElement. In fact, the
length property defined below that.
http://www.w3.org/TR/DOM-Level-2-HTM...ml#ID-40002357

I think the authors intentionally left out defining "direct access". I
think they were aware of browsers allowing named controls being
accessible directly off the form but couldn't specify that in IDL.

>Not an "HTMLCollection" but some sort of collection that is
vaguely described by the spec.

Specifications are not in the business of vaguely describing things.

Similar to a collection sounds vague to me. You said ambiguous, but I
think vague is more appropriate.

>But we can see that when using a string as a
property, the indexed element is returned.

The initial nature of the value of the expression used in a bracket
notation property accessor is irrelevant as they are always type-
converted into strings in property accessor algorithm. The ECMAScript
bindings for the DOM don't get any say in that, they can only suggest
that (like the Array [[Put]] method) some action is taken based on the
value (characters in) of that string.

[snip]

>>
The square bracket property accessors do not do type checking.
Not on native objects and not when used on DOM elements. The
Expression is converted to a string.

And that is stated in the article:-

| Contrary to what the [DOM 1] specification states, the [ ] property
| access operator does not perform a typecheck. In ECMAScript, property
| access is performed with obj[ Expression ] or obj . Identifier.
....
| When the property access operator is used, the Expression is converted
| to a string with the internal ToString.

I've also mentioned on the html mailing lists:
http://lists.whatwg.org/pipermail/wh...st/015684.html
http://lists.w3.org/Archives/Public/...8Jul/0169.html

<snip>

>And the example shows that
document.forms[0]["0"] is the same as document.forms[0][0];

As the ECMAScript specification requires it to be.

That is how property access works. But that is not what DOM 0 says.

>
We can talk about Java in this context because the HTML DOM Java
bindings are also pertinent when considering intentions regarding the
HTMLFormElement interface. Java has no equivalent of bracket notation
property accessors so when it accesses a collection it has to use
methods. The Java bindings for HTMLCollection have those methods (as
do NodeList, etc.), but the bindings for HTMLFormElement do not. It is
hardly reasonable to assert that a specification framed in IDL and
provided with bindings for ECMAScript and Java should only be
referring only to ECMAScript implementations when saying "encompasses
behaviour similar to a collection", and as an interpretation of that
text that suggests the HTMLFormElement be a collection is contradicted
by the omissions in the Java bindings (in addition to the ECMAScript
bindings) it becomes necessary to read the text as having another
intended meaning.

I've updated pages 1, 2, and the conclusion. Accessing controls directly
off the FORM is non-standard. A FORM is not an HTMLCollection, but it
acts like a collection in a non-standard way. Web forms 2.0 is trying to
standardize the behavior.

Looking forward to more comments.

Garrett

--
comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >