Help change HTML5 for the better

Feb 19, 2010

A few weeks ago I came across an unusual "bug" in Opera. I had a form where user action caused a script to change the value of a hidden input form element. It worked pretty well, until the user tried to reset the form using the Reset button.

All of the other form element types reverted to their original source-code values, except for the hidden inputs. They retained the modified values as assigned by the script. This didn't make any sense to me so I was about to report it as a bug until I discovered that Safari, Chrome and Firefox all behave the same way. What was going on here?

It turns out that this is one of those things that browsers have always done, and the reasoning is lost forever in the mists of internet past. Perhaps it's because hidden inputs were never meant to be user editable, but in today's environment of intelligent form processing using javascript and ajax, this inconsistency is set to potentially become a major inconvenience.

In any case, the HTML5 recommendation is just around the corner and one of its aims to document what browsers actually do (in many cases), rather than what they should do. It's been so long since HTML4.01 that we need a new starting point badly, even if that starting point has some flaws.

One of the items that has been documented is this odd behaviour for hidden input elements, inconsistent with the behaviour for all other form elements. In fact, you can't even set the defaultValue of a hidden input; attempting to do so will also change the value, as the two properties are inextricably linked.

So what to do? Well, we could just let it get documented this way. I'll definitely admit that it's not a truly serious issue, and one that arises only in a small number of cases during normal form usage online. On the other hand, it's an inconsistency that should be addressed, and the fact that it probably does only arise in a small number of cases means that changing this may not be a bad thing.

But don't all browsers do it in this unusual way? It will probably be too much hassle to change it.

This is what I initially thought, until I raised the issue with some Opera developers and got some feedback. Hallvord discovered that the behemoth that is every Internet Explorer version from 5 to 8 all handled the hidden input in what appears to be the correct way! If you have a hidden input in IE, set it to a different value by script, then use the reset method, IE will revert the value to the source code value. The plot thickened!

Now instead of being just a "wish-we-could" HTML5 change, the issue became a potential IE compatibility situation. And by the way, I have no idea why I didn't test this in IE before Hallvord took a whack at it. I guess I just thought to myself that there wasn't a chance it could get anything right... ?

Anyway, just having IE support the "correct" behaviour of hidden input elements doesn't mean HTML5 needs to be changed. There are already plenty of things that IE does that we'd rather not have documented! Rather, what would really influence the W3C CSS working group is if another browser such as Opera, Firefox, Chrome or Safari, would make the change on their own because they too thought it was the correct behaviour. The caveat here is that these browser vendors won't make any changes until they are reasonably certain that they won't break (m)any existing sites.

There is a small chance that some sites may rely on this unusual behaviour, but in my view, the behaviour is too obscure and unintuitive to be relied upon. In my opinion, if any web developer were to write a workaround for this issue, it would be much more likely they would modify the Firefox/Opera/Chrome/Safari behaviour to match the sensible IE behaviour. And because these developers can't use the hidden input's defaultValue property for storage (it maps directly to the value property, remember?) it means that any such workarounds they devise will continue to work if the sensible IE behaviour is implemented.

I know what you're thinking: "Sensible" and "IE" in the same sentence? What am I saying! :D But in this one case, it happens to be true. Amazing, ain't it?

So back to the title of this post; we want to change HTML5 so the sensible behaviour for hidden inputs is documented rather than the inconsistent behaviour. How do we do it? Well, here is where you come in. Hallvord has written an Opera user javascript that changes Opera's behaviour on all hidden inputs so it matches the IE behaviour. By installing this script, Opera will behave like IE for this one small case. On any form where the values of hidden inputs are changed and then a reset is called on the form, the IE behaviour will be executed, and a warning message will appear in the status bar.

The point of this is that, if you install this user javascript, the fewer times you see that message in the status bar, the more reason Opera has to make the behaviour a standard feature! This in turn will be a compelling reason for changing the HTML5 specification to match the IE behaviour for hidden inputs!

If you've ever wanted to take part in changing the future of the web, even in a small way, now is your chance! Install the user javascript below, and if nothing happens... great success! :D

The user javascript, written by Hallvord. Much thanks! ;) There is a set of instructions on how to install user javascripts at userjs.org.

If you'd like to see what exactly this user javascript will end up affecting, you can test it on this example form, also written by Hallvord. You might want to try the form before and after installing the user javascript, just to see the behaviour that actually changes.

If you have any problems with forms after installing this script (in theory you shouldn't notice any difference at all) send me an email using my contact form, or post a comment here. With your help, we can change one small part of internet future :) Good luck to us all!


Comments closed

Recent posts

  1. Customize Clipboard Content on Copy: Caveats Dec 2023
  2. Orcinus Site Search now available on Github Apr 2023
  3. Looking for Orca Search 3.0 Beta Testers! Apr 2023
  4. Simple Wheel / Tire Size Calculator Feb 2023
  5. Dr. Presto - Now with MUSIC! Jan 2023
  6. Archive