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 27596 - Need a better story for searchParams and URLSearchParams
Summary: Need a better story for searchParams and URLSearchParams
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: URL (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: Unsorted
Assignee: Anne
QA Contact: sideshowbarker+urlspec
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-12 18:14 UTC by Anne
Modified: 2015-08-14 09:32 UTC (History)
7 users (show)

See Also:

Attachments

Description Anne 2014-12-12 18:14:52 UTC 
The tentative plan is to make searchParams readonly and the relationship 1:1. However, for Location we need something more complicated due to Location's insanity.

Possible ideas for Location's searchParams and URLSearchParams:

1) Not have it
2) Scope lifetime to document (though how does that actually work if you set it for a prior document?)
3) Copy Location's security model (seems way mad)
4) Create an immutable variant

Some background: https://bugzilla.mozilla.org/show_bug.cgi?id=1105677
Comment 1 Domenic Denicola 2014-12-12 19:08:56 UTC 
I like the idea of having .searchParams only return the same object until a navigation occurs, or possibly until an origin change occurs, as per https://bugzilla.mozilla.org/show_bug.cgi?id=1082734. People in that thread seem to prefer removing it entirely though; I'm not sure if there's a problem with the changing-return-value idea, or if they just find it too complicated.

An alternate approach that seems OK-ish would be to remove .searchParams and add .parseSearchParams(). Then URLSearchParams no longer becomes something that auto-updates its associated url objects, but instead just an in-memory data structure for application/x-www-form-urlencoded manipulation. User code might then look like

var searchParams = myURL.parseSearchParams();
searchParams.set('foo', 'bar');
myURL.search = searchParams.toString();

(You could also consider at this point renaming URLSearchParams to FormURLEncodedParams or something else to emphasize its general-purpose nature.)
Comment 2 Anne 2015-06-15 13:52:46 UTC 
Solution 4 from comment 0 does not actually work. For now I'm going to specify 1 since I'm not sure how to tackle this for Location.

Making it readonly will have to happen separately.
Comment 3 Anne 2015-06-15 14:20:42 UTC 
https://github.com/whatwg/url/commit/3a5e8086aff2fe3baa57fcebd1795a16de4f5d16 puts searchParams on its own interface. HTML still needs updating to add it to HTMLAreaElement and HTMLAnchorElement, but not Location.
Comment 4 Anne 2015-06-18 09:58:59 UTC 
(In reply to Anne from comment #2)
> Making it readonly will have to happen separately.

Mostly waiting for https://bugzilla.mozilla.org/show_bug.cgi?id=1174731 to be fixed in Gecko to do that.
Comment 5 Anne 2015-06-25 15:24:25 UTC 
That is fixed now, will update the specification next week I think.