From #whatwg:

[12:12]  <caitp> would it be a bad thing to have a method of HTMLFormElement which assembles a FormData object automatically? that seems like a nice feature that people have already polyfilled a lot
[12:12]  <jgraham> Certianly not from the point of view of the compiler :)
[12:12]  <caitp> and pretty trivial to implement in a private script, for that matter
[12:13]  * paulohp has quit (Remote host closed the connection)
[12:13]  <jgraham> caitp: Seems like a reasonable idea

--------

This would be a pretty trivial feature to implement. It might even be taken a bit further, like having an "async" content attribute which submits the form via Fetch/XHR rather than navigation, using the specified method/action.

I mean yeah, libraries have been doing this for a while, but it might be a useful thing to let people do by default, and should be easily polyfilled in browsers which support XHR2

I thought we had this already. Isn't that what new FormData(myFormElement) does?

Yeah, anne mentioned that. I agree that it's already possible, but there are a few problems with this:

1) nobody would ever expect it to work this way. This is illustrated with the comment I made, "like, suppose you wanted a list of VIN numbers parked in a given parking lot --- the `new FormData()` option is like going to the paper factory and asking them to create a set of papers containing vin numbers from <parking lot>, whereas my suggestion is more like asking the parking lot manager for a list of vin numbers in the lot" --- It just seems semantically backwards as to what is being accomplished, so it doesn't occur to anyone to try this.

2) it doesn't really deal with the extended option I suggested, which I think would be pretty cool and save many lines of code in numerous frameworks (because nobody ever really wants to navigate when submitting a form anymore)

What if `HTMLFormElement#getFormData()` or something were an alias for `new FormData(<form>)`?

What if we did consider an async submission mechanism? There are many lines of code devoted to providing async form submission in numerous libraries, it would be cool if it were possible to make it a builtin.

I'm not convinced this is needed right now. There's bigger fish to fry.

(In reply to caitp from comment #3)
> Yeah, anne mentioned that. I agree that it's already possible

Ok. If it's possible, then there's nothing to do here.


> 1) nobody would ever expect it to work this way.

It's how I'd expect it to work...


> This is illustrated with
> the comment I made, "like, suppose you wanted a list of VIN numbers parked
> in a given parking lot --- the `new FormData()` option is like going to the
> paper factory and asking them to create a set of papers containing vin
> numbers from <parking lot>

No it's not. It's like grabbing a piece of paper from the top of the paper pile, and writing down the VIN numbers, instead of first collecting up all the VIN numbers, and telling them to give you a piece of paper with their name on it.


> 2) it doesn't really deal with the extended option I suggested, which I
> think would be pretty cool and save many lines of code in numerous
> frameworks (because nobody ever really wants to navigate when submitting a
> form anymore)

Not sure what you mean here. If you just want to submit the form in the background, use target="" to submit it to an iframe.


> What if `HTMLFormElement#getFormData()` or something were an alias for `new
> FormData(<form>)`?

If it's an alias, then it adds nothing except potential bug surface area, code bloat, and tutorial bloat.


> What if we did consider an async submission mechanism? There are many lines
> of code devoted to providing async form submission in numerous libraries, it
> would be cool if it were possible to make it a builtin.

All submission mechanisms in the specs right now except one (sync XHR, which is heavily deprecated) are async.

Closing per comment 5; please reopen if you respond. Thanks.