W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2014

Re: [whatwg] Making URLSearchParams set() `value` argument optional

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Wed, 12 Mar 2014 13:16:08 +0000
To: Simon Sapin <simon.sapin@exyr.org>
Message-ID: <AC5754DA-2A11-48AF-BFCF-5D29CA06170C@domenicdenicola.com>
Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
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" <simon.sapin@exyr.org> 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
Received on Wednesday, 12 March 2014 13:16:38 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:17 UTC