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

Sidney San Martín s at sidneysm.com
Sun Feb 7 10:28:02 PST 2010

On Jan 30, 2010, at 8:23 AM, Anne van Kesteren wrote:

> On Fri, 29 Jan 2010 22:12:19 +0100, Sidney San Martín <s at sidneysm.com> wrote:
>> What do you think?
> If we do anything here it needs to be harmonized with http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-formdata-interface somehow.

Thanks, it's good to hear that the overall problem is being considered.

> If the main use case is asynchronous submission it could be something as simple as <form>.formData which seems better than tying it to the submit event.

If a FormData is exposed on the submit event, it's much clearer that any changes you make (appending, or modifying or deleting) to it affect the submit and (more importantly) go away after the submit is over.

I'm worried that <form>.formData doesn't cover some of my use cases and leaves a lot of behavior to the imagination. It doesn't provide access to the submitter during a submit, so click event hackery is still needed to guess at it.

If you call <form>.formData.append(), what happens? Does it affect normally-submitted form data or just the FormData property on the form? How long does the new entry persist? I don't see a problem with providing an immutable FormData on <form>s.
-------------- 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/20100207/a21ffbea/attachment-0002.bin>

More information about the whatwg mailing list