[Bug 8506] New: 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

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