This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Both http://dom.spec.whatwg.org/#parentnode and http://url.spec.whatwg.org/#api defines a property named query.
Wow, even with the same author we get clashes. Sad times. I'm not sure which one to rename. Should we go for searchObj and URLSearch?
Maybe name the property urlQuery? Another option is to not have a URL query property on HTMLAnchorElement nor HTMLTextAreaElement.
I am starting to like queryParams or queryPairs. (Or searchParams/searchPairs.)
(In reply to Domenic Denicola from comment #3) > I am starting to like queryParams or queryPairs. (Or > searchParams/searchPairs.) +1 queryParams ... intuitive, been used before in other languages/frameworks/documentation and still fairly short.
I'm also fine with queryParams. Should we rename URLQuery to QueryParams as well?
Where has queryParams been used before? And yeah, if we go with that we should probably rename the interface.
(In reply to Anne from comment #6) > Where has queryParams been used before? And yeah, if we go with that we > should probably rename the interface. Seems to be pretty common parlance among devs to me - i see it in code frequently in several languages. some google searches show examples supporting... https://www.google.com/search? q=%E2%80%9Dqueryparams%E2%80%9D https://www.google.com/search? q=%E2%80%9Dqueryparams%E2%80% 9D+querystring https://www.google.com/search? q=%E2%80%9Dqueryparams%E2%80%9D+url
I'm still a bit torn. If we cannot use the actual proper term I think I somewhat prefer consistency with the existing API and either use searchObj or searchParams. I'm happy to be overruled though, it's not a big deal.
(In reply to Anne from comment #8) > I'm still a bit torn. If we cannot use the actual proper term I think I > somewhat prefer consistency with the existing API and either use searchObj > or searchParams. > > I'm happy to be overruled though, it's not a big deal. searchParams isn't so bad... where is that more consistent though? non-sequitur complaint on the platform in general: I hate that we have so many properties that begin with a potential verb and therefore seem like they might be a method. Seems kinda bad because it blocks a potentially useful method name and leaves us in situations picking a less than ideal name. Don't really see a great solution here for that, just mentioning that it bothers me :)
So my thinking is that either we have the short good name query and ignore search exists. Or we embrace that search exists and offer a classList-like companion. searchObj mostly stems from HTMLMediaElement src / srcObj (although they might name it srcObject).
(In reply to Anne from comment #10) > So my thinking is that either we have the short good name query and ignore > search exists. Or we embrace that search exists and offer a classList-like > companion. searchObj mostly stems from HTMLMediaElement src / srcObj > (although they might name it srcObject). I'm fine with searchObject but not with searchObj. We should not name things "obj". obj is fine for local variable names etc but we should not promote obj, doc, el, evt etc to APIs. Other options include {search,query}{List,Map,Object,Params}
Are you aware of srcdoc? Anyway, I am cool with searchParams with as object URLSearchParams.
https://github.com/whatwg/url/commit/0ca57a12e90099e00a0f142b7170d93fb11ab309