URL API

[Jamesernator]

While these text fragments will often be created by user agents it would be nice to be able to construct these easily in JS so that custom sharing options can be created.

For example Medium does this with selected text:

It would be nice to be able to do similar with fragment directives using the URL API.

e.g. Example API surface:

const url = new URL(location.href);
url.fragmentDirectives.add('text', window.getSelection().toString());

showShareUrl(url);

[Jamesernator]

Additional consideration, given fragment directives always come after the hash should the following delete the fragment directives or should they be preserved?:

const url = new URL('https://example.com/#:~:text=hello');
url.hash = '';

[othermaciej]

I agree this would be useful to add. I think modifying hash, even setting it to empty, should not alter the fragmentDirective. This should likely match the interface added to Location as much as possible.

[bokand]

Seconded - I think something like add() would be useful so JS apps can easily construct these.

On how url.hash should work I'm less certain about. We'd thought about this to some extent - some of my ideas are in whatwg/url#445 (comment) (back when we were still using ## as the delimiter). There's plenty of cases to consider but I think I covered a bunch there.

What we landed on currently is a minimal change. The HTML Document loading steps will strip the fragment directive from the loaded URL. Otherwise URLs and locations behave exactly as today (e.g. adding a fragment directive to window.location will fire hashchange).

That said, I don't have any strongly held opinions here so I'm open to make changes to URL objects and window.location if we can agree that's a good idea.

[zamicol]

fragment directives or should they be preserved?:

const url = new URL('https://example.com/#:~:text=hello');
url.hash = '';

Be removed.

A fragment directive is a subset to fragment.

For the other behavior to be reasonable, fragment directive needs to be independent of fragment (and probably a new name to denote this new addition to the URL standard). # is irrelevant for that case as well. If fragment directive is a part of the fragment component, it should following existing rules for fragment. If it needs new rules, it needs to be a new URL component.

[bokand]

Closing out old issues

Issues around how and when the URL is affected by the fragment directive are now well defined by #225. See https://wicg.github.io/scroll-to-text-fragment/#extracting-the-fragment-directive and the examples in that section for an overview.

Re: having APIs to make it easier to work with (e.g. on URL), that still seems worth having but I think is out of scope for this repo and can be followed up in the HTML standards repo once this is upstream.