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
smime.p7s
Description: S/MIME cryptographic signature
