How does the `FormData` constructor handle arguments in non-DOM runtimes?
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- javascript
- Domain
- api
Research direction
Review the XHR FormData constructor definition and the reported behavior in Node.js, Deno, Cloudflare Workers/workerd, Bun, and WinterJS. Decide the intended handling of unsupported arguments, including the second argument, and document the agreed normative behavior for this API and possible future APIs.
Written by the indexing model from the issue text.
Description
The FormData constructor, as defined in the XHR spec, takes two optional parameters: the first of type HTMLFormElement, and the second of type HTMLElement. These are DOM APIs, which server-side runtimes don't support.
The way I see it, if any of these arguments is passed (and it's anything other than undefined), this indicates a bug in user code. For example, the code in question could be isomorphic code using DOM APIs through a library such as jsdom or deno-dom, and the developer mistakenly used those objects with the runtime's FormData implementation. TypeScript might not catch that, since it could be set up to use the browser's type definitions rather than the runtime's.
In the runtimes I've tested:
- Node.js and Deno throw if the first argument is not
undefined, but they ignore the second argument. - Cloudflare Workers /
workerd, Bun and WinterJS ignore both arguments.
No runtimes seem to check the second argument. Specifying Node.js and Deno's behavior might be fine, since in browsers the second argument does nothing if the first one is undefined, and the first argument is already checked. But the WebIDL implementation in browsers does check that the second argument is a valid HTMLElement regardless of whether the first one is undefined, so maybe we should be consistent with that. This would also let us specify this by just saying what happens with unsupported WebIDL types, which is something that might also apply to other APIs in the future.
- Dominant language
- Bikeshed
- Stars
- 308
- Forks
- 17
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from WinterTC55/proposal-minimum-common-api
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
WinterTC55/proposal-minimum-common-api#117 · 4 reactions ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
WinterTC55/proposal-minimum-common-api#107 · 4 reactions ·
-
2026 edition roadmap Open
Difficulty 5/5 Over a week Newbie friendliness 25/100
WinterTC55/proposal-minimum-common-api#106 · 2 reactions ·
-
Serialization? Open
Difficulty 5/5 Over a week Newbie friendliness 18/100
WinterTC55/proposal-minimum-common-api#99 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
All issues in WinterTC55/proposal-minimum-common-api
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
code-quality refactoring
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
github/gh-aw-firewall#8816 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
getgrav/grav-plugin-api#45 ·
-
integration:quickjs org:external priority:backlog topic:code-interpreter topic:middleware type:feature
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
langchain-ai/deepagents#6450 ·