Hidden-state input elements and defaultValueJan 13, 2010
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.valuereferences the same value as
input.defaultValue; if you change one, you automatically change the other, you can't even use
defaultValueto store the actual default value manually. Thus people (like myself) who do try to use
defaultValuewill notice the behaviour and likely abandon using it. The
valueproperty will return the same value, as well as being syntactically shorter, so by definition
defaultValueon hidden-state inputs is thinly used, if at all.
- As per #1, since the
defaultValueproperty 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 the
- 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 with
foo.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 the
reset()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 the
Another such case would be where a page author has knowingly (and perhaps playfully) referenced the hidden-state input's value using the
defaultValueproperty rather than the normal
valueproperty. 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
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 ⇒|