FAQ Topic - My element is named myselect[], how do I access it? (2010-04-09)

[FAQ server]

-----------------------------------------------------------------------
FAQ Topic - My element is named myselect[], how do I access
it?
-----------------------------------------------------------------------

Form controls with any "illegal" characters can be accessed with
` formref.elements["myselect[]"] ` - The bracket characters,
amongst others, are illegal in ID attributes and javascript
identifiers, so you should try to avoid them as browsers may
handle them incorrectly.

http://msdn.microsoft.com/en-us/library/ms537449(VS.85).aspx

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

http://jibbering.com/faq/notes/square-brackets/


The complete comp.lang.javascript FAQ is at
http://jibbering.com/faq/

 

[Garrett Smith]

-----------------------------------------------------------------------
FAQ Topic - My element is named myselect[], how do I access
it?
-----------------------------------------------------------------------

Form controls with any "illegal" characters can be accessed with
` formref.elements["myselect[]"] ` - The bracket characters,
amongst others, are illegal in ID attributes and javascript
identifiers, so you should try to avoid them as browsers may
handle them incorrectly.

http://msdn.microsoft.com/en-us/library/ms537449(VS.85).aspx

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

How about a replacement:
https://developer.mozilla.org/en/DOM/form

http://jibbering.com/faq/notes/square-brackets/

That faq note provides the example:

| var stringOfValue = document.formName.inpName.value;

That is nonstandard and can result in a leaked form control. HTML 5
terms this as some sort of feature.

How about:
| var stringOfValue = document.forms.formName.elements.inpName.value;

?

Although standard form control access is not the point of the article,
the examples should not propose the reader to use non-standard access.
Considering this is linked from an entry on how to access a named form
control, it has the effect of advocating non-standard code.

 

[Richard Cornford]

On Apr 9, 5:38 am, Garrett Smith wrote:

That faq note provides the example:

| var stringOfValue = document.formName.inpName.value;

Which is preceded by the statement; "Various forms of dot notation
property accessor can be used to reference the "value" property of the
input element. One of the simplest is:-", which is factual in that
various forms can be used (name a single HTML DOM implementation where
the 'shortcut' accessors will not work with the mark-up shown) and the
example is one of the simplest that can be used. The point of the
example is to show equivalence between bracket notation property
accessors, for which any additional complexity and elaboration would
be unhelpful.

That is nonstandard

Except in the sense that it has never been possible to show an HTML
DOM environment where they don't work. But being standard or not is
not relevant to which (recognizable) forms of bracket notation
accessors would be equivalent (to showing the relationship between the
strings in the brackets and the Identifiers following the dots).

Proposing this change is as silly as the previous suggestion that
pointing out the equivalence between - document.body -,
document['body'] - and - doucment['bo'+'dy'] - was wrong because
nobody would ever use the latter two. Understanding how things work is
not dependent on how they would be used.

and can result in a leaked form control. HTML 5
terms this as some sort of feature.

How about:
| var stringOfValue = document.forms.formName.elements.inpName.value;

The next line of text reads; "This dot notation has three dots, so
there are three points at which the square bracket notation could be
used in place of the dot notation (these are all equivalent)". You
want to have five dots, and so must add the additional equivalents to
the following text, making it considerably more complex without adding
anything to the explanation that is being provided (indeed, probably
making it less clear).

?

Although standard form control access is not the point of the
article,

And examples of actual form access (rather than examples only of dot/
bracket-notation property accessors) use the standard form access
methods.

the examples should not propose the reader to use non-standard
access.

It doesn't. Indeed pointing out that the simple 'shortcut' form exists
and then not using it in the form access examples could be seen as
discouraging its use (as the observant reader may recognize that not
using the 'shortcut' accessors to work with forms would have been a
deliberate decision).

Considering this is linked from an entry on how to access a named
form control, it has the effect of advocating non-standard code.

There is a perfectly good article in the notes talking about form
access that states the relative status of the types of form access
methods.

Richard.

 

[Garrett Smith]

On Apr 9, 5:38 am, Garrett Smith wrote:
[...]

That is nonstandard

Except in the sense that it has never been possible to show an HTML
DOM environment where they don't work. But being standard or not is
not relevant to which (recognizable) forms of bracket notation
accessors would be equivalent (to showing the relationship between the
strings in the brackets and the Identifiers following the dots).

It is not part of any official standard.

The consequence of using the shortcut `myForm.controlName` is a leaked
form control.

If the element named `controlName` gets a new name or id, or is removed
from the document, `myForm.controlName` still points to that element.

http://jibbering.com/faq/names/form_dom_removal.html

Proposing this change is as silly as the previous suggestion that
pointing out the equivalence between - document.body -,
document['body'] - and - doucment['bo'+'dy'] - was wrong because
nobody would ever use the latter two. Understanding how things work is
not dependent on how they would be used.

I got that understanding the concept is the point of the article and the
example. My gripe is that the example uses nonstandard approach. That
approach has a nasty side effect and can be avoided by simply using the
standard approach.

The standard approach can be used as example without any harmful
consequence.

The next line of text reads; "This dot notation has three dots, so
there are three points at which the square bracket notation could be
used in place of the dot notation (these are all equivalent)". You
want to have five dots, and so must add the additional equivalents to
the following text, making it considerably more complex without adding
anything to the explanation that is being provided (indeed, probably
making it less clear).

The example could be made to fit that text.

| Various forms of dot notation property accessor can be used to
| reference the form named "formName":
| var form = document.forms.formName;

A novice who did not know how to get a form control now knows how to get
a FORM. If he keeps reading he will see the standard way to get that.

And examples of actual form access (rather than examples only of dot/
bracket-notation property accessors) use the standard form access
methods.


It doesn't. Indeed pointing out that the simple 'shortcut' form exists
and then not using it in the form access examples could be seen as
discouraging its use (as the observant reader may recognize that not
using the 'shortcut' accessors to work with forms would have been a
deliberate decision).

That assumes that the reader reads both articles. I think that is too
much to expect. Some readers will scan/read enough to do what they want
to know and stop reading and continue on with whatever it was that set
them to find the answer in the first place.

There is a perfectly good article in the notes talking about form
access that states the relative status of the types of form access
methods.

http://jibbering.com/faq/notes/form-access/
That is linked from #formControlAccess entry.

 

[Garrett Smith]

[...]

Regarding changing the FAQ note to use a DOM-compliant example (as
expressed below "proposed change"), how strongly do you feel about
keeping this.

Does else have an opinion on the proposed change?

The standard approach can be used as example without any harmful
consequence.

Proposed change:

The example could be made to fit that text.

| Various forms of dot notation property accessor can be used to
| reference the form named "formName":
| var form = document.forms.formName;

A novice who did not know how to get a form control now knows how to get
a FORM. If he keeps reading he will see the standard way to get that.

[...]

 

[Richard Cornford]

On Apr 9, 5:38 am, Garrett Smith wrote:

http://jibbering.com/faq/notes/square-brackets/

[...]

That is nonstandard

Except in the sense that it has never been possible to show an
HTML DOM environment where they don't work. But being standard
or not is not relevant to which (recognizable) forms of bracket
notation accessors would be equivalent (to showing the
relationship between the strings in the brackets and the
Identifiers following the dots).

It is not part of any official standard.

Neither is having a - document - property of the global object that
refers to an object implementing the Document interface. How much FAQ
code is going to be rendered non-function when you get around to
removing all instances of that?

I got that understanding the concept is the point of the article
and the example. My gripe is that the example uses nonstandard
approach.

It doesn't 'use' anything, it just shows a dot-notation property
accessor that is likely to be easily understood by people reading the
article, especially in relation to the bracket notation alternative
formulations.

That approach has a nasty side effect and can be avoided by
simply using the standard approach.

The best you could say is that it _can_ have nasty side effects (How
often do people actually change the name or ID of a form control?),
but since actually using that formulation is not encouraged by the
article (and is effectively discouraged) that is not relevant.

The standard approach can be used as example without any harmful
consequence.

The example (which was original chosen, over possible alternatives
(including all 'standard formulations), for its combination of
relative complexity and recognisably for the expected audience) is
fine as it is.

The example could be made to fit that text.

<snip>

Or it could be left alone.

That assumes that the reader reads both articles.

Which "both articles"? Examples of combining numbers with strings in
the expressions in bracket nation property accessors, relating to
forms and using the standard formulations, appear later in the article
on bracket notation property accessors. Indeed, they were deliberately
used to contrast the simpler form shown earlier.

I think that is too much to expect. Some readers will scan/read
enough to do what they want to know and stop reading and continue
on with whatever it was that set them to find the answer in the
first place.

Probably, but then the article must have made the point about the
relationship between dot and bracket notation property accessors, and
the specific examples that may have been read up until the point where
they stop reading will not significantly influence the behaviour of
such an individual.

http://jibbering.com/faq/notes/form-access/

That is linked from #formControlAccess entry.

No:-

<URL: http://jibbering.com/faq/faq_notes/form_access.html >

The FAQ question on strangely named controls links to the last section
of the bracket-nation property accessor article (which is long after
the example you have decided to quibble about), so there is no reason
to expect people interested in learning how to access form controls to
be reading that article at all. They should be being directed to the
form access article.

The people interested in bracket-notation are not necessarily
interested in applying it to form access at all, and if they are then
they will see specific examples of doing so in the way that you
consider 'correct'.

Richard.

 

[Richard Cornford]

[...]

Regarding changing the FAQ note to use a DOM-compliant example (as
expressed below "proposed change"),

Which are incomplete as they do not include the then necessary changes
to the examples of equivalent bracket nation property accessors.

how strongly do you feel about
keeping this.

I have no idea why you are wasting anyone's time (including your own)
on this pointless and trivial quibble. I will never approve such a
worthless change.

Does else have an opinion on the proposed change?

<snip>

Richard.

 

[Asen Bozhilov]

<URL:http://jibbering.com/faq/faq_notes/square_brackets.html>

Are you planning to update/rewrite with other name that article? Will
be good if you explain the `PropertyName` in object literals. For
example:

var obj = {if : true};

By ECMA-262-3 that should be SyntaxError, because property name is
bound by rules for Identifier. Identifier rules do not allow to be
used Identifier with same sequence of symbols as ReservedWord.

And the follow code is syntactical correct:

var obj = {'if' : true};

Because object literals allow to be used string literals as property
name.

Regards.

 

[Garrett Smith]

[...]

Regarding changing the FAQ note to use a DOM-compliant example (as
expressed below "proposed change"),

Which are incomplete as they do not include the then necessary changes
to the examples of equivalent bracket nation property accessors.

how strongly do you feel about
keeping this.

I have no idea why you are wasting anyone's time (including your own)
on this pointless and trivial quibble. I will never approve such a
worthless change.

I do not approve of nonstandard examples in the FAQ. Particularly when
they are presented as solutions to problems and especially when the
consequences to using the nonstandard approach are not explained.

It is harmful advice.

 

[Garrett Smith]

On Apr 9, 5:38 am, Garrett Smith wrote:
<snip>
http://jibbering.com/faq/notes/square-brackets/ [...]

That is nonstandard
Except in the sense that it has never been possible to show an
HTML DOM environment where they don't work. But being standard
or not is not relevant to which (recognizable) forms of bracket
notation accessors would be equivalent (to showing the
relationship between the strings in the brackets and the
Identifiers following the dots).

It is not part of any official standard.

Neither is having a - document - property of the global object that
refers to an object implementing the Document interface. How much FAQ
code is going to be rendered non-function when you get around to
removing all instances of that?

We are not doing that.

It doesn't 'use' anything, it just shows a dot-notation property
accessor that is likely to be easily understood by people reading the
article, especially in relation to the bracket notation alternative
formulations.


The best you could say is that it _can_ have nasty side effects (How
often do people actually change the name or ID of a form control?),
but since actually using that formulation is not encouraged by the
article (and is effectively discouraged) that is not relevant.

Changing the name or id of the form control is only one cause of the
problem.

The problem with leaked control occurs when the node is removed, as
discussed I don't know many times, and mentioned in the named form
controls article.

| The consequence of using the shortcut `myForm.controlName` is a leaked
| form control.
|
| If the element named `controlName` gets a new name or id, or is
| removed from the document, `myForm.controlName` still points to that
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| element.
|
| http://jibbering.com/faq/names/form_dom_removal.html

The link to the example provided shows how accessing a control as a
named property directly off the form results in a leaked control.

A beginner should not be shown examples of nonstandard DOM, even if the
DOM is not the point of the article.

It is too much to expect the beginner to read that article, plus the
additional article "Referencing Forms and Form Controls".

The amount of typing required to use the standard approach is not much more.

The example (which was original chosen, over possible alternatives
(including all 'standard formulations), for its combination of
relative complexity and recognisably for the expected audience) is
fine as it is.

It has the consequence of showing a beginner a nonstandard approach, and
for what reason? Because it is simpler? Less typing?

How about using those reasons for writing code?

<snip>

Or it could be left alone.

Yes, but providing a nonstandard example that has inconsistent negative
side effects and not explaining those consequences is potentially harmful.

Which "both articles"?

You mentioned the other "perfectly good article," as you put it, so I
assumed you meant the article on form control access. That makes two
articles:

1) square brackets
2) form access

[...]

That is linked from #formControlAccess entry.

No:-

<URL: http://jibbering.com/faq/faq_notes/form_access.html >

Try ctrl + f5 on the FAQ. You should see the updated link URL.
http://jibbering.com/faq/#formControlAccess

The FAQ question on strangely named controls links to the last section
of the bracket-nation property accessor article (which is long after
the example you have decided to quibble about), so there is no reason
to expect people interested in learning how to access form controls to
be reading that article at all. They should be being directed to the
form access article.

So you think the entry should link to /notes/form-access/ and not
notes/square-brakets/ ?

That sounds fine.

[...]

 

[Garrett Smith]

Are you planning to update/rewrite with other name that article?

I don't exactly get your meaning. I'm not rewriting articles, but I am
editing them, including:
* Use HTML Strict
* Link all articles under /faq/notes/
* Navigation
* Edits for broken links, spelling, etc.

I will probably update the meta tags. I thought to put at the top of the
documents under faq_notes that a more recent of the document occurs at
/faq/notes/[article_path]

Will

be good if you explain the `PropertyName` in object literals. For
example:

var obj = {if : true};

By ECMA-262-3 that should be SyntaxError, because property name is
bound by rules for Identifier. Identifier rules do not allow to be
used Identifier with same sequence of symbols as ReservedWord.

And the follow code is syntactical correct:

var obj = {'if' : true};

Because object literals allow to be used string literals as property
name.

That's useful, but not really directly related to "Square Bracket
Notation". It seems out of place for that article.

 

[Asen Bozhilov]

That's useful, but not really directly related to "Square Bracket
Notation". It seems out of place for that article.

Yes, that is not related with property access notations, but can it in
addition. And general idea is to show distinctions between property
names in square bracket notation, dot notation and property names in
object literals. In object literal cannot be used result of expression
for property name. That is the main difference with square bracket
notation, where result of any valid expression by ECMA-262 can be used
as property name. The difference with dot notation where property name
is an Identifier, in object literal as property name can be used
NumericLiteral and StringLiteral. So any valid Indentifier,
NumericLiteral and StringLiteral can be used as property name. For
example, the follow property names are syntactical valid by rules in
ECMA-262-3 11.1.5 Object Initialiser:

var obj = {
propertyName : true,
2 : true,
'function' : true
};

And the follow are not, because are not valid Identifier,
StringLiteral or NumericLiteral:

var obj1 = {
function : false,
2 + 2 : false,
'str\' : false
};

Another purposes to I suggested update of article is because ES5 does
changes in dot notation and object literal for PropertyName. There is
used IdentifierName instead of Identifier, which mean ReservedWords in
ECMA-262-5 can be used as property name in dot notation.

| ECMA-262-5 11.2.1 Property Accessors

| Properties are accessed by name, using either the dot notation:
| MemberExpression . IdentifierName
| CallExpression . IdentifierName

And in ES5 implementation the follow property access expressions are
syntactical valid:

myObj.function;
myObj.super;

And follows are invalid:

myObj.0;
myObj.\u0030;

You can see some new things in ES5 by kangax slides.
<URL: http://www.slideshare.net/kangax/say-hello-to-ecmascript-5 />
For my words see slide 46.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Mon, 12 Apr 2010 12:26:04, Garrett Smith

I do not approve of nonstandard examples in the FAQ. Particularly when
they are presented as solutions to problems and especially when the
consequences to using the nonstandard approach are not explained.

Examples used in the FAQ should normally work, or be believed to work,
in the 12 PC browsers that the EU makes Microsoft admit to[1], and in
other equally-common older browsers, and in a similar selection of non-
Windows browsers. They do not need to be W3C-compliant; but, where they
are not, that should be stated. They do not need to work in browsers
(they could be for JSCript in WSH, or other ECMAScript "derivatives");
but, where they are not, that should be stated.

[1] <http://www.browserchoice.eu/BrowserChoice/browserchoice_en.htm>