This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 8506 - The value of a hidden-state input element as defined here does not have a concept of a defaultValue.
Summary: The value of a hidden-state input element as defined here does not have a con...
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: LC
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-16 15:20 UTC by contributor
Modified: 2010-11-11 06:45 UTC (History)
6 users (show)

See Also:

Attachments
Test case ("pass" means an implementation consistent with other input types, "fail" means complying with the existing HTML5 prose) (743 bytes, text/html)
2010-01-16 10:34 UTC, Hallvord R. M. Steen 		Details

Description contributor 2009-12-16 15:20:06 UTC 
Section: http://www.whatwg.org/specs/web-apps/current-work/#hidden-state

Comment:
The value of a hidden-state input element as defined here does not have a
concept of a defaultValue.  Setting either the value or the defaultValue will
both result in changing of the value since both are direct access to the
attribute rather than an instantaneous user-modifiable value.  In the case
where no scripting is involved, this isn't an issue as the user will never
change the value of the hidden-state element before the form is submitted. 
However, when a "form-artist" begins adding complex scripting controls to
his/her forms, one of those controls may be modifying the values of
hidden-state inputs to match, eg: combinations of user inputs, or input that
can't be described using existing HTML form controls.  A serious issue arises
because the value of a hidden-state input is read/write just like the states
of other input types, however once changed, there is no way to recall the
original value; neither through defaultValue nor the .reset() method.  This
difference in behaviour between the hidden-state and other input element
states is not intuitive.  There is no practical purpose in cutting off a
hidden-state input from what essentially is its history via the defaultValue
property.  I cannot conceive of any situation in which a scripter would want
their hidden-state form elements to forget their original source-derived
values, or to be excepted from the form .reset() method.  In fact, because of
this behaviour, the form .reset() method is no longer a strict reset to the
form's original state, because hidden-state elements which may have been
changed through scripting as an indirect result of user action, will retain
the values from before the reset.  Ergo, the form is still tainted with user
interaction, even after the reset.  This will result in incorrect information
being sent on submission, or require the scripter to add special cases not
only to "reset" the hidden-state elements, but also pre-store their original
values so it is actually possible to reset them.  In conclusion, I don't see
any negative consequences in making hidden-state elements behave like other
form element states, having both a value and defaultValue and obeying the
.reset() method.  Actually, when thought of critically, the current defined
behaviour of the hidden-state element is essentially a limitation of function
for no discernable reason.  Thanks for your attention.	Brian Huisman
(GreyWyvern)

Posted from: 76.71.53.105
Comment 1 Ian 'Hixie' Hickson 2010-01-10 11:17:51 UTC 
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: As much as I agree with the points raised, unfortunately, what the spec describes is what browsers already do. There is therefore not much room for us to make the spec more sensible on this front.

Incidentally, my hat is off to you for being able to write such a long missive in such a small text box. :-)
Comment 2 Hallvord R. M. Steen 2010-01-16 10:33:11 UTC 
Since this test passes in IE:
http://hallvord.com/opera/bugs/CORE-7516.htm
..it seems IE does not behave like this bug claims "browsers already do". Where major browsers disagree we can go for the logical and consistent behaviour, no? If we conclude it doesn't cause compatibility problems I'm pretty certain we (Opera) would be happy to change it and stop special-casing hidden inputs.
Comment 3 Hallvord R. M. Steen 2010-01-16 10:34:29 UTC 
Created attachment 803 [details]
Test case ("pass" means an implementation consistent with other input types, "fail" means complying with the existing HTML5 prose)
Comment 4 Brian Huisman 2010-01-16 14:17:13 UTC 
I can't believe I missed that.  Thanks Hallvord!

IETester displays the PASSED message also in IE7, IE6 and IE5.5.  Should this be reopened? :)
Comment 5 Brian Huisman 2010-01-18 13:45:16 UTC 
Reopening this issue due to the fact that the behaviour is already implemented in several Internet Explorer versions up to IE8.  Surely this is evidence that such a change in other browsers would be possible without much (or any) disruption to existing online scripts.
Comment 6 Ian 'Hixie' Hickson 2010-02-13 10:56:39 UTC 
Only IE does this. When all the browsers except IE do something, it's often the case that browsers depend on both behaviours, and use scripts to detect IE and handle IE differently from the others.

Unless you can convince Firefox and Safari to change to match IE, I do not think changing this to match IE (and no other browser) is a good idea.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: Tests show that this is what (most) browsers already do.
Comment 7 Ian 'Hixie' Hickson 2010-11-11 06:45:58 UTC 
(In reply to comment #6)
> Only IE does this. When all the browsers except IE do something, it's often the
> case that browsers depend on both behaviours [...]

For the record, I meant "that *pages* depend..."