27941 2015-02-02 08:59:37 +0000 URLSearchParams and HTMLFormElement 2017-02-10 15:27:17 +0000 1 1 1 Unclassified WHATWG URL unspecified PC All RESOLVED WONTFIX P2 normal Unsorted 1 annevk annevk block.rxckin.beats brettz9 d mike rubys sideshowbarker+urlspec oldest_to_newest 117654 0 annevk 2015-02-02 08:59:37 +0000 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>. 117711 1 d 2015-02-05 15:49:08 +0000 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. 117715 2 annevk 2015-02-05 19:06:22 +0000 It does the same as <form> would do for application/x-www-form-urlencoded (its default behavior, by the way). 117732 3 block.rxckin.beats 2015-02-07 02:54:44 +0000 +1 for Anne. some discussion on discourse http://discourse.specifiction.org/t/formdata-and-urlsearchparams-on-form-urlencoded-in-xhr/742 117752 4 d 2015-02-08 21:30:11 +0000 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. 122580 5 annevk 2015-08-13 08:13:45 +0000 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>. 128439 6 annevk 2017-02-10 15:27:17 +0000 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).