Fix HTML5: help us test hidden input default value change

Web developer and long-time Opera user Brian Huisman has discovered one of those small and sometimes annoying inconsistencies in the web platform: a hidden input has no default value, and is thus not reset to its original value if you do form.reset(). For some reason, Gecko/Firefox, WebKit/Safari/Chrome and Opera all implement this quirky behaviour. If any reader knows why, a small history lesson would be pretty interesting!

However, in IE hidden inputs are consistent with other types of input, and are reset with the rest of the form. This seems like the behaviour you would expect when calling form.reset() or clicking a "reset" button, no?

I assume most people would agree that a consistent behaviour for both input type=text and input type=hidden is desirable. The major question is whether browser vendors can safely stop special-casing hidden inputs. Ian Hickson, the HTML5 editor, leaves it to the browser vendors and tells Brian to go convince them first. Obviously, I'm wearing a browser vendor quality assurance hat, so who am I to argue against that? 🙂

It would still be nice to be consistent. If only we somehow knew that we would not break existing sites by changing this..

Now, this is where you come in. By adding the defaultValue User JavaScript to Opera you can test the more consistent behaviour and tell us if you notice any broken sites. (If anyone writes a GreaseMonkey-compatible version, that would be great!) I'm also pondering shipping this in browser.js for beta and preview versions to get more test mileage – it's pretty interesting that we can use browser.js for compatibility research and test out implementation changes that we would like to be able to revert easily if we discover problems ;).

The effect of this User JavaScript should change the first two tests on Brian's test page from fail to pass. Like this:


From left to right: Firefox, Chrome, IE8, Opera without User JS running, Opera with User JS running.

Let us know in the comments what behaviour you find better, and whether you find any broken sites!

Advertisements

20 thoughts on “Fix HTML5: help us test hidden input default value change

  1. You should package the userjs up as an extension (obviously hosting it from here and not the official gallery) so no one has an excuse to not test it. :PEDIT:Or if anyone knows how to package it properly, I can host it temporarily or indefinitely from a directory I've already setup for extensions. Just PM me. 😉

  2. I think the logic in general is most of the time, hidden elements aren't changed.. so resetting them often means "doing nothing". Sometimes JS changes hidden inputs and that's the only time it would come into play. It seems like a very corner case. Most forms don't even have reset buttons these days. How often do you reset a form? Often you just fix your few mistakes instead. This is very, very corner case.

  3. Originally posted by remcolanting:

    I packaged it as extension for anyone wanting it. You can find it on http://oex.r3m.coIt makes the first two tests on the testpage pass, so I'm assuming it works right

    The way I understand the picture shown above, the first three tests should pass. This is also what I experience when using your extension. The only thing for me is, that test #5 never gets out of "testing…" status.

  4. Thanks Remco :DAlso, the first 3 pass for me as shown in the screenshot, but the last one never finishes. It may be a userjs I've already installed.

  5. Originally posted by ouzoWTF:

    The way I understand the picture shown above, the first three tests should pass. This is also what I experience when using your extension. The only thing for me is, that test #5 never gets out of "testing…" status.

    Originally posted by kyleabaker:

    Also, the first 3 pass for me as shown in the screenshot, but the last one never finishes. It may be a userjs I've already installed.

    It had to do with window not being the default scope in extension userjs, so it couldn't find Element. Adding "window." in front seems to have cured the problem. The new version is already on the server.

  6. Originally posted by remcolanting:

    It had to do with window not being the default scope in extension userjs, so it couldn't find Element. Adding "window." in front seems to have cured the problem. The new version is already on the server.

    After cleaning cache and downloading the new version this now works. Thanks.

  7. Originally posted by fearphage:

    This is very, very corner case.

    It certainly is. But what behaviour would you, as a web developer and JS author expect?

  8. Hi Hallvord! I find it interesting that the spec [1] says: "When activated, a reset button resets all controls to their initial values." I guess it's up for debate if default value == initial value, but I don't think it is. I'd say initial value is the value the (in this case) hidden input had at page load completion.So as your average web developer, I'd expect form.reset() to set the hidden input value to the initial value or "least recent known value" or whatever you would like to call it. :)[1] http://www.w3.org/TR/html401/interact/forms.html#reset-button

  9. Originally posted by Hallvord R. M. Steen:

    what behaviour would you, as a web developer and JS author expect?

    I expect the behavior to be explicit. I expect Form#reset to reset the form to exactly how it was when the page loaded… this would include 100% of inputs no matter the type, color, size, or anything else.

  10. Anonymous writes:i also would expect that all controlls are reset to f5 state. ||but.. im not exactly sure that this stuff should be changed or touched at all. if you do not know what to do, please, fix your key event handling. ||pages that should be mostly affected are old legacy airline booking services. but the heaviest hidden input user (ms sharepoint etc services) work perfectly in firefox, so a) .reset() is not used b) ms webdevelopers knew this little fact. i bet on a) (i never used it myself when i actively coded the web)

  11. I suspect that some developers use hidden inputs to store a form of simple token in a page? Especially if it requires no special permissions, and does not reset when fields in-page are altered.Poorly written web applications would be a principle culprit here, anything else seem likely? (Such as an airline website that stores a session value to hidden input, but lets you reset the visible form if you've made a mistake?) Though since IE actually resets this, small sites are more likely to have the problem than bigger ones…unless IE has another hidden complexity that "sometimes" preserves the stored info. @_@

  12. "a hidden input has no default value, and is thus not reset to its original value if you do form.reset()."If sites works with the current behavior, wouldn't changing it only cause potential problems for no real benefit?

  13. Originally posted by Qyngali:

    If sites works with the current behavior, wouldn't changing it only cause potential problems for no real benefit?

    That's what you'd think, except IE exhibits the "correct" behaviour. Because of that fact any web form in the wild which relied on either one behaviour or the other, would have to include a complex workaround to account for the browser(s) which behaved differently.The hypothesis then, is that rather than making workarounds, form authors just avoid the problem altogether by not using hidden inputs for persistent storage. If this is the case, switching to the "correct" behaviour should have minimal (if any) effect on existing web scripts.Installing this user javascript will help Opera make an estimate of how many sites out there actually DO rely on the behaviour. Hopefully it is none, or a very very small number.

  14. I actually still think the ideal solution would be for all five tests to pass. However, tests four and five also fail for inputs of other types (like "text") in Opera/Chrome/Firefox (but not IE), so the scope of effect for THAT change would be much larger, and may not be feasible. IOW, potentially more sites would rely on the behaviour.But we can always hope! 🙂 The fact that so many people still use IE and that tests 4 and 5 pass there shows that there can be no inter-operative script in the wild that depends on the behaviour without also using a workaround fork.Tests 4 and 5 test whether the .value property and .getAttribute('value') remain unchanged when a new .defaultValue is set. A PASS means they did not change.

  15. Anonymous writes:ENTIRE .net web platform relies on hidden input to hold viewstate. it by default works in opera. and in all other browsers because: who cares what behaviour is good when noone uses .reset() anyway? || opera, you had some long time ago automated crawler that roamed the net and gathered various statistics (MOMA? some M-sounding acronym). just use it to tel if there is anybody that uses reset() anyway. because – if i understand correctly – it ONLY happens when one press reset button (who uses them?!?!) or .reset() is called some other way. just leave it alone, let it rot. just fix this prototype.bind already.. :/

  16. Anyone able to set up a .NET demo with a form and a reset button?The way I think .NET sites work is that viewstate is hardcoded in the markup delivered from the server, potentially also changed by scripts when a form is submitted. (In this case we don't really need to worry much about .reset()). If a .NET app contains scripts that continuously changes viewstate while you're interacting with the page, plus a reset feature, we might have reasons for concern. However, since we're looking at differing browser implementations, .NET sites must either* Not use input type=reset or form.reset() at all, sidestepping the incompatibilityor* Have code to handle the browser differenceAnyone knows if .NET has code to work around this, and prefer one or the other behaviour?

  17. Anonymous writes:i do not know NET from this perspective, but: by default NET pages DO NOT have 'reset' button. you have to do more than minimal work to add something like this. viewstate is hardcoded when loaded, but then any manipulation (depends on configuration, because it affects performance) changes it via javascript. it was long ago when i last programmed using NET, but i NEVER used any kind of 'reset' functionality. so i presume it is the first scenario. another point to look is sharepoint (opera by default does not work with it, but it is another NET-like form based app, 2010 is 100% NET app). as i wrote before – only place that comes to mind are OLD legacy booking services that 'just work' – national railways, national airlines or ferry services. in their cases i expect to see code from 1995, and then reset button was popular.|| anyway id suggest letting it live, it is consistently incosistent, dont break it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s