[whatwg/url] Consider adding support for fragment parameters (#389)

Domenic Denicola suggested that I open an issue for this.

Various specs and web applications would benefit from standardizing support for fragment parameters, in addition to the existing support for query parameters.

The URL spec defines support for name-value pairs in the query string, parsed by running the application/x-www-form-urlencoded parser (https://url.spec.whatwg.org/#concept-urlencoded-parser).

In addition to the query string, other specs make use of name-value parameter pairs in the fragment portion of the URL. For example, various mime types make use of name=value pairs in their fragment specifications:

Media fragments, e.g. #track=audio&t=10,20 (https://www.w3.org/TR/media-frags/#media-fragment-syntax)
PDF fragment identifiers, e.g. #page=10&zoom=... (https://tools.ietf.org/html/rfc3778#section-3)
text/plain fragment identifiers, e.g. #line=10,20 (https://tools.ietf.org/html/rfc5147#section-3)
CSV fragment identifiers, e.g. #row=4 (https://tools.ietf.org/html/rfc7111#section-3)

More recently, we are looking at extending support for HTML fragment identifiers in https://github.com/bryanmcquade/scroll-to-css-selector and would like to use parameters in the fragment, e.g. #targetElement=.cssClass.

In addition to these specs, it's not uncommon for web apps to want to encode their own application-specific parameters in the fragment. Searching github for "URLSearchParams hash substr  language:JavaScript" shows a number of code snippets that perform an operation like: var fragmentParams = new URLSearchParams(window.location.search.substr(1));. Standardizing fragment params would make it simpler for these apps to consume their fragment params (perhaps on a hashParams property of the URL API, similar to the existing searchParams property).

Standardizing on an encoding scheme for fragment parameters, similar to the existing support for query parameters, would allow other specs that depend on fragment params (those linked above) to reference the standard, rather than having to spec out how to encode these fragments in each individual spec.

In addition, a common encoding scheme with named parameters makes it straightforward to "share" the fragment, encoding both mime-type specific fragment identifiers, as well as application-specific fragment parameters, in a single fragment. For example: #targetElement=.cssClass&myApplicationParam=foo allows for encoding both the targetElement fragment identifier param proposed in https://github.com/bryanmcquade/scroll-to-css-selector as well as any application-specific parameters (in this case myApplicationParam=foo).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/389