13054 2011-06-25 07:48:06 +0000 WF3: Allow one input to be part of multiple forms 2011-08-14 06:43:29 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified All All RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#top P5 enhancement --- 1 contributor ian annevk ayg ian mike public-html-admin public-html-wg-issue-tracking w3cbugs public-html-bugzilla oldest_to_newest 50303 0 contributor 2011-06-25 07:48:06 +0000 Specification: http://www.w3.org/TR/html5/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: I am referring to this section of the HTML5 spec: http://www.w3.org/TR/html5/association-of-controls-and-forms.html#association- of-controls-and-forms Decoupling form controls and the form element is a good first step to improving the flexibility of web forms, but I think we should go one step further: allowing a single form-associated element to be associated with multiple forms. I propose that there may be circumstances where application developers may want to create a form containing several inputs, but to also associate sub-groups of those inputs with another form. I propose that the syntax of the form attribute be modified to work like the class attribute does. rather than containing a single form id, the form attribute should be a space-separated list of form ids. I recognize some difficulties in this approach, for example: - Submit inputs and buttons obviously cannot attempt to submit multiple forms at once, so the proposed syntax should be invalid for those elements. - When clearing a form which contains an input that is associated with a second form, it is unclear what the expected behavior of that input would be. Should the input be cleared, or remain populated? I think good solutions can be found for these problems, and, if there is interest among the group, this new syntax could be adopted and may prove useful to many developers. Thanks for reading. I hope I made my case well. Posted from: 71.61.178.237 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_7) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.24 Safari/535.1 50304 1 w3cbugs 2011-06-25 07:57:11 +0000 Here is a short use case: I have a shopping cart page with an input for each item in my cart which allows me to update the quantity of that item. I have a form for each of these inputs that points to a script that saves the quantity of the item in my cart. I also have all of the inputs associated with a form that saves all of the quantity values (and possibly some other fields) and directs the user to a checkout page. 50307 2 annevk 2011-06-25 09:52:38 +0000 This used to be in Web Forms 2.0 (and Opera). We dropped it to make the specification simpler. It also gave problems with radio buttons and checkboxes, if I remember correctly. 50330 3 ayg 2011-06-26 22:19:21 +0000 Not sure if the use-case is compelling, particularly since it could easily be done by script. Generally if something is doable by script, we require that it be very commonly needed before we're willing to add a declarative way to do it. I encourage you to provide as many distinct, common use-cases as possible to make a case for your proposal. The one you gave is a good start. 53511 4 mike 2011-08-04 05:14:34 +0000 mass-move component to LC1 54928 5 ian 2011-08-14 06:43:29 +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: Rejected Change Description: no spec change Rationale: As Anne says, we actually did this a few years ago. It was more trouble than it's worth and really there aren't as many use cases as you'd think. In practice you generally end up having to have script anyway so it's no big loss.