Javascript Name action problem

[Meendar]

Hi,

Below is my code snippet having only one form,

<form>
<input type ="radio" name="action" value="xyz" checked>xyz
<input type ="radio" name="action" value="zyx">zyx
<input type ="radio" name="action" value="yxz">yxz
</form>
Through Javascript when i change action url

document.forms[0].action = "some.php";
document.forms[0].submit();

The radio button action ( watch the name of radio button) gets
changed. I have no choice to change the name of the radio button.

Is there any workaround for this?

Thanks!

[Henry]

On Aug 13, 1:32 pm, Meendar wrote:

Hi,

Below is my code snippet having only one form,

<form>
<input type ="radio" name="action" value="xyz" checked>xyz
<input type ="radio" name="action" value="zyx">zyx
<input type ="radio" name="action" value="yxz">yxz
</form>

Through Javascript when i change action url

document.forms[0].action = "some.php";
document.forms[0].submit();

The radio button action ( watch the name of radio button)
gets changed. I have no choice to change the name of the
radio button.

Is there any workaround for this?

Why is the FORM elements ACTION not specified as an attribute in the
opening FORM tag?

The - action - property of a FORM element cannot refer to more than
one object at the same time, so your best option is change the name of
radio buttons. They should never have been named "action" to start
with, and any small change, such as "Action" would be sufficient to
avoid the issue. See:-

<URL: http://jibbering.com/faq/faq_notes/f....html#faComMis >

[dhtml]

Henry wrote:

On Aug 13, 1:32 pm, Meendar wrote:

>
The - action - property of a FORM element cannot refer to more than
one object at the same time, so your best option is change the name of
radio buttons. They should never have been named "action" to start
with, and any small change, such as "Action" would be sufficient to
avoid the issue. See:-

<URL: http://jibbering.com/faq/faq_notes/f....html#faComMis >

That is a good article, however, it is little outdated.

| In addition to making named FORM elements
| available as named properties of the document.forms
| collection web browsers also make them available as
| named properties of the document object.

Fortunately, that is no longer true in most browsers.

Alas, the same cannot be said for HTML Form Controls' names being added
as properties to a form. In fact, we can see that this is regressing now
with Web Forms 2.0:
http://www.whatwg.org/specs/web-form...ork/#additions

In my research, I have discovered some 240 names that will replace (or
shadow, depending on the implementation) properties of a FORM element,
even when the original property was "readonly", "const", or a function.

<form name='testForm'>
<input name="length"/>
<input name="toString"/>
</form>

<script>
alert( document.forms.testForm );
</script>

Will result in errors in Firefox 3, Safari 3, and Opera 9.5. The alert
will attempt to call the form's - toString - property.

There are 240 such properties that I am aware of. It is likely that that
number will increase as more names are discovered and new features are
created.

Garrett

[Richard Cornford]

dhtml wrote:

Henry wrote:

<snip>

><URL: http://jibbering.com/faq/faq_notes/f....html#faComMis >

That is a good article, however, it is little outdated.

| In addition to making named FORM elements
| available as named properties of the document.forms
| collection web browsers also make them available as
| named properties of the document object.

Fortunately, that is no longer true in most browsers.

<snip>

In the absence of a rational for "Fortunately", any single cited example
and any evidence/justification for "most" this is most likely to be
dismissed as more of your usual BS.

Richard.

[dhtml]

Richard Cornford wrote:

dhtml wrote:

>Henry wrote:

<snip>

>><URL: http://jibbering.com/faq/faq_notes/f....html#faComMis >

That is a good article, however, it is little outdated.

| In addition to making named FORM elements
| available as named properties of the document.forms
| collection web browsers also make them available as
| named properties of the document object.

Fortunately, that is no longer true in most browsers.

<snip>

In the absence of a rational for "Fortunately", any single cited example
and any evidence/justification for "most" this is most likely to be
dismissed as more of your usual BS.

You probably meant 'rationale'.

Regardless, that is a loaded statement. It implies that I usually post BS.

<form name="testform"></form>
<script>
alert([document.testform, document.testform]);
</script>

Will result in:
Firefox 3, Opera, Safari

object,object

So it is true that browsers still exhibit this old behavior. I remember
testing this previously and getting a different result, but I modified
that test to do something else.

The browser adding form names as properties to the document creates a
bad situation (this is the 'rationale' part). The problem is that can
easily creates conflict with existing properties of the document. When a
browser adds a new feature and a new property name to the document
object, document.setTheme, for example, and a form named 'setTheme'
exists, there will be a conflict. Especially with an object that has as
many properties as document, which vary across many browsers.

It's the same problem with having form control names replace properties
of the form. Same rationale except the conflict exists between form
control names and properties on the FORM element.

You are obviously more interested in attempts to insult or discredit me
than you are to have any sort of technical discussion.

Garrett

Richard.

[optimistx]

dhtml wrote:

Richard Cornford wrote:

....

>In the absence of a rational for "Fortunately", any single cited
example and any evidence/justification for "most" this is most
likely to be dismissed as more of your usual BS.

You probably meant 'rationale'.

Regardless, that is a loaded statement. It implies that I usually
post BS.

<form name="testform"></form>
<script>
alert([document.testform, document.testform]);
</script>

Will result in:
Firefox 3, Opera, Safari

object,object

....

You are obviously more interested in attempts to insult or discredit
me than you are to have any sort of technical discussion.

Garrett

I have appreciated your postings, no BS.

You also made me glad now that you did not start mudwrestling with
Richard. ('After a while the bystanders forget, who started. They see
only two pigs in the mud').

I did not quite catch you alert-statement above. Should it be
alert(['document.testform', document.testform]);
?

[dhtml]

optimistx wrote:

dhtml wrote:

>Richard Cornford wrote:

>Garrett

I have appreciated your postings, no BS.

Thank you.

I do my best not to make mistakes and post misinformation, but sometimes
I do make mistakes.

I did not quite catch you alert-statement above. Should it be
alert(['document.testform', document.testform]);
?

It should be:
alert([document.testform, document.forms.testform]);

This would have the result of alert converting the array to a string. It
will work as long as there is no form control with the name or id
"toString".

The same effect as:-

var s = String([1, 2]);
alert(s);

As for a form control with name "toString" This:-
<form><input name="toString"></form>
<script>
alert(document.forms[0]);
</script>

Opera 9.5, Safari 3, Firefox 3
Error

Safari 2 and Mac IE result in the form being converted to a string, such as:
"object FORM"
Garrett

>

[Richard Cornford]

dhtml wrote:

Richard Cornford wrote:

>dhtml wrote:

>>Henry wrote:

<snip>

>>><URL: http://jibbering.com/faq/faq_notes/f....html#faComMis
>

That is a good article, however, it is little outdated.

| In addition to making named FORM elements
| available as named properties of the document.forms
| collection web browsers also make them available as
| named properties of the document object.

Fortunately, that is no longer true in most browsers.

<snip>

In the absence of a rational for "Fortunately", any single cited
example and any evidence/justification for "most" this is most
likely to be dismissed as more of your usual BS.

You probably meant 'rationale'.

I did.

Regardless, that is a loaded statement. It implies that
I usually post BS.

Implies it? I thought "more of your usual BS" said it in as many words.

<form name="testform"></form>
<script>
alert([document.testform, document.testform]);
</script>

Will result in:
Firefox 3, Opera, Safari

object,object

So it is true that browsers still exhibit this old behavior.

So "that is no longer true in most browsers" was an absolutely false
statement then? Not only is it not "no longer true" in "most browsers",
but apparently it is not "no longer true" in any. And presumably as the
wording of the article describes the current reality "it is a little
outdated" was also a false assertion.

I remember testing this previously and getting a different
result, but I modified that test to do something else.

You don't say?

The browser adding form names as properties to the document
creates a bad situation (this is the 'rationale' part).

So this would be the rationale that justified characterising the thing
that never happened as 'fortunate'?

The problem is that can easily creates conflict with existing
properties of the document.

Yes, as mentioned in the document you were erroneously attempting to
'correct'.

When a browser adds a new feature and a new property name
to the document object, document.setTheme, for example, and
a form named 'setTheme' exists, there will be a conflict.

But not a problematic conflict so long as the form element reference
replaces the value of 'new property name' as the document using that
form name could not also attempt to employ a feature that did not exist
at the time of its being authored.

Especially with an object that has as many properties as
document, which vary across many browsers.

Sensible naming convention, such as choosing pertinent names for form
object ("setTheame" doesn't make much sense as the name of a form) and
using non-javascript-like capitalisation (such as initial capital
letters instead of initial lower case) can largely negate the issues.

It's the same problem with having form control names replace
properties of the form. Same rationale except the conflict
exists between form control names and properties on the
FORM element.

Yes, it sounds like the sort of thing that any document on accessing
forms and form controls should mention so people don't stumble into it
unexpectedly.

You are obviously more interested in attempts to insult or

I am not interested in you at all. Stop attempting to waste my time with
irrelevances and nonsense and I will happily ignore you completely.

discredit me

You discredit yourself when you make factually false or redundant posts.

than you are to have any sort of technical discussion.

What sort of technical discussion do you expect to follow from your
making an obviously false statement?

Richard.

[dhtml]

Richard Cornford wrote:

dhtml wrote:

>Richard Cornford wrote:

>>dhtml wrote:
Henry wrote:

[repeats mentioning mistake]

>

>When a browser adds a new feature and a new property name
to the document object, document.setTheme, for example, and
a form named 'setTheme' exists, there will be a conflict.

But not a problematic conflict so long as the form element reference
replaces the value of 'new property name' as the document using that
form name could not also attempt to employ a feature that did not exist
at the time of its being authored.

If the browser were not to replace existing property value the form
element, it would not create a problem.

The browser adding form IDs and Names is poor API design. There is no
question about that. There is no good reason to access a FORM directly
off the document (non-standard) over the document.forms collection
(standard). (The potential fraction of a millisecond saved would is
negligible).

It is possible that accessing the form element directly off the document
will result in accessing a property off the document instead. This will
happen if the document's property value did not get replaced. For exaple:-

<form name="title">

<script>
document.title = 12;
</script>

May result in changing the title of the document in some browsers.
Safari, for one.

Having a blacklist of element names and form control names is problematic.

The problem persists into server APIs which must adopt such naming
conventions as well. For example, a server that were to require a
parameter named "data" would create a conflict, as - data - is a
property in an HTML 5 Form.

>Especially with an object that has as many properties as
document, which vary across many browsers.

Sensible naming convention, such as choosing pertinent names for form
object ("setTheame" doesn't make much sense as the name of a form) and
using non-javascript-like capitalisation (such as initial capital
letters instead of initial lower case) can largely negate the issues.

So the proposal to adopt such naming scheme must also be used by all web
services.

But even that is still not error-proof as there are properties that have
capital letters (ATTRIBUTE_NODE is one).

[more insults]

>
Richard.

[Richard Cornford]

dhtml wrote:

Richard Cornford wrote:

>dhtml wrote:

<snip>

>>When a browser adds a new feature and a new property name
to the document object, document.setTheme, for example, and
a form named 'setTheme' exists, there will be a conflict.

But not a problematic conflict so long as the form element
reference replaces the value of 'new property name' as the
document using that form name could not also attempt to
employ a feature that did not exist at the time of its
being authored.

If the browser were not to replace existing property value
the form element, it would not create a problem.

I have no idea what that is supposed to mean.

The browser adding form IDs and Names is poor API design.
There is no question about that.

That ship sailed a long time ago.

There is no good reason to access a FORM directly off the document
(non-standard) over the document.forms
collection (standard).

None, and you will be hard pressed to find anyone on this group
suggesting anyone does (quite the reverse).

(The potential fraction of a millisecond saved would is negligible).

It is possible that accessing the form element directly off
the document will result in accessing a property off the
document instead.

And the same will go for named images, embeds, applets and anything else
that can be accessed in that way.

This will happen if the document's property value did not
get replaced.

And assuming a perverse/unwise choice of name.

For exaple:-

<form name="title">

And that would be a pretty poor name for a form.

<script>
document.title = 12;
</script>

May result in changing the title of the document in some
browsers. Safari, for one.

Having a blacklist of element names and form control names
is problematic.

The problem persists into server APIs which must adopt
such naming conventions as well. For example, a server
that were to require a parameter named "data" would
create a conflict, as - data - is a property in an HTML
5 Form.

But no issues with "Data".

>>Especially with an object that has as many properties as
document, which vary across many browsers.

Sensible naming convention, such as choosing pertinent names
for form object ("setTheame" doesn't make much sense as the
name of a form) and using non-javascript-like capitalisation
(such as initial capital letters instead of initial lower
case) can largely negate the issues.

So the proposal to adopt such naming scheme must also be
used by all web services.

But even that is still not error-proof as there are properties
that have capital letters

Are there any (or indeed likely to be any) with mixed case and initial
capital letters? Such a property name will go against the grain of all
previous precedent.

(ATTRIBUTE_NODE is one).

If someone is mad enough to name their forms "ATTRIBUTE_NODE" then they
have more problems than will be the result of naming conflicts.

[more insults]

Or observations.

Richard.