[whatwg] Fixing the submit event by exposing submitter and data set

[Sidney San Martín]

When a user binds to a form's submit event, it's almost always for one of three purposes:

1. To prevent submission, if the page or form is in an unsubmittable state
2. To handle submission in a non-default way (submit it asynchronously or use it locally)
3. To add to the data in the form before it's submitted

The result is that every major JavaScript framework has functionality to extract the data from a form. [This page compares][1] the behavior of the most popular ones. *None* of the framework results match any of the others, except for jQuery and jQuery Form, and *none* of the framework results match my UA's results (WebKit r53990). Scripts handling the submit event can't get at the submitter, which makes it impossible to know its name, value, and mouse coordinates (in the case of image inputs) without binding to click on every button in the form and keeping track of which one fired in the same event loop as submit. This is how forms are handled today.

JavaScript authors shouldn't be in the game of implementing the HTML API. I propose that the [form submission algorithm][2] be rearranged slightly so that the form data set is constructed before the submit event fires, and the data set and submitter are exposed as properties on the submit event.

The data set might look like this:

   [
       {
           name: "someName",
           value: "someValue",
           node: <input>
       },
       {
           name: "otherName",
           value: "otherValue",
           node: <input>
       },
       ...
   ]

...where `name` and `value` are the name and value to be submitted, and `node` is a reference to the element that caused that pair to be created.

If I want to submit additional data describing some state on the page, right now I have to create an input, set its type to hidden, set its name and value, append it to the form, and, if I don't plan to target the form at its own browsing context, wait for the submit to run, and remove it from the form. With this new model, sending extra data could be as simple as

   formData.push({ name: "someAdditionalName", value: "someAdditionalValue" });

In this case, `node` would be undefined. It's also conceivable that objects could be deleted from the data array (maybe in the case that an input only has relevance to the script handling a form and not to its action), and that the names and values could be writeable without mutating the name or value of the associated input (I don't have use case for this last one). The implementation would have to handle inputs being added, removed, or modified during the submit event. I think that the cleanest way to deal with this would be to update the data object synchronously to reflect those changes, so that behavior remains backwards compatible. There may be a better way, or my whole implementation could be garbage.

What do you think?


 [1]: http://jquery.malsup.com/form/comp/
 [2]: http://www.w3.org/TR/html5/forms.html#form-submission-algorithm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6343 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100129/36b0eba3/attachment-0002.bin>