This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Summary: Usability and accessibility studies agree that the use of reset buttons on forms brings nothing but misery. They are very easy to hit by accident and will reset the entire form to the state it was on page load. Suggestion: <input type="reset"> and <button type="reset"> should be kept as implementation requirements, but be non-conforming. The validator should raise an error. Extended rationale/Quoting Kornel Lesiński on the mailing list: As far as I'm (Kornel) aware there are no solid use-cases for reset buttons. I have never seen them used correctly. I encounter improper uses of these elements regularly. They are poorly implemented in browsers and their functionality is very limited. There are good, simple alternatives for them. Therefore, I propose to make <input type=reset> and <button type=reset> non-conforming. It might also be worthwhile to let browsers hide such buttons (as if they had display:none). Most often cited case for reset is that there might be a form that needs to be filled in many times with completely different data by the same user (without page refresh, and without need for JavaScript support). This is extremely rare. It only really matters when server responds to the submission with HTTP status 204, however that is often undesireable, as this doesn't allow to indicate submission result to the user. In typical scenarios forms cause page to be reloaded from the server, and server may simply send a new, empty form to the user if that is needed. Authors could also use JavaScript which gives better control over what is reset and to what state and <a href=""> or another submit button as JS-less alternative. Users willing to clear form usually can refresh the page or navigate away and back to it. When server-side validation error occurs, it's considered good practice to pre-fill form with values that user has already typed. In such case <input type=reset> will not reset form to its real initial state, only to intermediate state after reload, which doesn't suit aforementioned use case, and at best is a very poor form of undo without redo (and unnecessary, because browser's undo function could do the same, but better). Reset is not well implemented: browsers don't allow users to undo reset action, and don't ask for confirmation. Unless page author adds such functionality (and I've never seen it done), reset clears entered data immediately and irreversibly. This serious implementation flaw coupled with page authors putting reset in wrong place (next to submit, rather than as first element in the form[1]) and in forms where reset is absolutely not needed, lowers usability of forms and causes data loss[2]. [1] http://www.cs.tut.fi/~jkorpela/forms/imagereset.html [2] "Reset / Cancel Button Considered Harmful" http://www.useit.com/alertbox/20000416.html
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: I agree with the general feeling here, but since we still have to support it (browsers aren't going to just drop support), and since there are some use cases for which it makes some sense (though maybe not many), I think making this non-conforming would have minimal positive impact and might cause some people to start ignoring validators instead. (One use case would be a calculator where you can vary some figures to see the result of a calculation, and reset would reset it back to the defaults.)