This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 14870 - autosubmit attribute for form elements
Summary: autosubmit attribute for form elements
Status: RESOLVED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement
Target Milestone: ---
Assignee: David Stone
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y
Depends on:
Blocks:
 
Reported: 2011-11-18 01:20 UTC by David Stone
Modified: 2013-05-08 13:51 UTC (History)
12 users (show)

See Also:


Attachments

Description David Stone 2011-11-18 01:20:40 UTC
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.
Comment 1 Everett Zufelt 2011-11-18 01:40:43 UTC
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
Comment 2 David Stone 2011-11-20 05:19:58 UTC
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.
Comment 3 John Thomas 2011-11-22 14:37:50 UTC
(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.
Comment 4 Everett Zufelt 2011-11-22 16:10:26 UTC
The HTML Accessibility Task Force will track this bug to ensure that there are no negative implications for accessibility.
Comment 5 Ian 'Hixie' Hickson 2011-12-07 21:13:09 UTC
We actually had an "autosubmit" feature in an earlier draft, but didn't keep it (I forget why).
Comment 6 Robin Berjon 2013-01-21 15:59:04 UTC
Mass move to "HTML WG"
Comment 7 Robin Berjon 2013-01-21 16:01:49 UTC
Mass move to "HTML WG"
Comment 8 Edward O'Connor 2013-02-25 22:58:23 UTC
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