Hidden-state input elements and defaultValue
Jan 13, 2010This is the edited text of an email I sent to Ian Hickson regarding a particular point of interest in the upcoming HTML5 recommendation.
Re: https://www.w3.org/Bugs/Public/show_bug.cgi?id=8506
I wanted to make a personal appeal to you regarding this bug touching on your concern that this "is what browsers already do" and thus your conclusion that not much can be done. My position is that enabling the defaultValue
property of the hidden-state input will have minimal (if any) impact on scripts currently in use on the web. I state the following reasons:
- Under the current behaviour,
input.value
references the same value asinput.defaultValue
; if you change one, you automatically change the other, you can't even usedefaultValue
to store the actual default value manually. Thus people (like myself) who do try to usedefaultValue
will notice the behaviour and likely abandon using it. Thevalue
property will return the same value, as well as being syntactically shorter, so by definitiondefaultValue
on hidden-state inputs is thinly used, if at all. - As per #1, since the
defaultValue
property as-is cannot even be used for storage on hidden-state inputs, enabling it (as in other input elements) will not break scripts in which the author provides a work-around using a custom property in the object or global scope. Such workarounds will never use thedefaultValue
property. - There are few legitimate cases I can discern in which someone may rely on the behaviour. For example, a page author may call a
reset()
or individually reset input elements withfoo.value = foo.defaultValue
(in a type agnostic fashion) and expect the hidden-state inputs to retain their value if they have been changed by script. In the corollary cases a) where the hidden-state input is never meant to change (the most common case), or b) the page author has implemented a work-around to bypass the default behaviour, the behaviour of thedefaultValue
property orreset()
action will have no effect on script execution nor form submission. The only affected case is where the page author uses the hidden-state input as permanent storage which he/she expects to survive thereset()
method; such a case assumes the page author a) knows about the behaviour, b) knowing "a", has decided to use a hidden input element rather than a JavaScript variable to hold some data, and c) is using script to change the hidden-state input value before submission. Another such case would be where a page author has knowingly (and perhaps playfully) referenced the hidden-state input's value using thedefaultValue
property rather than the normalvalue
property. Whether such a case is a "legitimate" reliance, however, is questionable.
For these reasons, I believe implementing the defaultValue
property and reset()
behaviour for hidden-state inputs to match other input types is inherently backwards-compatible for the vast majority of DOM scripts currently in use. The web is indeed vast, so chances are good that at least some scripts rely on this behaviour, but due to the reasons above, that number is arguably very very small. It is a situation entirely different from, say, a decree that will send application designers everywhere scrambling to fork their methods in preparation. For the all-but-unanimous majority of scripts being used today, enabling the defaultValue
and reset()
behaviour for hidden-state inputs will have no effect on their execution whatsoever.
As you can probably tell, I am hesitant to mark the bug as CLOSED because I believe implementation, despite being a significant change in itself, would cause very little disruption among scripts and forms already in use. HTML5 has a chance here to make the web a little bit saner in this small area, while avoiding a backward-compatibility incident. I think it is an appropriate chance to take.
⇐ Number vandals at Wikipedia | Clipping Box-Shadow ⇒ |