Re: [w3ctag/design-reviews] FYI - Add optional `submitter` parameter to the `FormData` constructor (Issue #812)

> Just as a matter of process : we don’t really do FYIs. Either there’s something for us to review and feed back on or there isn’t. 

Thanks for letting me know! I'll pass this along to the Chromium team, as I think they've done similar "FYI" reviews in the past 🙏

> I respectfully disagree; I find `<form>` a rather natural first argument for a **form** data object, whereas submitter is much more secondary and non-obvious.

While `form` feels intuitive to me as well, in practice I don't know if that's what developers typically want/expect it to support. I.e. a very common scenario is wanting to construct a `FormData` object from an object or array, as can be done with `UrlSearchParams`, e.g. `new UrlSearchParams({ some: "value", another: "value"})` (see [xhr issue](https://github.com/whatwg/xhr/issues/202), [typical SO post](https://stackoverflow.com/questions/22783108/convert-js-object-to-form-data), [npm module workaround](https://www.npmjs.com/package/object-to-formdata)). In retrospect, perhaps the constructor should have always accepted a sequence/record, and supported forms a different way (e.g. `FormData.fromForm(form, submitter)`.

In light of that, a mild concern I have around the dictionary approach is that developers could see it in the wild and misunderstand its purpose, trying to use it to specify arbitrary entries, e.g. `new FormData(undefined, { some: "value", another: "value"})`. So while `submitter` is less obvious than `form`, it does relate to it strongly, and thus might avoid some ambiguities introduced by a dictionary.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/812#issuecomment-1410738407

You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/812/1410738407@github.com>