undefined is probably more appropriate than null, but generally this would be nice. We have several URLs in our app at work that are built without = signs; it would be surprising if we couldn't round trip them through the URL parser without losing that.
> On Mar 12, 2014, at 7:00, "Simon Sapin" <[email protected]> wrote: > >> On 12/03/2014 10:04, David Håsäther wrote: >> I would like to propose making the `value` argument optional for >> URLSearchParams set()[1]. This would work as set("name", ""), but >> would not output the equals sign, leading to nicer URLs. >> >> So: >> >> set("name", "") -> "?name=" >> set("name") -> "?name" >> >> Anne van Kesteren pointed out[2] that this is different from the >> application/x-www-form-urlencoded serialization on which it currently >> relies on. I'm not sure if that has any implications. >> >> [1]http://url.spec.whatwg.org/#dom-urlsearchparams-set >> [2]https://twitter.com/annevk/status/443576248166391808 > > Currently the application/x-www-form-urlencoded serializer takes a list of > name-value pairs, where the name and the value are implied to be strings. We > could change it to accept values that are null as well as strings. A pair > with a null value would be serialized as just the name, without the equal > sign. > > So you could end up with ?name1=value1&name2&name3=value3 > > HTML forms would just provide lists of pairs that never happen to include a > null value. > > > The parser currently emits an empty strings when the input is missing an > equal sign for a given pair. Assuming the above, I don’t know if it should be > changed to emit a null value. > > -- > Simon Sapin
