This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27941 - URLSearchParams and HTMLFormElement
Summary: URLSearchParams and HTMLFormElement
Alias: None
Product: WHATWG
Classification: Unclassified
Component: URL (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: Unsorted
Assignee: Anne
QA Contact: sideshowbarker+urlspec
Depends on:
Reported: 2015-02-02 08:59 UTC by Anne
Modified: 2017-02-10 15:27 UTC (History)
5 users (show)

See Also:


Description Anne 2015-02-02 08:59:37 UTC
It's been suggested twice now to make URLSearchParams accept HTMLFormElement just like FormData does. This would e.g. help with manipulating a URL based on a <form>.
Comment 1 Domenic Denicola 2015-02-05 15:49:08 UTC
So this is just a lossy translation for forms containing <input type="file">? That seems like a bad incongruity between FormData and URLSearchParams that makes URLSearchParams less of a fit.
Comment 2 Anne 2015-02-05 19:06:22 UTC
It does the same as <form> would do for application/x-www-form-urlencoded (its default behavior, by the way).
Comment 3 Jxck 2015-02-07 02:54:44 UTC
+1 for Anne.

some discussion on discourse
Comment 4 Domenic Denicola 2015-02-08 21:30:11 UTC
I guess so. It'd be the first part of the URL API to start depending on non-browser environments, which is kind of sad.
Comment 5 Anne 2015-08-13 08:13:45 UTC
I see two ways around that:

1. <form> supports a generic protocol whereby another object can ask it for a specific serialization and it then iterates over its entries and invokes `append()` on that other object.

2. We leave `FormData` as a special case and introduce `toURLSearchParams()` directly on <form>.
Comment 6 Anne 2017-02-10 15:27:17 UTC
I'm going to close this for now. I didn't get any new requests for this. HTML <form> exporting a URLSearchParams seems like a better API too if we are to ever do this (even though that would be inconsistent with FormData).