Is onforminput Deprecated in HTML5 Forms? (And Why Should I Care Anyways?)

May 10th, 2011 by zoltan · 6 Comments


Newer versions of all browsers support the form element’s oninput attribute, which replaces the functionality of onforminput, and as a result I wrote a related article Fixing oninput in IE Using html5Widgets. Thanks to Rob Crowther for setting me straight and providing a great example, which I have forked to work for IE9. I will refactor html5Widgets to support oninput in IE very soon. I will leave this article as is for the benefit of anyone who is Googling for onforminput and why it was deprecated.

I was just doing some regression testing on html5Widgets, and noticed that the onforminput event wasn’t working in Firefox 4. This didn’t make sense to me: I designed html5Widgets to detect if the output tag is supported, and if not, add support for it. I believed that if a browser supported the output tag, it also had to support the onforminput event, since I assumed that this was one of the main reasons of having the output tag in the first place. However, Firefox 4 supports the output tag, but doesn’t support onforminput. After doing a bit of light research, I came across this this bug report that seems to indicate that onforminput is deprecated. This article will discuss what onforminput does, why it is very useful to designers are not so strong in JavaScript, how one can add support for onforminput to browsers that don’t, and why I really hope someone in power adds it back to the HTML5 Forms specification, or at least something very similar.

Why Do I Care

For those that don’t know what this is, onforminput is an attribute that a web author can use on the output tag to do some calculations with the values in a form’s input fields and show that calculation to a user. Right now, Opera is the only browser that natively supports it, but in an earlier post I showed how one could use it with my html5Widgets polyfill library in all the other browsers. How does it work? To illustrate a very simple use case, let’s say I have a range input field:

HTML Output
  Darkness Level:
  <input type="range" name="darkness"
         value="0" min="0" max="255" />
Darkness Level:

(Note the range element is polyfilled with html5Widgets if your browser doesn’t support it).

The range input type is a slider widget, and we use it here so the user can choose a number between 0 and 255. The slider looks cool, but from a usability standpoint, there is no feedback of what value the user is sliding to. It would make more sense to show a number next to the slider. which gives feedback to the user as to what the slider’s value is. This is where onforminput comes in:

HTML Output
  Darkness Level:
  <input type="range"
     value="0" min="0" max="255" />
     onforminput="this.value = darkness.value"
  >0</output> / 255

Darkness Level: 0 / 255

Immediate user feedback! Great user experience! And simple syntax! Even a person who is not familiar with JavaScript can figure it out. But it’s deprecated! So, even though the output tag is supported by Firefox 4, onforminput is not. Oh-noes!!!!

Luckily, my html5Widgets library adds support for it in browsers that don’t, including Firefox 4. I just made a small change that worked around an issue preventing Firefox from supporting it, and BAM! Instant support.

Another good (and common) example for using output would be a form for an online tool that calculates a total automatically. Enter in values into the following form and see the calculations magically appear:

Tax: 0
Total: 0

But, why is it depreciated in the first place?

It seems the decision has been made to remove onforminput from the HTML5 specification since it’s purpose can be easily done with capturing events (at least, that’s what I understood from this thread about onforminput and onformchange on the public-webapps mailing list).

While this is true, I think keeping it in would be a huge help to designers and developers. I even think that having it declared inline like I do in the code examples above is useful. Even though it breaks the separation of document structure and behavior, it allows a developer with practically no JavaScript knowledge to implement this simple feature in a form. According to the Bug Report, designers shouldn’t have to use onforminput since they can do this instead:

<form name="f1">
Darkness Level:
<script type="text/javascript"> document.addEventListener("input", function(e) { if (document.forms.f1 == = parseFloat(; }, true); </script>
<input type="range" name="darkness" value="0" min="0" max="255" /> <output name="output"> </form>

This is uglier than your Mom’s mood when you don’t call her on Mother’s Day (not that I’m speaking from any recent experience). Even though it is dead easy for a JavaScript programmer to implement this without onforminput, some web designers wouldn’t have the knowledge or the patience to do so. This is not a slight to those designers — after all, they can probably make better looking web pages than the average programmer. So I am keeping onforminput in html5Widgets. It is really convenient and easy to understand.

A Note To Those In Power

To anyone at the W3C who has the power to do so, I am politely asking to reconsider and please put onforminput back into the specification or at least replace it with something just as simple (the latter being attractive to those who want to continue separating the structure of the document (i.e. HTML) from the behavior (i.e. JavaScript)). As mention in the update on the top of the page, oninput is a great replacement for onforminput and it works in all modern browsers.

In my humble opinion, creating calculations the old-fashioned way with events and lines and lines of JavaScript is painful for designers who aren’t scripters. After all, isn’t this the reason why required and pattern were created?

Download the latest version of html5Forms.js, which includes HTML5Widgets with onforminput support, from github

Tags: Events · Events · Forms · HTML · HTML5 · Polyfills

6 responses so far ↓
  • 1 Rob Crowther // May 10, 2011 at 7:24 pm

    You can still capture declaratively:

    <form name=”f1″ oninput=”output.value = parseFloat(darkness.value);”>
    Darkness Level:
    <input type=”range” name=”darkness” value=”0″ min=”0″ max=”255″>
    <output name=”output”>

    Not sure how code will work out on your comments, here’s a JSFiddle:

  • 2 zoltan // May 10, 2011 at 8:15 pm

    Excellent! Works in all browsers except for IE … I will have to work on adding support for this in html5Widgets. Thanks for the correction on this.

  • 3 zoltan // May 10, 2011 at 8:25 pm

    Actually … it looks like IE9 supports it … but it is necessary to refactor the code slightly for it:

    <form name=”f1″ oninput=”document.getElementById(‘output’).innerHTML = parseFloat(darkness.value);”>
    Darkness Level:
    <input type=”range” name=”darkness” value=”0″ min=”0″ max=”255″>
    <output id=”output”>

    It can be seen in action as a fork of your fiddle here:

    Thanks for the info. I will still be adding support for older browsers in html5Widgets, but I am really happy something native works today in modern ones. :-)

  • 4 Rob Crowther // May 10, 2011 at 9:44 pm

    The ability to add oninput to any element is the main argument behind dropping onforminput – it should work in any browser which supports the output element. I’ve had trouble with name.value myself in some browsers, but I only checked the code in Firefox 4 :)

  • 5 Paul Irish // May 11, 2011 at 1:42 am

    While we’re on the topic, let me link up the biggest resource I know of research on `oninput` :

  • 6 zoltan // May 11, 2011 at 11:02 am

    @Paul: thanks for the tip. The research there will definitely help with making the polyfill for oninput.

Give Feedback

Don't be shy! Give feedback and join the discussion.

Please Note: If you are asking for help using the information on this page or if you are reporting a bug with the code featured here, please include a URL that shows the problem you are experiencing along with the browser/version number/operating system combination where the issue manifests itself. Without this information, I may not be able to respond.

An orange star denotes a required field.