can't reset a hidden field in form

[newbie]

i have a form in which a hidden field (initial value as '0', and my
javascript set it to '1' when an event is trigged).
In the same form, i have a reset field. But I realized that the hidden
field is not reset to '0' when i push the
reset button. If I simply change the node from
"<input type="hidden" id='IsChanged' value='0'>"
to
"<input type="text" id='IsChanged' value='0'>"

Everything is working as expected (the value is reset to '0' when I
push the reset button) Why does this happen?

Thanks

[Randy Webb]

newbie said the following on 8/12/2007 5:26 PM:

i have a form in which a hidden field (initial value as '0', and my
javascript set it to '1' when an event is trigged).
In the same form, i have a reset field. But I realized that the hidden
field is not reset to '0' when i push the
reset button. If I simply change the node from
"<input type="hidden" id='IsChanged' value='0'>"
to
"<input type="text" id='IsChanged' value='0'>"

Everything is working as expected (the value is reset to '0' when I
push the reset button) Why does this happen?

Safari and IE on Windows reset it to 0, Firefox and Opera do not. So I
am going to guess you are testing in Firefox. Why it doesn't reset the
value when you reset the form, I do not know. I do know that if you make
the input type="text" and then use CSS to make it "hidden", then FF and
Opera will reset it:

<input type="text" name="IsChanged " value="0" style="display: hidden">

Then it is "hidden" by CSS but Opera9, FF2.0, IE7 and Safari/Win will
reset it to 0.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Randy Webb]

Evertjan. said the following on 8/12/2007 5:54 PM:

newbie wrote on 12 aug 2007 in comp.lang.javas cript:

>i have a form in which a hidden field (initial value as '0', and my
javascript set it to '1' when an event is trigged).
In the same form, i have a reset field. But I realized that the hidden
field is not reset to '0' when i push the
reset button. If I simply change the node from
"<input type="hidden" id='IsChanged' value='0'>"
to
"<input type="text" id='IsChanged' value='0'>"

Everything is working as expected (the value is reset to '0' when I
push the reset button) Why does this happen?

<snip>

Works fine here [IE7]

Works fine in IE7 and Safari3.0 but not in Firefox1.5/2.0 nor Opera9.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Evertjan.]

RobG wrote on 13 aug 2007 in comp.lang.javas cript:

I think IE7 and Safari3.0 are in error, logically speaking.
Technically it is a question of specification.

Personally, I think IE7 and Safari are right. The user tells the browser
"Reset this form" and that is what the browser does. FF and Opera don't
do what the user asked it to do.

I think you're right.

Resetting the form should set all values back to their initial value
which is set by the value attribute in the HTML. The initial value is
stored in the DOM defaultValue property, resetting the form should set
all controls back to the defaultValue.

Resetting a form should set all controls back to their defaultValue.
I don't see anywhere that programmaticall y changing the value
attribute should change the defaultValue property for hidden controls
only:

<URL: http://www.w3.org/TR/DOM-Level-2-HTM...ml#ID-26091157 >

Specification is not neccessarily logical and
why would you call a hidden field a "control"?

I think that if the clientside js altered a hidden field,
it is the responsability of that js [programmer] to reset it or not
after detecting the user's actions:

<input type='reset'
onclick='return manipulateHidde nFieldsAsRequir ed(this);'>

btw, the whole idea of using the html reset button function in a js
governed form is often not the most versatile solution,
especially in a cross browser environment.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Randy Webb]

Evertjan. said the following on 8/13/2007 3:40 AM:

RobG wrote on 13 aug 2007 in comp.lang.javas cript:

>>>I think IE7 and Safari3.0 are in error, logically speaking.
Technicall y it is a question of specification.
Personally, I think IE7 and Safari are right. The user tells the browser
"Reset this form" and that is what the browser does. FF and Opera don't
do what the user asked it to do.

I think you're right.

Resetting the form should set all values back to their initial value
which is set by the value attribute in the HTML. The initial value is
stored in the DOM defaultValue property, resetting the form should set
all controls back to the defaultValue.

Resetting a form should set all controls back to their defaultValue.
I don't see anywhere that programmaticall y changing the value
attribute should change the defaultValue property for hidden controls
only:

<URL: http://www.w3.org/TR/DOM-Level-2-HTM...ml#ID-26091157 >

Specification is not neccessarily logical and
why would you call a hidden field a "control"?

Because that is what it has come to be called. Rather than a "form
field" it is commonly called a "control".

I think that if the clientside js altered a hidden field,
it is the responsability of that js [programmer] to reset it or not
after detecting the user's actions:
<input type='reset'
onclick='return manipulateHidde nFieldsAsRequir ed(this);'>

That I disagree with. If the user wants the form Reset, then it should
be reset *to the state it was in when the form was loaded*. If you want
to track users actions, the simplest way is to put it outside the
current form. Then onsubmit read it into your current form and submit
it. Then you bypass the reset buttons.

BTW, Firefox doesn't "reset" a form if you do a Refresh of the page,
which I also think is dead wrong behavior. And it has nothing to do with
whether JS modified the page or not.

btw, the whole idea of using the html reset button function in a js
governed form is often not the most versatile solution,
especially in a cross browser environment.

I would think that the idea of having a JS controlled form to begin with
would often not be the "most versatile" solution, would it?

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[RobG]

Evertjan. wrote:

RobG wrote on 13 aug 2007 in comp.lang.javas cript:

I think IE7 and Safari3.0 are in error, logically speaking.
Technically it is a question of specification.

Personally, I think IE7 and Safari are right. The user tells the browser
"Reset this form" and that is what the browser does. FF and Opera don't
do what the user asked it to do.

I think you're right.

Resetting the form should set all values back to their initial value
which is set by the value attribute in the HTML. The initial value is
stored in the DOM defaultValue property, resetting the form should set
all controls back to the defaultValue.

Resetting a form should set all controls back to their defaultValue.
I don't see anywhere that programmaticall y changing the value
attribute should change the defaultValue property for hidden controls
only:

<URL: http://www.w3.org/TR/DOM-Level-2-HTM...ml#ID-26091157 >

Specification is not neccessarily logical and
why would you call a hidden field a "control"?' '

Because that is what it is:

<URL: http://www.w3.org/TR/html4/interact/...hidden-control >

I think that if the clientside js altered a hidden field,
it is the responsability of that js [programmer] to reset it or not
after detecting the user's actions:

That is purely your opinion and seems at odds with the specification:

"Each control has both an initial value and a current value, both of
which are character strings... ... a control's "initial value" may be
specified with the control element's value attribute...

"The control's "current value" is first set to the initial value.
Thereafter, the control's current value may be modified through user
interaction and scripts.

"A control's initial value does not change. Thus, when a form is
reset, each control's current value is reset to its initial value. If
a control does not have an initial value, the effect of a form reset
on that control is undefined."

<URL: http://www.w3.org/TR/html4/interact/forms.html#h-17.2 >

I can't see how anyone can interpret that as requiring hidden controls
that have been modified by script to also be reset by script.

<input type='reset'
onclick='return manipulateHidde nFieldsAsRequir ed(this);'>

btw, the whole idea of using the html reset button function in a js
governed form is often not the most versatile solution,
especially in a cross browser environment.

Perhaps, depending on the situation. But that is not the issue here,
it is that some browsers do not reset controls to their initial value
when the W3C specification states that they should.
--
Rob

[Evertjan.]

Randy Webb wrote on 13 aug 2007 in comp.lang.javas cript:

>Specificatio n is not neccessarily logical and
why would you call a hidden field a "control"?

Because that is what it has come to be called. Rather than a "form
field" it is commonly called a "control".

A hidden "control" in the <input type=hiddensens e
is not a control at all.

It is not even a field.

It is just a form element, and if submitted, a form parameter.

To do silly "control" things with it, like having the user reset it without
that user knowing what he or she is resetting, just because you call it a
controll, seeems an uncontrollable error to me.

A reset is ment. meseems, to help the user restart the manual form entry
from scratch.

How can he or she repopulate an hidden "field"?

Say the hidden field is filled with the client date/time by js,
it should not be reset to the possibly empty start value, but kept or
repopulated with the acutal time. That would be the js'es job.

In short, resetting a hidden formfield value by the html reset function may
be according to specs, but is illogical. Misnaming it a "control" dos not
influence this logic.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Evertjan.]

RobG wrote on 13 aug 2007 in comp.lang.javas cript:

>
Evertjan. wrote:

>RobG wrote on 13 aug 2007 in comp.lang.javas cript:

I think IE7 and Safari3.0 are in error, logically speaking.
Technically it is a question of specification.

Personally, I think IE7 and Safari are right. The user tells the
browser "Reset this form" and that is what the browser does. FF
and Opera don't do what the user asked it to do.

I think you're right.

Resetting the form should set all values back to their initial
value which is set by the value attribute in the HTML. The initial
value is stored in the DOM defaultValue property, resetting the
form should set all controls back to the defaultValue.

Resetting a form should set all controls back to their
defaultValue. I don't see anywhere that programmaticall y changing
the value attribute should change the defaultValue property for
hidden controls only:

<URL: http://www.w3.org/TR/DOM-Level-2-HTM...ml#ID-26091157 >

Specificatio n is not neccessarily logical and
why would you call a hidden field a "control"?' '

Because that is what it is:

<URL: http://www.w3.org/TR/html4/interact/...hidden-control >

No.

That is what some secification siys it could be names.

Naming a control you cannot control a control only makes me laugh
uncontrollably.

I specified the difference between logic and specification,
so arguing it must be logical, since it is speciefied that way is
illogical argumentation.

>

>I think that if the clientside js altered a hidden field,
it is the responsability of that js [programmer] to reset it or not
after detecting the user's actions:

That is purely your opinion and seems at odds with the specification:

Again:
I specified the difference between logic and specification,
so arguing it must be logical, and that it is specified that way is
illogical argumentation.

"Each control has both an initial value and a current value, both of
which are character strings... ... a control's "initial value" may be
specified with the control element's value attribute...

"The control's "current value" is first set to the initial value.
Thereafter, the control's current value may be modified through user
interaction and scripts.

"A control's initial value does not change. Thus, when a form is
reset, each control's current value is reset to its initial value. If
a control does not have an initial value, the effect of a form reset
on that control is undefined."

<URL: http://www.w3.org/TR/html4/interact/forms.html#h-17.2 >

I can't see how anyone can interpret that as requiring hidden controls
that have been modified by script to also be reset by script.

Again:
I specified the difference between logic and specification,
so arguing it must be logical, and that is specified that way is
illogical argumentation.

>

><input type='reset'
onclick='retur n manipulateHidde nFieldsAsRequir ed(this);'>

btw, the whole idea of using the html reset button function in a js
governed form is often not the most versatile solution,
especially in a cross browser environment.

Perhaps, depending on the situation. But that is not the issue here,
it is that some browsers do not reset controls to their initial value
when the W3C specification states that they should.

The issue is that I specified the difference between logic and
specification, so arguing it must be logical, and that is specified that
way is illogical argumentation.

You may be defining "the issue" otherwise, but that was not what I was
arguing.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Evertjan.]

Evertjan. wrote on 13 aug 2007 in comp.lang.javas cript:

That is what some secification siys it could be names.

Since there is no bug in my keyboard,
it must have been me that wrote that ;-(

I ment:
That is what some specification says it could be named.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Randy Webb]

Evertjan. said the following on 8/13/2007 5:02 AM:

Randy Webb wrote on 13 aug 2007 in comp.lang.javas cript:

>>Specificati on is not neccessarily logical and
why would you call a hidden field a "control"?

Because that is what it has come to be called. Rather than a "form
field" it is commonly called a "control".

A hidden "control" in the <input type=hiddensens e
is not a control at all.

It doesn't matter to me whether you call it a control, a form element,
or a hotdog. If it is part of the form and you reset the form, then the
form should be reset to the state it was in when the form was loaded.
Otherwise, you have a broken reset button.

It is not even a field.

Sure it is. It is just hidden is all.

It is just a form element, and if submitted, a form parameter.
To do silly "control" things with it, like having the user reset it without
that user knowing what he or she is resetting, just because you call it a
controll, seeems an uncontrollable error to me.

Call it what you want, it doesn't change anything. If a user wants to
reset a form, then it should reset the form. Period. But, doing "silly
things" with it like trying to maintain a false state after reset/reload
is the silly thing to try to do.

A reset is ment. meseems, to help the user restart the manual form entry
from scratch.

Not according to the W3C (which I don't much care for).

How can he or she repopulate an hidden "field"?
Say the hidden field is filled with the client date/time by js,
it should not be reset to the possibly empty start value, but kept or
repopulated with the acutal time. That would be the js'es job.

Then don't make it part of that particular form at the time. Use the
onsubmit event handler of the form and set the input's value. Then you
have no worry whatsoever whether it was reset or not.

In short, resetting a hidden formfield value by the html reset function may
be according to specs, but is illogical. Misnaming it a "control" dos not
influence this logic.

Whether it is illogical or not is a personal opinion. And no matter what
that opinion is (mine, yours or anybody else's), the behavior is easily
worked around and when there is a trivial solution then it seems moot to
even worry about it.

Want an input that reset doesn't interfere with? (Your "client date/time"):

var myVariableThatR esettingTheForm WontEverChange = new Date();

<form
onsubmit="this. form.inputThatC anBeResetButWil lHaveTheValueIW antInItWhenTheF ormGetsSubmitte d.value=myVaria bleThatResettin gTheFormWontEve rChange">

Now, how will resetting the form change/impact what that hidden fields
value is?

Just don't let the "I hate MS" crowd know IE got it right and Firefox
got it wrong.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/