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: http://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

Comments closed

  • Jan 15, 2010 - 7:05

    # Comment by Hallvord R. M. Steen


    Researching this is a fun challenge and I might try out some things along the lines of http://my.opera.com/hallvors/blog/2009/12/02/new-adventures-in-compatibility-testing :)

    I believe form.reset() isn't used that much, however, I believe you also underestimate the probability of sites setting .value of a hidden input from JS, calling form.reset() and implicitly expecting the value(s) to survive (so not setting them again after reset()).

    Implication of that is that implementing your most logical suggestion can potentially break interaction with any site that both sets values of hidden inputs and uses form reset(), and these sites will be broken in very subtle and hard-to-find/debug ways. I'm reluctant to recommend dploying such a change..

  • Jan 15, 2010 - 7:11

    # Comment by Hallvord R. M. Steen


    (Of course, feel free to start testing that on your own with some User JS! It shouldn't be too hard to write a user script that implements the correct behaviour. HTMLInputElement.prototype.__defineSetter__('value', ...) and so on.)

  • Jan 15, 2010 - 8:15

    # Comment by GreyWyvern


    Hey, I can get on that :) Anything else I can do to help just let me know! For sure I don't want to let the fire on this one go out.

  • Jan 16, 2010 - 5:13

    # Comment by Hallvord R. M. Steen


    Great! :)
    Feel free to use and/or rewrite the Unite services I wrote (linked from the blog post). I'd like to find as many sites as possible that

    a) read or set defaultValue on hidden inputs
    b) call form.reset() after setting value or defaultValue (or even setAttribute('value')) on hidden inputs..

    (Of course we may find no such sites at all.. :))

    I can probably help you out with a big list of URLs by some search criteria for an automated URL player run. Also writing a user JS that you can just keep active during your regular surfing to log such scripts, and potentially upload it and request others to help out would be interesting (after all, the issue we're trying to investigate is quite likely to happen during user input).

    Perhaps also listen to form reset events, to find sites that have INPUT type=reset..

  • Jan 16, 2010 - 5:35

    # Comment by Hallvord R. M. Steen


    IE8 actually disagrees with the spec per my test case (see W3C bug)!

    Strengthens your case considerably, sir :D

  • Jan 16, 2010 - 9:13

    # Comment by GreyWyvern


    I don't know how I missed that :? That's great news!

  • Jan 18, 2010 - 8:20

    # Comment by Hallvord R. M. Steen


    (I think you're supposed to re-open the W3C bug yourself now with the new info. Hope there isn't anything special about that test triggering a weird mode where IE actually does what we think makes sense whereas it normally wouldn't :P)

  • Jan 22, 2010 - 6:10

    # Comment by chris

    Thanksa lot for your min-height tutorial.....It is working perfectly. I was sarching a lot for a good solution. THANKS!!!!!!!!!!!!!!!