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]

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-HTM...ml#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, <f8*******************@news.demon.co.uk>

[VK]

On May 25, 3:12 pm, Stanimir Stamenkov <[e-mail]:

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

VK wrote:

On May 25, 3:12 pm, Stanimir Stamenkov <[e-mail]:

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

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]

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

On May 25, 3:12 pm, Stanimir Stamenkov <[e-mail]:

>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 :-)

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]

On May 25, 7:01 pm, Thomas 'PointedEars' Lahn <[e-mail]>
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]

On May 25, 7:05 pm, Stanimir Stamenkov <[e-mail]:

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]

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

On May 25, 7:05 pm, Stanimir Stamenkov <[e-mail]:

>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.propertyName works, object["propertyName"]
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]

On May 25, 5:01 pm, Thomas 'PointedEars' Lahn <[e-mail]>
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]

On May 25, 8:02 pm, Stanimir Stamenkov <[e-mail]:

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

On May 25, 7:05 pm, Stanimir Stamenkov <[e-mail]:

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.propertyName works, object["propertyName"]
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.anchors 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]

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

On May 25, 8:51 pm, Stanimir Stamenkov <[e-mail]:

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]

VK <sc**********@yahoo.comwrites:

In any case document.forms, document.forms.elements, document.links,
document.anchors 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 - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Stanimir Stamenkov]

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

On May 25, 10:17 pm, Stanimir Stamenkov <[e-mail]:

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.

[Thomas 'PointedEars' Lahn]

VK wrote:

On May 25, 7:01 pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

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

???

Why not read a posting again before protesting, if it is confusing at first?

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

No, the proprietary backwards-compatible "convenience shortcut" regarding
the reference to form control objects that we are talking about here is

document.formname.elementname
or
document.forms["formname"].elementname

instead of the standards-compliant and also backwards-compatible

document.forms["formname"].elements["elementname"]

Whether the bracket property accessor is used or not is secondary to this
difference.

[...]
These are basics of the language itself,

You miss the point.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Thomas 'PointedEars' Lahn]

Stanimir Stamenkov wrote:

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

>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-HTM...dt-DOM-Level-0

What you and I have cited states that DOM Level 2 HTML specifies features
that are also found in "DOM Level 0". It is therefore obvious nonsense to
state that "DOM Level 0" it has not been standardized later; some parts of
it have been, and HTMLDocument::forms is one good example of that.

However, as you have observed, the standards-compliant referencing uses
specific collections and control names as as their property/item names, not
only control names, for the referencing.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Thomas 'PointedEars' Lahn]

VK wrote:

On May 25, 10:17 pm, Stanimir Stamenkov <[e-mail]:

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

And therefore you think that you of all people are in a position
to tell the difference between standards-compliant or proprietary,
and to make recommendations in that matter.

You're right. And the moon consists of green cheese. [psf 4.17]
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Gregor Kofler]

Thomas 'PointedEars' Lahn meinte:

You're right. And the moon consists of green cheese. [psf 4.17]

I'm not a hundred percent positive about the "green". But "cheese" -
yes: Wallace and Gromit verified that [1].

Gregor
[1]
http://uk.imdb.com/title/tt0104361/
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

[VK]

On May 26, 12:56 am, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

VK wrote:

On May 25, 10:17 pm, Stanimir Stamenkov <[e-mail]:

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.

And therefore you think that you of all people are in a position
to tell the difference between standards-compliant or proprietary,
and to make recommendations in that matter.

I don't classify things for standards-compliant and proprietary as it
is mostly useless. I do classify things for i) ones being reliably
usable on the current set of browsers in consideration (possibly with
UA-specific workarounds) and for ii) ones not currently being reliably
usable on the current set of browsers in consideration.

I assume that "standards-compliant" refers to "being documented at
w3.org and acting in the way as documented at w3.org".

You're right. And the moon consists of green cheese.

If you say so. And say
var b = document.createElement('BUTTON');
b.type = 'button";
is safe to use on any modern browser with document.createElement
support because it is "standards-compliant"? Right? Or not right?

[Stanimir Stamenkov]

Sun, 25 May 2008 21:50:22 -0700 (PDT), /VK/:

I don't classify things for standards-compliant and proprietary as it
is mostly useless. I do classify things for i) ones being reliably
usable on the current set of browsers in consideration (possibly with
UA-specific workarounds) and for ii) ones not currently being reliably
usable on the current set of browsers in consideration.

I assume that "standards-compliant" refers to "being documented at
w3.org and acting in the way as documented at w3.org".

Of course compatibility is the most important goal everyone is
after. Adhering to standards is the first step in this regard.
Testing on all target platforms and working around for specific
one(s) is next. If you're using more non-standardized stuff it is
more likely you'll get more compatibility problems, initially and in
future. Don't you agree?

var b = document.createElement('BUTTON');
b.type = 'button";
is safe to use on any modern browser with document.createElement
support because it is "standards-compliant"? Right? Or not right?

Doesn't seem standards-compliant as the 'type' attribute of
HTMLButtonElement objects is defined to be read-only.

--
Stanimir

[Thomas 'PointedEars' Lahn]

Gregor Kofler wrote:

Thomas 'PointedEars' Lahn meinte:

>You're right. And the moon consists of green cheese. [psf 4.17]

I'm not a hundred percent positive about the "green". But "cheese" -
yes: Wallace and Gromit verified that [1].

D'oh, seems I'll have to update that psf :)
Regards,

PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Thomas 'PointedEars' Lahn]

Stanimir Stamenkov wrote:

Sun, 25 May 2008 21:50:22 -0700 (PDT), /VK/:

> var b = document.createElement('BUTTON');
b.type = 'button";
is safe to use on any modern browser with document.createElement
support because it is "standards-compliant"? Right? Or not right?

Doesn't seem standards-compliant as the 'type' attribute of
HTMLButtonElement objects is defined to be read-only.

One wonders, though, why that is, given that the `type' attribute of HTML
4.01/XHTML 1.0 BUTTON/button elements may assume one of three possible values:

http://www.w3.org/TR/1999/REC-html40...ml#edef-BUTTON
http://www.w3.org/TR/2000/REC-xhtml1...ml1-strict.dtd

Seems like an obvious error in the DOM 2 HTML Specification to me.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[Stanimir Stamenkov]

Mon, 26 May 2008 10:43:00 +0200, /Thomas 'PointedEars' Lahn/:

Stanimir Stamenkov wrote:

>Doesn't seem standards-compliant as the 'type' attribute of
HTMLButtonElement objects is defined to be read-only.

One wonders, though, why that is, given that the `type' attribute of HTML
4.01/XHTML 1.0 BUTTON/button elements may assume one of three possible values:

http://www.w3.org/TR/1999/REC-html40...ml#edef-BUTTON
http://www.w3.org/TR/2000/REC-xhtml1...ml1-strict.dtd

Seems like an obvious error in the DOM 2 HTML Specification to me.

The 'type' attribute of HTMLInputElement has been read-only in the
DOM Level 1 but changed in DOM Level 2. As to why the 'type'
attribute of HTMLButtonElement was left read-only in DOM Level 2 I
could only speculate it is because that's how it is implemented in
Internet Explorer:

http://msdn.microsoft.com/en-us/libr...96(VS.85).aspx

Seems one could use instead:

var btn = document.createElement('button');
btn.setAttribute('type', 'reset');

--
Stanimir