whatwg
FormData: Add ability to specify submitter in addition to <form>
Context: https://github.com/whatwg/html/issues/3195 Context: https://github.com/whatwg/xhr/issues/202
FormData should have ability to add an entry for a submitter button when it appends entries for a <form>.
We have multiple options of how to specify submitter. See five comments since https://github.com/whatwg/html/issues/3195#issuecomment-540927844
A) constructor(optional (HTMLFormElement or record<USVString, FormDataEntryValue>) formOrMap, optional HTMLElement? submitter = null)
Idiomatic.
B) constructor(optional (HTMLElement or record<...>) formOrSubmitterOrMap)
HTMLElement represents a form or a submitter.
C) constructor(optional (HTMLFormElement or FormDataInit) formOrDict)
dictionary FormDataInit {
HTMLFormElement form;
HTMLElement? submitter;
record<...> map;
}
The content of the dictionary is idiomatic. Need to wrap a record with a dictionary. Extensible. It's easy to add new members to the dictionary in the future.
D) constructor(optional (HTMLFormElement or FormDataInit or URLSearchParams) init)
dictionary FormDataInit {
required HTMLFormElement form;
HTMLElement? submitter = null;
}
FormData doesn't support record<> directly. Developers have to write new FormData(new URLSearchParams(map)).
E) constructor(optional HTMLFormElement form, optional HTMLElement? submitter = null)
FormData append(record<USVString, FormDataEntryValue> map);
Developers have to write new FormData().append(map).
F) (no changes on the constructor)
FormData append(HTMLFormElement form, optional HTMLElement? submitter = null);
FormData append(record<USVString, FormDataEntryValue> map);
Developers have to write let fd = new FormData().append(form, submitter); if they want to collect entries including an entry for the submitter.
From that discussion, I think there's agreement on adding a second optional argument to address the use cases from @muan et al. If we were to extend FormData further to support similar initialization to URLSearchParams we can revisit A vs E vs overloading at that point.
~~Is it worth also providing a way to pass in the selected x/y coordinate when the submitter is an Image Button? That would allow for full parity with the form submission algorithm (though it would require the developer to capture the coordinate, e.g. via click handler)~~ edit 2013-01-11 after reading the various specs, it seems like this should be handled implicitly as below
Or alternatively this could be implicitly handled by implementations (i.e. the coordinate would be recorded when the user selects it, and later used when constructing the data set, as is the case with a normal form submission)
