Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Target JavaScript generated content #2

Closed
laukstein opened this issue Feb 14, 2019 · 5 comments
Closed

Target JavaScript generated content #2

laukstein opened this issue Feb 14, 2019 · 5 comments

Comments

@laukstein
Copy link

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?

@bokand
Copy link
Collaborator

bokand commented Feb 14, 2019

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.

@kevinmarks
Copy link

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

@bokand
Copy link
Collaborator

bokand commented May 28, 2019

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.

bokand pushed a commit that referenced this issue Aug 16, 2019
Minor edits (up to #### Match)
bokand pushed a commit that referenced this issue Sep 12, 2019
@sspi
Copy link

sspi commented Mar 20, 2020

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

@bokand
Copy link
Collaborator

bokand commented Dec 13, 2023

Closing out old issues.

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

@bokand bokand closed this as completed Dec 13, 2023
@bokand bokand closed this as not planned Won't fix, can't repro, duplicate, stale Dec 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants