3

If you have a form element within a form and that element has a name or id, you can access it directly off the form's DOM element as a property with that name. This behavior appears to be very broadly-supported. Is it covered by any specification, and if so, which one?

This behavior for a form's elements collection is specified in the DOM2 HTML spec, but I'm not immediately seeing the business of dumping the elements as properties on the form itself specified anywhere, unless the phrase "It provides direct access to the contained form controls as well as the attributes of the form element." here is meant to say that (if so, wow is that subtle, I read it as referring to the elements collection). I'm guessing it's just legacy behavior.

For clarity: I'm not asking what the best way to access form fields is, I'm asking if this behavior is covered by a standard. (I'm also avoiding the whole business of things being dumped on the window object; that's a whole other topic.)

Example (live copy):

HTML:

<form id="theForm">
<input type="text" name="field1" value="foo">
<input type="text" id="field2" value="bar">
</form>

JavaScript:

var f = document.getElementById("theForm");
console.log(f.elements.field1.value); // "foo", per spec
console.log(f.field1.value);          // also "foo"
console.log(f.elements.field2.value); // "bar", per spec
console.log(f.field2.value);          // also "bar"

I've checked IE6, 7, 8, and 9, Firefox 4.0, Firefox 3.6, Chrome 12, Opera 11, and Safari 5. They all do it (make the form fields available in both places).

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • I'm pretty sure this is leftover backwards support for something that was originally IE nonstandard behaviour – Gareth Jun 28 '11 at 10:33
  • @Gareth: Thanks, I think I remember it from Netscape Navigator 2, so it's probably not Microsoft's fault, but maybe Netscape copied from IE1 or something -- there was a lot of back-and-forth in those heady years of the First Browser War. :-) In any case, it's [in the process of being recognised in a standard](http://stackoverflow.com/questions/6503764/form-elements-as-properties-of-the-form/6504878#6504878). – T.J. Crowder Jun 28 '11 at 10:36
  • http://jibbering.com/faq/names/ – Bergi Sep 01 '14 at 15:15

3 Answers3

1

Found it in the draft HTML5 specification:

When a form element is indexed for indexed property retrieval, the user agent must return the value returned by the item method on the elements collection, when invoked with the given index as its argument.

Each form element has a mapping of names to elements called the past names map. It is used to persist names of controls even when they change names.

The supported property names are the union of the names currently supported by the object returned by the elements attribute, and the names currently in the past names map.

When a form element is indexed for named property retrieval, the user agent must run the following steps:

  1. If name is one of the supported property names of the object returned by the elements attribute, then run these substeps:

    1. Let candidate be the object returned by the namedItem() method on the object returned by the elements attribute when passed the name argument.

    2. If candidate is an element, then add a mapping from name to candidate in the form element's past names map, replacing the previous entry with the same name, if any.

    3. Return candidate and abort these steps.

  2. Otherwise, name is the name of one of the entries in the form element's past names map: return the object associated with name in that map.

If an element listed in the form element's past names map is removed from the Document, then its entries must be removed from the map.

...and we know from the DOM2 HTML specification's section on ECMAScript language mapping that indexing via [] ends up being a call to either item (for numbers) or namedItem (for strings).

Thanks to @Carey for his answer to my other related question, which made me facepalm and look in the HTML5 draft, since they're trying to subsume the HTML DOM stuff into the spec.

Community
  • 1
  • 1
T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
0

It's specified in Netscape's Javascript-Reference

Dr.Molle
  • 116,463
  • 16
  • 195
  • 201
  • That's also a very old copy of the documentation that has been superseded by [mozdev](https://developer.mozilla.org/en-US/). It is also worth pointing out that the relevant document is lurking a couple of paragraphs down in the section about the elements property (even though they don't actually have anything to do with that property aside from duplicating it). – Quentin Jun 28 '11 at 09:15
  • Thanks, but I'm looking for a specification from a standards body. – T.J. Crowder Jun 28 '11 at 09:31
  • As far as I know Netscape "invented" Javascript, so the linked documents are a kind of standard. Since AOL closes netscape-devedge there no longer exists an official ressource for this. But however, as long as Javascript never has been an "official standard" , you will not find an official standard (the derived ECMAScript doesn't contain specific informations about what we are talking here). – Dr.Molle Jun 28 '11 at 09:42
  • Netscape did indeed invent JavaScript, specifically Brendan Eich when employed there. But whoever owns Netscape this week doesn't define the DOM or the language bindings for it, and in terms of *standards*, Netscape and Mozilla have to take a back seat now to the ECMA (for JavaScript) and the W3C (for DOM and HTML), though of course the folks at Mozilla are **key** members of the working groups related to both of those efforts. – T.J. Crowder Jun 28 '11 at 10:19
0

From DOM 2 (my emphasis):

The FORM element encompasses behavior similar to a collection and an element. It provides direct access to the contained form controls as well as the attributes of the form element.

It is a bit fuzzily worded, but that covers the behaviour you are seeing.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • Yes, I quoted that as well in my question. That's ***awfully*** subtle for a specification, if it's really meant to specify this behavior. Still, this may be the answer. I suppose I could write to the W3C. – T.J. Crowder Jun 28 '11 at 09:33