This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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>.
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.
It does the same as <form> would do for application/x-www-form-urlencoded (its default behavior, by the way).
+1 for Anne. some discussion on discourse http://discourse.specifiction.org/t/formdata-and-urlsearchparams-on-form-urlencoded-in-xhr/742
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.
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>.
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).