Unsafe Names for HTML Form Controls

Discussion in 'Javascript' started by dhtml, Oct 26, 2008.

  1. dhtml

    dhtml Guest

    dhtml, Oct 26, 2008
    #1
    1. Advertising

  2. In comp.lang.javascript message <ge13a1$8jp$>
    , Sat, 25 Oct 2008 23:38:55, dhtml <> posted:

    >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.htm> clpdmFAQ;
    NOT <URL:http://support.codegear.com/newsgroups/>: news:borland.* Guidelines
    Dr J R Stockton, Oct 26, 2008
    #2
    1. Advertising

  3. dhtml

    RobG Guest

    On Oct 26, 4:38 pm, dhtml <> wrote:
    > 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-HTML/html.html#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, whereas you can use form.elements 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
    RobG, Oct 27, 2008
    #3
  4. dhtml

    David Mark Guest

    On Oct 26, 2:38 am, dhtml <> wrote:
    > 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.
    David Mark, Oct 28, 2008
    #4
  5. dhtml

    dhtml Guest

    RobG wrote:
    > On Oct 26, 4:38 pm, dhtml <> wrote:
    >> 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.

    >


    First off, thank you for the comments. I made changes to the index page
    based on those. Removed 'clobber', added an example, and some text
    qualifying the DOM 1 quote.

    I did not agree with all of your feedback though. Comments interspersed.


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



    By virtue of implementing the HTMLFormElement interface, they also
    implement Node, Element, HTMLElement.

    Most browsers are implementing EventTarget and ElementCSSInlineStyle.

    > 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-HTML/html.html#ID-40002357 >
    >
    > Second sentence:
    >
    > “...as properties to the FORM.”
    >


    "adds a property to the form" vs "adds a property from the form."

    A property is added to the form, so I think the first one makes more sense.

    > 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, whereas you can use form.elements because its elements
    > property really is a collection.
    >


    It's right in the spec. you can hate it as much as I do and it will
    still be there.

    The elements can be accessed by index, as document.forms[0][0]. Just
    don't expect them to be in the order they appear in the document.


    > 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.
    >



    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. 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.

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

    > 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.
    >


    That is not the point I was trying to make. Hmm. The point is that when
    a FORM control is removed, the property might still be on the form.

    The phenomenon is demonstrated in the simple leak example:

    http://jibbering.com/faq/names/simple-leak-form-input.html

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

    // Clear out form's HTML.
    document.forms[0].innerHTML = "";
    document.write('foo: ' + document.forms[0].foo+'<br>');
    document.write('bar: '+document.forms[0].bar+'<br>');
    document.write('elements.foo: '+document.forms[0].elements.foo);
    </script>
    </pre>
    </body>
    </html>

    Firefox 3, Safari 3:
    foo: [object HTMLInputElement]
    bar: undefined
    elements.foo: undefined


    The result shows that after setting the forms innerHTML = "", the
    property remains on the form.

    Garrett


    --
    comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >
    dhtml, Oct 28, 2008
    #5
  6. dhtml

    RobG Guest

    On Oct 28, 2:10 pm, dhtml <> wrote:
    > RobG wrote:
    > > On Oct 26, 4:38 pm, dhtml <> wrote:
    > >> 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.

    >
    > First off, thank you for the comments. I made changes to the index page
    > based on those. Removed 'clobber', added an example, and some text
    > qualifying the DOM 1 quote.
    >
    > I did not agree with all of your feedback though. Comments interspersed.
    >
    > > First sentence:

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

    >
    > By virtue of implementing the HTMLFormElement interface, they also
    > implement Node, Element, HTMLElement.


    The article is about forms, so better to name the relevant interface
    at least.


    > Most browsers are implementing EventTarget and ElementCSSInlineStyle.
    >
    > > 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-HTML/html.html#ID-40002357>

    >
    > > Second sentence:

    >
    > > “...as properties to the FORM.”

    >
    > "adds a property to the form" vs "adds a property from the form."
    >
    > A property is added to the form, so I think the first one makes more sense.
    >
    > > 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, whereas you can use form.elements because its elements
    > > property really is a collection.

    >
    > It's right in the spec. you can hate it as much as I do and it will
    > still be there.
    >
    > The elements can be accessed by index, as document.forms[0][0]. Just
    > don't expect them to be in the order they appear in the document.


    Bugger me, in all these years I've never accessed a form control that
    way. I actually tried a test and stuffed it up, but see now that it
    can be done. All the same, it doesn't make it a collection any more
    than a collection is an Array because of being able to access its
    properties by index.

    Collections are defined in the DOM HTML spec, I don't see
    HTMLFormElement defined as one.


    >
    > > 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.

    >
    > The quote is from DOM 1.
    >
    > http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/level-one-html.html...


    Then that spec is missleading too for the same reason - form controls
    are no restricted to input elements (unless in DOM 1 access really was
    restricted to input elements). You may note that the DOM 2 HTML spec
    has ammended that phrase with "...contained form controls" instead.



    >
    > > 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.


    Noted, but doesn't change my mind. :)


    > The DOM specification says that a form encompasses behavior of a
    > collection. 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.


    It also has a self adjusting, read-only length property related to the
    number of controls in the form, but doesn't seem to implement the
    HTMLCollection's item or namedItem methods (in Firefox 3 at least).

    So it is fair to say that it has some of the properties of a
    collection, just like it's fair to say a collection is *like* an
    Array, but that doesn't make it one.


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


    NamedNodeMap is in the DOM Core spec, not the HTML spec which defines
    HTMLCollection. I think if you are going to introduce the term
    "collection" as a generic term, you should define what you mean by it
    and make clear that you aren't referring to the set of objects defined
    by the DOM 2 HTML spec that implement the HTMLCollection interface.

    >
    > > 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.

    >
    > That is not the point I was trying to make. Hmm. The point is that when
    > a FORM control is removed, the property might still be on the form.


    Then better to say that. You can also remove controls using
    removeChild rather than innerHTML[1] and your example still works.
    Perhaps the form has multiple references to the control and removing
    one of them doesn't remove the others.

    1. I think using DOM methods makes for a better example, otherwise
    it's easy to blame innerHTML for unexpected behaviour 'cos it's not a
    standard and has known cross-browswer differences.


    --
    Rob
    RobG, Oct 29, 2008
    #6
  7. 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 (pre-DOM collections that were
    formalised in the HTML DOM retained their - tags - methods for back-
    compatibility))

    The - tags - method was used to provide fall-back on IE 4 for -
    getElementsByTagName -because wherever you could have otherwise used -
    elementRef.getElementsByTagName(tagNameString); - on IE 4 you could
    use elementRef.all.tags(tagNameString); - (the - all - collection of
    elements containing all decedents so the subset of a particular type
    was equivalent to the DOM method's result (though I don't recall
    whether order or 'live-ness' were equivalent).

    Richard.
    Richard Cornford, Oct 29, 2008
    #7
  8. dhtml

    David Mark Guest

    On Oct 29, 9:35 am, Richard Cornford <>
    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 (pre-DOM collections that were
    > formalised in the HTML DOM retained their - tags - methods for back-
    > compatibility))


    Oh that. I thought that was just for the "all" collections.

    >
    > The - tags - method was used to provide fall-back on IE 4 for -
    > getElementsByTagName -because wherever you could have otherwise used -


    Right. I use it for just that.

    > elementRef.getElementsByTagName(tagNameString); - on IE 4 you could
    > use elementRef.all.tags(tagNameString); - (the - all - collection of
    > elements containing all decedents so the subset of a particular type
    > was equivalent to the DOM method's result (though I don't recall
    > whether order or 'live-ness' were equivalent).


    I don't remember either. Order is the same, IIRC.
    David Mark, Oct 29, 2008
    #8
  9. dhtml

    dhtml Guest

    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, whereas you can use
    >>> form.elements 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/ >
    dhtml, Oct 31, 2008
    #9
  10. dhtml

    dhtml Guest

    David Mark wrote:
    > On Oct 29, 9:35 am, Richard Cornford <>
    > 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/ >
    dhtml, Oct 31, 2008
    #10
  11. 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, whereas you can use
    >>>> form.elements 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-HTML/html.html#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.
    Richard Cornford, Oct 31, 2008
    #11
  12. On Oct 25, 11:38 pm, dhtml <> wrote:
    > 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
    Peter Michaux, Oct 31, 2008
    #12
  13. dhtml

    dhtml Guest

    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-HTML/html.html#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/whatwg-whatwg.org/2008-August/015684.html
    http://lists.w3.org/Archives/Public/public-html/2008Jul/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/ >
    dhtml, Nov 3, 2008
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jeronimo Bertran

    Compiling a code behind file as unsafe

    Jeronimo Bertran, Nov 18, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    416
    Jacob Yang [MSFT]
    Nov 19, 2003
  2. Axl
    Replies:
    2
    Views:
    15,613
    John C. Bollinger
    Sep 2, 2004
  3. Mark 'Kamikaze' Hughes

    Re: does lack of type declarations make Python unsafe?

    Mark 'Kamikaze' Hughes, Jun 29, 2003, in forum: Python
    Replies:
    4
    Views:
    790
    Anton Vredegoor
    Jul 1, 2003
  4. rockdale
    Replies:
    3
    Views:
    3,244
    rockdale
    Nov 3, 2006
  5. Ondrej Sevecek

    Safe/Unsafe ActiveX controls

    Ondrej Sevecek, Nov 15, 2003, in forum: ASP .Net Web Controls
    Replies:
    0
    Views:
    101
    Ondrej Sevecek
    Nov 15, 2003
Loading...

Share This Page