Re: Unsafe Names for HTML Form Controls

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-HTML/html.html#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-Level-1-20000929/level-one-html.html#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_props.html#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/ >
.

Relevant Pages

  • Re: Unsafe Names for HTML Form Controls
    ... controls, not just input elements. ... the ECMAScript bindings documents make assertions about the mapping of bracket notation property accessors to collection interface methods. ... That would depend on how you defined a collection (the DOM specification doesn't). ...
    (comp.lang.javascript)
  • Re: Unsafe Names for HTML Form Controls
    ... contained in a form is being similar, not having any form control ... collection interface methods. ... methods that could be mapped to the property accessors. ... That is what the ECMAScript bindings say they must do for the ...
    (comp.lang.javascript)
  • Re: How to flag onclick() and confirm() using DOM
    ... Because the - addEventListener - is defined as being an optional part of the Node interface it should be reasonable to assume that either all Nodes have the method or that no Nodes have the method. ... For a start text Nodes often do not have the method (as it is generally impractical to use text nodes because IE has no equivalent at that level of its DOM) so you might shift the interest to only object implementing the Element interface for expedience. ... But there are browsers where the window does not have the methods but the Elements do, so an inference from the window to the elements would have sup-optimal results. ... wrapper for getElementsByTagName. ...
    (comp.lang.javascript)
  • Re: Identifier like "_", "$", etc.
    ... On e of the main things that has dogged the - isFunction - question over its very long history is that very few people have been willing to state what 'being a function' represents. ... The W3C DOM is defined in terms of interfaces; sets of properties and methods that object implementing those interfaces must possess. ... Neither ECMAScript, the W3C DOM specs nor the ECMAScript bindings for the DOM interfaces place any restrictions on the nature of the objects implementing an interface, and as ECMAScript functions are objects there is absolutely no reason for any object implementing a W3C DOM interface not to be an ECMAScript function. ... The point being that there is no technical reason to expect to be able to discriminate between objects implementing the Element interface and an ECMAScript function. ...
    (comp.lang.javascript)
  • Re: Denigration of GUI
    ... For myself designing the interface is the most challenging and interesting ... I think a Java GUI can create a screen that acts just ... data bound controls are an option but I use them rarely. ... that CLI screens are reusable in a way ...
    (comp.lang.cobol)