- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 16 Dec 2009 15:20:06 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8506 Summary: 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 insta Product: HTML WG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current- work/#hidden-state OS/Version: other Status: NEW Severity: normal Priority: P3 Component: HTML5 spec bugs AssignedTo: dave.null@w3.org ReportedBy: contributor@whatwg.org QAContact: public-html-bugzilla@w3.org CC: ian@hixie.ch, mike@w3.org, public-html@w3.org 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 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 16 December 2009 15:20:18 UTC