[Proposal] Allow scrolling to a specified text snippet in a navigation

Current specifications and implementations allow a URL to specify a target in the URL fragment. If the navigated to resource has:

  • an element with an id matching the fragment
  • a link with with a name attribute that matches the fragment

that element will be the CSS target. The UA will scroll the targeted element into view when the resource is loaded. This allows linking to specific parts of a resource. For example, the Wikipedia entry on “Cat” is very long and broad. However, each subsection is marked with an id so users and resources can link directly to a subsection, for example: Cat Behavior.

However, this relies on a page author predicting all the parts of a resource users may find interesting and marking it up with ids. This limitation makes it difficult to use fragments to link to arbitrary content. For example, take the page: https://www.gutenberg.org/files/2147/2147-h/2147-h.htm. Suppose a user or resource wants to link to the paragraph (e.g. to cite a quote) that starts with:

“It became necessary, at last, that I should arouse both master and valet to the expediency of removing the treasure.”

The referring page would have to link to “THE GOLD-BUG” section and tell the user to scroll down or use their browser’s find-in-page function.

I’d like to propose extending the URL fragment for HTML documents to allow specifying a text snippet as the target. In this case, we could encode the above quote directly in the URL fragment and the user agent would scroll directly to the specified text, possibly highlighting it to the user.

I have an explainer in my personal GitHub repo that has more details and a proposed solution.

Would anyone else be interested in discussing and iterating on this proposal in the WICG?


As a user and someone that find themselves linking to other documents quite often, I really like that proposal! Would be very handy!

It might be useful, here are some of the major open questions about the proposal:

  • How does this interact with single-page apps that use the fragment for routing? e.g. how could we specify a text fragment on a page like: http://example.org/#!splashPage (note, this isn’t unique to this proposal, the same issue exists for id-based fragments)
  • Selecting long, DOM-fragmented quotes: sometimes the text to select may be very long. Ideally we’d provide some convenient syntax to keep URLs manageable. Additionally, the desired quote may appear continuous on the page but be contained in separate elements, e.g. <p>paragraph 1</p><p>paragraph 2</p>. We should provide a way to select the text like this irrespective of it’s underlying DOM structure.
  • Allow selecting multiple quotes. We may wish to highlight an entire row or column in a table, or two paragraphs separated by an image.

These and others are discussed in detail in our GitHub repo issues

I like the idea but what if the text snippet on the target page changes? Not only would the link on the referrering page be broken, but the referrering page wouldnt even know about it to update. And if it does update it, the text snippet can be changed again. Then another broken link.

I like the idea but what if the text snippet on the target page changes? Not only would the link on the referrering page be broken, but the referrering page wouldnt even know about it to update. And if it does update it, the text snippet can be changed again. Then another broken link.

The fallback behavior would be that the page loads unscrolled which doesn’t seem any worse than what would happen today when you can’t link to a text snippet

Additionally, the UA could potentially indicate to the user that it couldn’t find the specified text to make it clear the page might be stale.

I’d also point out the same issue exists with element-id based fragments but they work well in practice. More so, if a link points to a page whose content has changed so that the content of the page is no longer relevant to the link, I’d say that’s an existing problem that exists regardless of whether a fragment is specified at all. Having an indication as mentioned above would actually improve this scenario since the user could at least tell that the page has changed since the link was created.

It seems that you want to reinvent XPointer – something that never got much interest from browser vendors.

This is something the IndieWeb community has tackled with fragmentations. I have an explainer I wrote a few years back as well. Let me dust it off and see if it needs updating and then I’ll post it. Given my schedule it’ll be the tail end of next week at the earliest. But yes!


Yeah the same issues exist with URL fragments that are associated with anchor element IDs. And yes, its a problem regardless of this proposal, but at least when a developer uses an anchor ID (</>) to make their content linkable, they are deliberate in doing so and are aware they are using an identifier that can be linked to, which should probably never change.

This proposal, on the other hand, actually is encouraging anchor linking to text, which is even more likely to change and result in broken links. Of course, I’m not saying this proposal should fix broken anchor fragment links but it shouldnt facilitate an opportunity to make a bad problem even worse, if that makes sense.

1 Like

It is a good idea. However, since this seems to overlap with ongoing standardisation efforts, maybe it would be better to engage directly with those?

https://www.w3.org/TR/selectors-states/#TextQuoteSelector_def https://www.w3.org/TR/annotation-html/#web-annotation-based-citation-urls

1 Like

This has been (and is still being) discussed in issue 10 of the aforementioned GitHub repo.

However, just to make the situation clear: there is no “ongoing standardization effort” on this. There is a set of standards on Web Annotation which does include a selector model related to annotations. The Web Annotation model does not define a fragment URL approach, and the corresponding Working Group has been closed a while ago.

The document you quote, that does include a fragment URL proposal has been published by the Working Group as a Note, and has not been touched since its publication in early 2017. I think one possible question is: should there be a standardization effort, possibly along the lines of that note? (I do not have an answer to this question.)

1 Like

I think there’s enough interest. I’d like to move the repo into the WICG.

Sounds good. Let’s do this!

1 Like

And the repo is now live at https://github.com/WICG/ScrollToTextFragment

Happy incubating!!