javascript - Why JS function name conflicts with element ID?

Question

I've got two almost identical simple JS fiddles calling a function on select change. Function name is the same as select ID in both cases, but for some reason the first fiddle works just fine, and the second one fails with a JavaScript error is not a function:

http://jsfiddle.net/AZkfy/7/ - works fine in FF9 (Linux), Chromium 16 (Linux), IE8 (Windows):

<script>
    function border(border) { alert(border); }
</script>

<select id='border' name='border' onchange='border(this.value)'>
    <option value='foo'>foo</option>
    <option value='bar'>bar</option>
</select>

and

http://jsfiddle.net/cYVzk/ - fails in FF9 (Linux), Chromium 16 (Linux), IE8 (Windows):

<script>
    function border(border) { alert(border); }
</script>

<form>
<select id='border' name='border' onchange='border(this.value)'>
    <option value='foo'>foo</option>
    <option value='bar'>bar</option>
</select>
</form>

First of all I fail to understand why the first one works fine, and the second one fails.

Second - are there any JS specifications or restrictions regarding the conflicting JS function names and element ID?

Answer 1

This is a legacy scope chain issue originating from JavaScript 1.0 to 1.3 when there was no distinction between the programming language and what we now call a DOM API ("Dynamic HTML" back then).

If your form control (here: a select element) is part of a form (descendant of a form element), then the Form object that represents the form element is third-next in the scope chain of code in the control's event-handler attribute values (second-next is the form control object itself, next is the Variable Object of that code).

JavaScript? was designed by Brendan Eich (then at Netscape) as a programming language that is easy to use for beginners and that works well with HTML documents (as complement to Sun's Java; hence the ever-confusing name). Because in those early days language and (Netscape) DOM API were one, this (over)simplification applied to the DOM API as well: A Form object has the names of the controls contained in the form that it represents as the names of its properties that refer to the corresponding form control objects. IOW, you can write

myForm.border

which is the proprietary shorthand of the standards-compliant (W3C DOM Level 2 HTML), but equally backwards-compatible

document.forms["myForm"].elements["border"]

Now, if you use a form control's name in an event-handler attribute value of a form control in a form, like

<form …>
  <… name="border" onchange='border(this.value)' …>
</form>

that is the same as if you had written the half-proprietary

<form …>
  <… name="border" onchange='this.form.border(this.value)' …>
</form>

or the standards-compliant

<form …>
  <… name="border" onchange='this.form.elements["border"](this.value)' …>
</form>

because a potential global border() function is a property of the ECMAScript Global Object which comes last, after the Form object (an object implementing the HTMLFormElement interface in the W3C DOM), in the scope chain.

However, the form control object referred here by border is not callable (does not implement the ECMAScript-internal [[Call]] method or implements it so that it throws an exception when called). So if you try to call the object with border(this.value), a TypeError exception is thrown, which you should see in the script consoles (like "TypeError: border is not a function" in the Developer Tools of Chromium 16.0.912.77 [Developer Build 118311 Linux]).

Microsoft, Netscape's competitor in the 1990s, had to copy that feature for the MSHTML DOM so that code written for Netscape would also run in Internet Explorer (3.0), with JScript (1.0). And Microsoft's competitors copied it to their DOM implementations for exactly the same reason. It became part of a quasi-standard (now called "DOM Level 0").

Then came the DOM Level 2 HTML Specification, a continuing effort to standardize and extend common features of existing DOM implementations at the time. A W3C Recommendation since 2003-01-09, its ECMAScript Language Binding specifies that items of HTMLCollections can be accessed by their name or ID with the bracket property accessor syntax […], equivalent to calling the namedItem() method of the object implementing the HTMLCollection interface.

form element objects and element objects for form controls in forms are items of HTMLCollections in the W3C DOM, HTMLDocument::forms and HTMLFormElement::elements, respectively. But for backwards compatibility in browsers,

document.forms["myForm"].elements["myControl"]

needs to be equivalent to

document.myForm.myControl

So, with the implementations of W3C DOM Level 2 HTML interfaces at the latest, this feature started to apply to elements with ID (id attribute value) as well (which can be seen in Chromium, for example).

As a result, the convenience feature introduced in JavaScript? 16 years ago still bites you like a bug in client-side DOM scripting today.

If you avoid using the same name or ID for form controls and forms that you use as identifier of user-defined functions, and that are already used for built-in form properties (like action, submit, and reset), then this becomes less of an issue. Also, it is a bad idea to use the same identifier for the function and one of its arguments as (confusing code aside) that makes the function object inaccessible from within the function (the Variable Object of the function context comes first in its scope chain).