document.forms[formName].elemName

[Stanimir Stamenkov]

<form name="myForm" action="...">
<p><input type="text" name="myElem"></p>
</form>

As far as I was able to get the following is the standard way of
accessing HTML form elements:

document.forms['myForm'].elements['myElem']

But I have also seen the following:

document.forms['myForm'].myElem

Is the later correct usage or it just happens all browsers I've
tried with (IE 6, Mozilla 1.8, Opera 9.2 and Safari 3.1 on Windows)
support it for compatibility with existing Web content?

--
Stanimir

[Thomas 'PointedEars' Lahn]

Re: document.forms[formName].elemName

Stanimir Stamenkov wrote:

<form name="myForm" action="...">
<p><input type="text" name="myElem"></p>

A `div' element instead of `p' would be semantic here. It isn't exactly a
text paragraph, is it?

</form>
>
As far as I was able to get the following is the standard way of
accessing HTML form elements:
>
document.forms['myForm'].elements['myElem']

Correct, as far as the standard goes. That the object referred to by
`document' implements the HTMLDocument interface of W3C DOM Level 2 HTML
in many cases has been a proprietary, yet reasonable design decision.

But I have also seen the following:
>
document.forms['myForm'].myElem
>
Is the later correct usage

I think it qualifies as deprecated usage by now.

http://docs.sun.com/source/816-6408-10/form.htm

or it just happens all browsers I've
tried with (IE 6, Mozilla 1.8, Opera 9.2 and Safari 3.1 on Windows)
support it for compatibility with existing Web content?

It would seem so.

http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-40002357

http://www.w3.org/TR/DOM-Level-2-HTML/glossary.html

PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8 300dec7@news.de mon.co.uk>

[VK]

Re: document.forms[formName].elemName

On May 25, 3:12 pm, Stanimir Stamenkov <s7a...@netscap e.netwrote:

<form name="myForm" action="...">
<p><input type="text" name="myElem"></p>
</form>
>
As far as I was able to get the following is the standard way of
accessing HTML form elements:
>
document.forms['myForm'].elements['myElem']
>
But I have also seen the following:
>
document.forms['myForm'].myElem

The latter is a shortcut accessor to the same element. Most of the
time the shortcut form can be used to preserve your keyboard and your
finger tips :-) It is not the case when the form control name doesn't
conform with Javascript valid identifier rules. Imagine you have a set
of radioboxes with names adjusted for PHP server-side pre-processing,
so something like <input type="radio" name="radio[0]">, "radio[1]"
etc. Obviously by using the shortcut form
document.forms['myForm'].radio[0] you'll get runtime errors. At the
same time the fully qualified notation will work:
document.forms['myForm'].elements['radio[0]']

[Thomas 'PointedEars' Lahn]

Re: document.forms[formName].elemName

VK wrote:

On May 25, 3:12 pm, Stanimir Stamenkov <s7a...@netscap e.netwrote:

><form name="myForm" action="..."<p> <input type="text"
>name="myElem"> </p</form>
>>
>As far as I was able to get the following is the standard way of
>accessing HTML form elements:
>>
>document.for ms['myForm'].elements['myElem']
>>
>But I have also seen the following:
>>
>document.for ms['myForm'].myElem

>
The latter is a shortcut accessor to the same element.

It sa reference to the same element _object_, if that.

Most of the time the shortcut form can be used to preserve your keyboard
and your finger tips :-) It is not the case when the form control name
doesn't conform with Javascript valid identifier rules.

Wrong. The proprietary referencing allows

document.forms['myForm']["myElem[]"]

as well.

The reason for using the standards-compliant approach over the proprietary
one is that the latter is the *proprietary* one. Proprietary approaches
should be avoided, and should only serve as a fallback for
standards-compliant approaches because, theoretically, by definition they
could break any minute the code is exposed to another, previously unknown,
user agent.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[Stanimir Stamenkov]

Re: document.forms[formName].elemName

Sun, 25 May 2008 07:51:22 -0700 (PDT), /VK/:

On May 25, 3:12 pm, Stanimir Stamenkov <s7a...@netscap e.netwrote:
>

>document.for ms['myForm'].elements['myElem']
>>
>But I have also seen the following:
>>
>document.for ms['myForm'].myElem

>
The latter is a shortcut accessor to the same element. Most of the
time the shortcut form can be used to preserve your keyboard and your
finger tips :-)

Yes, it seems to save typing but I haven't found it described in the
ECMAScript language binding [1] of the DOM Level 2 HTML
specification, so I've thought it is just deprecated as Thomas Lahn
suggested in another reply. Having said that my question could be
stated better as "should the second form of access not be used in
newly written scripts?".

[1] http://www.w3.org/TR/DOM-Level-2-HTM...t-binding.html

--
Stanimir

[VK]

Re: document.forms[formName].elemName

On May 25, 7:01 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

The reason for using the standards-compliant approach over the proprietary
one is that the latter is the *proprietary* one.

???

forms[index] or forms["formName"] exposes an object with properties
representing form elements (a.k.a. controls) in the given form.
Javascript allows to access object property over squared brackets
notation or over dot notation, other words in object foo with property
bar, the bar value can be accessed either
foo["bar"]
or
foo.bar
The latter form is a convenience shortcut of the first one and
acceptable iff the property name corresponds to the Javascript
identifier naming rules. Say if the property named not "bar" but
"class" or "bar[0]" or "#$&%&#*" etc. then only the full form is
usable.

These are basics of the language itself, so naturally they are not
documented over and over again wherever objects are discussed: just
like in a complex analysis math books they don't explain what do +, -
and other basic signs mean before each new formula. Once explained -
works everywhere further unless explicitly spelled otherwise.

[VK]

Re: document.forms[formName].elemName

On May 25, 7:05 pm, Stanimir Stamenkov <s7a...@netscap e.netwrote:

Yes, it seems to save typing but I haven't found it described in the
ECMAScript language binding [1]

See my answer to Thomas. Both accessor syntax types are in the
language core, so not explained in each particular application.

[Stanimir Stamenkov]

Re: document.forms[formName].elemName

Sun, 25 May 2008 08:37:30 -0700 (PDT), /VK/:

On May 25, 7:05 pm, Stanimir Stamenkov <s7a...@netscap e.netwrote:
>

>Yes, it seems to save typing but I haven't found it described in the
>ECMAScript language binding [1]

>
See my answer to Thomas. Both accessor syntax types are in the
language core, so not explained in each particular application.

I understand if object.property Name works, object["propertyNa me"]
will also work equally but could you point me where in the DOM Level
2 HTML specification (and its ECMAScript language binding) it is
stated form elements are exposed as properties of the
HTMLFormElement object?

While these are same:

document.forms["formName"].elemName
document.forms["formName"]["elemName"]

they are different from:

document.forms["formName"].elements["elemName"]

the later being the only thing I've found defined in the standard.

--
Stanimir

[Steve]

Re: document.forms[formName].elemName

On May 25, 5:01 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

The reason for using the standards-compliant approach over the proprietary
one is that the latter is the *proprietary* one.

Could you explain what this is supposed to mean?

[VK]

Re: document.forms[formName].elemName

On May 25, 8:02 pm, Stanimir Stamenkov <s7a...@netscap e.netwrote:

Sun, 25 May 2008 08:37:30 -0700 (PDT), /VK/:
>

On May 25, 7:05 pm, Stanimir Stamenkov <s7a...@netscap e.netwrote:

>

Yes, it seems to save typing but I haven't found it described in the
ECMAScript language binding [1]

>

See my answer to Thomas. Both accessor syntax types are in the
language core, so not explained in each particular application.

>
I understand if object.property Name works, object["propertyNa me"]
will also work equally but could you point me where in the DOM Level
2 HTML specification (and its ECMAScript language binding) it is
stated form elements are exposed as properties of the
HTMLFormElement object?

I have no a slightest clue about it, sorry - I never read any of DOM
Level 1 or 2 specs.

In any case document.forms, document.forms. elements, document.links,
document.anchor s etc. are parts of the original Netscape Navigator
document model (so-called DOM 0) so out of any jurisdiction of W3C.
They simply are, always were and always will.

So if your question is carrying out some practical issue then the
answer is above. If it is an academical study then you are in some
troubles because off my head I have no idea where you could find now
any authoritative, "stamped and sealed" proof that there is indeed
window object with say setTimeout and clearTimeout methods, DOM 0,
document.forms[0].foobar-type accesor and many other things that
simply are from the beginning of times so no one ever needed to
document it.

[Stanimir Stamenkov]

Re: document.forms[formName].elemName

Sun, 25 May 2008 09:22:41 -0700 (PDT), /VK/:

So if your question is carrying out some practical issue then the
answer is above. If it is an academical study then you are in some
troubles because off my head

I'm searching or rather asking if there's a practical reason to use
the not officially standardized (and I've been also asking whether
it is standardized) way of accessing form elements.

I have no idea where you could find now
any authoritative, "stamped and sealed" proof that there is indeed
window object with say setTimeout and clearTimeout methods,

You could follow the work on standardizing these (and more) by the
Web API WG <http://www.w3.org/2006/webapi/>: Window Object 1.0
<http://www.w3.org/TR/Window>.

DOM 0,

This has always been referred to something different vendors have
once implemented but hasn't been standardized later, either because
the standard covers the features in a different way (though a way
the vendors have agreed on), or the features could not be specified
in way all vendors agree on at the time.

http://www.w3.org/TR/DOM-Level-2-HTML/glossary.html#dt-DOM-Level-0

document.forms[0].foobar-type accesor and many other things that
simply are from the beginning of times so no one ever needed to
document it.

Even if document.forms[0].foobar is from the beginning of times I
couldn't find it in the Mozilla specific documentation [1], too, so
I can only guess this way of accessing form elements is just deprecated.

[1] http://developer.mozilla.org/en/docs/DOM:form

--
Stanimir

[VK]

Re: document.forms[formName].elemName

On May 25, 8:51 pm, Stanimir Stamenkov <s7a...@netscap e.netwrote:

I'm searching or rather asking if there's a practical reason to use
the not officially standardized (and I've been also asking whether
it is standardized) way of accessing form elements.

Up do you. As well as with window.onload, window.open etc.

http://www.w3.org/TR/Window/#notcovered

IMHO if you think that any DOM 0 can be not implemented as of now,
then no convincing arguments can be provided.
....

Even if document.forms[0].foobar is from the beginning of times I
couldn't find it in the Mozilla specific documentation [1], too, so
I can only guess this way of accessing form elements is just deprecated.

Stanimir, sorry, but this type of discussion is plain boring. The
things are not being done by W3C specs anyway so who gives a crap what
is written or not written in where? Or do you think no one used window
object until 2006 because until then W3C didn't admit its existence&
It might be interesting to research for say current SVG coverage and
bugs, but examining say window.open support is plain silly. Yet just
make a test accesor document.forms['myForm'].elementName and see if
it's typeof undefined before further use.

[Lasse Reichstein Nielsen]

Re: document.forms[formName].elemName

VK <schools_ring@y ahoo.comwrites:

In any case document.forms, document.forms. elements, document.links,
document.anchor s etc. are parts of the original Netscape Navigator
document model (so-called DOM 0) so out of any jurisdiction of W3C.
They simply are, always were and always will.

And yet they are also specified in the W3C DOM Level 1 and DOM Level 2
HTML specifications.
In these, the HTMLFormElement does not have each element as
properties, only the "elements" HTMLCollection.

So if your question is carrying out some practical issue then the
answer is above. If it is an academical study then you are in some
troubles because off my head I have no idea where you could find now
any authoritative, "stamped and sealed" proof that there is indeed
window object with say setTimeout and clearTimeout methods, DOM 0,

Those are indeed not part of a commonly implemented standard.

document.forms[0].foobar-type accesor and many other things that
simply are from the beginning of times so no one ever needed to
document it.

.... but document.forms and form.elements are W3C standard, and has
been for almost ten years.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Stanimir Stamenkov]

Re: document.forms[formName].elemName

Sun, 25 May 2008 10:12:28 -0700 (PDT), /VK/:

[...]

Yet just
make a test accesor document.forms['myForm'].elementName and see if
it's typeof undefined before further use.

If you never read any specification (being standard or not) and you
code just by trial and error you would eventually end up in a
situation you don't know how to substitute something used to work
previously but not anymore (as it would have been deprecated for a
long time, for example).

A simple but probably not best example is variation of my initial one:

document.formNa me.elemName

This appears to work with HTML documents but doesn't appear to work
with XHTML ones.

Anyway, thanks for taking time to respond.

--
Stanimir

[VK]

Re: document.forms[formName].elemName

On May 25, 10:17 pm, Stanimir Stamenkov <s7a...@netscap e.netwrote:

If you never read any specification (being standard or not)

I didn't say that: I said that I never bothered to read W3C specs as I
see very low practical value in that. Ever since about 1996 my main
"document" is text dump of
for (var p in probe) {
out.value+= p + '=' + probe[p] + '\n';
}
received from different objects in different browsers and then reading
the corresponding producer's documentation and then manually checking
how does the description fits the reality because very often it
doesn't. Sooner or later you will come to the conclusion that it is
the only reliable way for the commercial development: but I have no
intention to boost the process. Let it be your own conclusion and not
someone's push.

just by trial and error you would eventually end up in a
situation you don't know how to substitute something used to work
previously but not anymore (as it would have been deprecated for a
long time, for example).

And how W3C's belletristic would be helpful? Say window.prompt leads
to the security alert in IE7 or newer with default security settings
so not usable for a long time now and must be replaced by DHTML
emulations. But sure you already new it from w3.org so no use to
repeat the obvious... Oh, was it a revelation to you? How come, did
you read wrong w3.org pages or what? ;-)

Of course one has to monitor new software releases and to check the
existing solutions on newer UA versions. What on really has to do is
to abandon the idea to learn how to write "eternal" programs that
would work from now on and for anything what may possibly come in the
feature - because it is futile. Other words one has to stop being an
idealistic philosopher and start to be a developer. This last
paragraph is not to you directly, just some thoughts.