14870 2011-11-18 01:20:40 +0000 autosubmit attribute for form elements 2013-05-08 13:51:48 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified All All RESOLVED NEEDSINFO a11y P2 enhancement --- 1 david david cooper eoconnor everett ian jfoliot mark.sadecki+w3c mike plh public-html-a11y public-html-admin public-html-wg-issue-tracking therandshow public-html-bugzilla oldest_to_newest 60129 0 david 2011-11-18 01:20:40 +0000 Currently javascript is frequently used to submit simple html forms with a small number of controls. Implementing an autosubmit boolean attribute for all form elements would eliminate the need to use javascrpt's onchange method to call a form's submit method and provide a better user experience especially on mobile devices. One use case would be a simple search form like so: <form> Search terms: <input type="search" name="search_terms" autosubmit> <input type="submit"> </form> Once the user has enter their data using a touch keyboard on a mobile device and tapped "done" to close the keyboard the form would be automatically submitted with the user needing to tap the submit button. The above use case is most useful for mobile devices while placing an autosubmit attribute on a <select> element for paginating content would be useful for any device: <form action="content"> Page: <select name="page" autosubmit> <option>1</option> <option>2</option> <option>3</option> <option>4</option> <option>5</option> ... </select> <input type="submit"> </form> Once the user selected a different option the form would auto-submit and the chosen page would be displayed. There are many sites that currently use javascript and onchange events to autosubmit such forms used for pagination. Other possible use cases would be a survey asked one multiple choice question per page. Each question could be answered by simply selecting the appropriate radio button without needed to click submit. Like so: <form> What gender are you? <label><input name="gender" value="male" type="radio" autosubmit >Male</label> <label><input name="gender" value="female" type="radio" autosubmit >Female</label> </form> In the above case it might be better also define an autosubmit attribute for the form element itself. This would make the form auto-submit if any of it's elements were changed and eliminate the need to specify autosubmit for each element in the form as above. Other use cases would be <input type="file" autosubmit> which would submit the form once a file is selected by the browser. This attribute was previously proposed for menu elements: http://www.w3.org/TR/2008/WD-html5-20080610/interactive-elements.html#menu and there was a little discussion about it: http://lists.w3.org/Archives/Public/public-html/2007Sep/0315.html I'm not entirely sure why it was removed from the spec, other than the fact that it was more appropriate for form elements. 60130 1 everett 2011-11-18 01:40:43 +0000 From what I can tell from the bug description, this is a request to add an @autosubmit boolean attribute to all form input elements. If @autosubmit is set on an input element then an action that would have the element fire an onchange event would automatically submit the form that owns the element. WCAG 2.0 success criteria 3.2.2 "On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)" http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html 60176 2 david 2011-11-20 05:19:58 +0000 Yes, that is exactly what I was attempting to describe. I can understand the concern with causing an unpredictable context change. However, in the case of a form with only one element such a select list the submit button could be omitted in which case a context change wouldn't be unexpected. 60349 3 therandshow 2011-11-22 14:37:50 +0000 (In reply to comment #1) > From what I can tell from the bug description, this is a request to add an > @autosubmit boolean attribute to all form input elements. If @autosubmit is set > on an input element then an action that would have the element fire an onchange > event would automatically submit the form that owns the element. > > WCAG 2.0 success criteria 3.2.2 > "On Input: Changing the setting of any user interface component does not > automatically cause a change of context unless the user has been advised of the > behavior before using the component. (Level A)" > > http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html The key element here should be unpredictable. For example, sometimes sorting controls (especially in js-free environments) are represented as form elements. I think most users would expect a simple sorter (such as an arrow button next to a table header) to autosubmit. Likewise with paging controls. In addition, consider a corporate environment where web pages may be modeled after certain desktop applications. If that application autosubmits, then the user will likely expect the web page to do likewise. If I may make a bad pun, sometimes what is unpredictable to the user is not always predictable. 60354 4 everett 2011-11-22 16:10:26 +0000 The HTML Accessibility Task Force will track this bug to ensure that there are no negative implications for accessibility. 61132 5 ian 2011-12-07 21:13:09 +0000 We actually had an "autosubmit" feature in an earlier draft, but didn't keep it (I forget why). 81704 6 robin 2013-01-21 15:59:04 +0000 Mass move to "HTML WG" 81822 7 robin 2013-01-21 16:01:49 +0000 Mass move to "HTML WG" 83685 8 eoconnor 2013-02-25 22:58:23 +0000 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: Additional Information Needed Change Description: No spec change. Rationale: As Ian noted in comment 5, we used to have such a feature, but dropped it. Would you be interested in pursuing such a feature in an extension specification? http://www.w3.org/html/wg/wiki/ExtensionSpecifications I note that there's already an extension spec which enhances <form> features. Perhaps you could coordinate with its editor? http://cameronjones.github.com/form-http-extensions/index.html