WICG/scroll-to-text-fragment

Target JavaScript generated content

laukstein opened this issue · 5 comments

User might share content that is generated by JavaScript.
How would targetText target/scrollTo text that isn't yet painted or is painted after some delay?

I think this should be analogous to regular fragment identifiers today, that is, the page has until the load event to present the content. If the content wouldn't normally be loaded (e.g. "below the fold" in an infinite scroller), the page could read the fragment and either ensure the scroller loads all content down to the target or perform the scrolling itself.

Though, I don't think this is unique to text-fragments, the same issues apply to id fragments.

You look for events that change the document text. For example
http://www.kevinmarks.com/poemfragmentions.html#searches%20are%20more%20resilient%20than%20links
will highlight the js-injected comment with that fragment in

We could do this from the browser: reevaluate the targetTexts when the page changes. However, this could lead to the user interacting with the page for some time only to have new content cause the page to scroll away from where the user's attention is focused. Browsers today override scrolling to the id-fragment when the user has performed any scrolling and we've implemented this for targetText in the Chromium prototype. Additionally, this could lead to significant overhead on pages that change often as full-text searches aren't trivially cheap. We could experiment with some heuristics if this turns out to be a major issue

The main issue I see for pages handling this on their own is it's currently difficult for a page to parse and perform the targetText selector itself (since the current format allows for a wild card and surrounding context). It'd be nice to have an API like:

let selector = new TargetText(window.location.targetText);
selector.invoke();

This would be a nice follow up but I don't want to block on this.

sspi commented

For dynamically created pages (PWA ...), such an API seems essential.

Closing out old issues.

Such an API is out of scope for this repo but could be considered in future efforts.