Hidden-state input elements and defaultValue

Jan 13, 2010

This 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:

1. Under the current behaviour, input.value references the same value as input.defaultValue; if you change one, you automatically change the other, you can't even use defaultValue to store the actual default value manually. Thus people (like myself) who do try to use defaultValue will notice the behaviour and likely abandon using it. The value property will return the same value, as well as being syntactically shorter, so by definition defaultValue on hidden-state inputs is thinly used, if at all.
2. 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 the defaultValue property.
3. 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 defaultValue property or 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 reset() 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 the defaultValue property rather than the normal value 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 ⇒

---