Scroll To Text

[nickburris]

こんにちはTAG!

I'm requesting a TAG review of:

• Name: Scroll To Text
• Specification URL: N/A
• Explainer (containing user needs and example code)¹: https://github.com/WICG/ScrollToTextFragment
• GitHub issues (if you prefer feedback filed there): https://github.com/WICG/ScrollToTextFragment/issues
• Tests: N/A
• Primary contacts (and their relationship to the specification): @nickburris @bokand

Further details:

• Relevant time constraints or deadlines: [please provide]
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles
• The group where the work on this specification is:

We recommend the explainer to be in Markdown. On top of the usual information expected in the explainer, it is strongly recommended to add:

• Links to major pieces of multi-stakeholder review or discussion of this specification:
• Links to major unresolved issues or opposition with this specification:

You should also know that...

One of our major discussion points currently is how the targetText= indicator should be delimited in the URL fragment. See https://github.com/bokand/ScrollToTextFragment/issues/15. The latest idea here is that we could use a double-hash syntax (e.g. example.com#fragment##targetText=example) to avoid breaking websites that use the fragment for routing/state. The browser would parse the ##targetText= identifier and then remove it from the fragment.

We'd prefer the TAG provide feedback as (please select one):

• open issues in our GitHub repo for each point of feedback
• open a single issue in our GitHub repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

---

Please preview the issue and check that the links work before submitting. In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document.

¹ For background, see our explanation of how to write a good explainer.

[dbaron]

Is it worth having any similarity to RFC 5147's mechanism?

[torgo]

Hi - just noting that the assessment of the questionnaire appears blank.

[nickburris]

Is it worth having any similarity to RFC 5147's mechanism?

The problem with using character positions is that the references would be outdated much more quickly, for example if this were to be used for cross-references on Wikipedia, where articles are updated often. Naturally, text references will also go stale over time, but only when the actual target text is modified.

Hi - just noting that the assessment of the questionnaire appears blank.

Sorry - I misunderstood the template. Here is the questionnaire: https://github.com/bokand/ScrollToTextFragment/blob/master/security-privacy-questionnaire.md

[aarongustafson]

Some additional thoughts for consideration based on research & exploration we’ve been doing: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Fragments/explainer.md

[annevk]

I couldn't find a description of how "Restricted to pages without an opener (no window.open)" is managed. (In particular, if A1 opens a popup A2 which then navigates A1 to V, V won't have an opener, but we certainly don't want this to work there.)

[nickburris]

I couldn't find a description of how "Restricted to pages without an opener (no window.open)" is managed. (In particular, if A1 opens a popup A2 which then navigates A1 to V, V won't have an opener, but we certainly don't want this to work there.)

The case you describe would indeed circumvent this. I'm not sure how we can mitigate this case - does anyone know of any precedent for this kind of restriction in spec already?

[nickburris]

FYI, we're currently exploring a way to improve web compatibility by placing the targetText behind a delimiter - e.g. a ## in the URL fragment separating the targetText which would then be stripped off and hidden from the page. This mitigates issues with sites that use the fragment for other purposes, e.g. https://www.webmd.com/skin-problems-and-treatments/lice-treatment#3##targetText=other%20options.-,Wet%20combing%20is%20one,or%20olive%20oil.,-But%20these%20may (from chromium bug 961440)

This is explored in https://github.com/bokand/ScrollToTextFragment/issues/15#issuecomment-496595958 and we'd appreciate TAG reviewers' thoughts on this issue!

[dbaron]

We had a discussion about this at our telecon last week.

[dbaron]

Another question about this: what's the story for feature detectability?

[bokand]

Another question about this: what's the story for feature detectability?

I brought this up in WICG/scroll-to-text-fragment#19 - We should have some way to detect this feature but I'm not sure what the best way would be. Since there's no new JS APIs there's no obvious place to put it. Perhaps a bool on navigator? Or on URL? Neither feels especially intuitive. Is there an existing place for feature detecting things without a matching JS/CSS API?

For ##, we could feature detect that with (new URL('https://test.com/##)).hash.indexOf('##') >= 0 but we probably don't want to tie ## to targetText.

From some of the questions in the notes:

Peter: I remember Doug Schepers talking about an annotation system.

Probably WebAnnotations? We did look at this and our syntax is quite close to the TextQuoteSelector, the major difference being that we allow essentially a wild-card match on the exact portion to allow a more compact representation of a long snippet.

Peter: there's a lot of work that's been done with media fragments;

We also looked at media fragments and initially wanted to do something similar. However, we ran into the compatibility concerns for pages that don't expect a hash/use it for their own processing.

How will these URL be minted? From user doing text search in browser? Or something page will generate?

We expect two major use cases: external pages pointing to a sub-resource (e.g. search engine, Wikipedia references) as well as users highlighting a snippet and copying a direct link to it. In both these cases we're generating a hash for a page without it knowing about it prior. Hence why conflicting with existing uses of the hash for routing is a concern; we expect a large number of links containing a hash to pages that would previously not expect it.

The case of internal (within an origin) anchors is less interesting because it's already possible. Since the author controls both the anchor and the pointed to resource, they can simply annotate the desired location with an element-id and use a regular element-id fragment (and provide highlight styling using :target)

[BigBlueHat]

The Web Annotations WG did also create a fragment selector proposal as part of a note and there are a handful of existing implementations of those among web annotation tool providers--Apache Annotator among them (see demo).

So...Web Annotation Fragment Selectors:

https://annotator.apache.org/demo/#selector(type=TextQuoteSelector,exact=annotated%20world!))

vs.

https://example.org/##targetText=annotated%20world!

The Web Annotation Data Model (and it's Open Annotation predecessor) are widely used in digital heritage communities such as those using the International Image Interoperability Framework or projects like Pelagios or online article publishing tools like dokie.li. Additionally, general purpose web annotation systems like Hypothes.is and Pundit support Web Annotation Data Model compatible exports.

All of these communities would benefit from a text selection fragment identifier which was compatible with the Web Annotation Data Model structure such that conversions could be made between the two by existing implementations.

[plinss]

The spec needs to list which content types this type of fragment applies to, e.g. does this only work for html? what about plain/text documents? SVG? etc...

I'm not asserting which types of documents this should apply to, but the spec needs to be clear as fragments are interpreted according to the content type of the document.

[hober]

@annevk left a comment on WICG/scroll-to-text-fragment#70 after it was merged:

That might be doable, yes, but it would require patching HTML.

Is there an issue filed on HTML to track this work, @bokand?

[hober]

Marking as pending external feedback while we wait for answers to the above questions, and pending editor update for my word boundary nits.

[bokand]

This is definitely an improvement, thanks. I have more specific thoughts about the non-normative note beginning "Limiting matching to word boundaries," which are below. With the following changes, I'd be happy with this text.

Thanks for the feedback, we'll make the changes.

The spec needs to list which content types this type of fragment applies to, e.g. does this only work for html? what about plain/text documents? SVG? etc...

It's implied to be HTML documents only by section 2.3.4 allowTextFragmentDirectiveFlag since it makes the change in the HTML document loading steps. I agree it'd be useful to make this more explicit. Would a non-normative note be sufficient because of the above or does this need to be normative?

@annevk left a comment on WICG/scroll-to-text-fragment#70 after it was merged:

That might be doable, yes, but it would require patching HTML.

Is there an issue filed on HTML to track this work, @bokand?

I believe this was in reply to my suggestion:

Also, w.r.t. target="_self" rel="noopener", could we make a link with a text directive imply noopener semantics? I would think this is preferable to requiring links to add noopener since there are cases where that'll be difficult for the user and generally make this more difficult to use.

I just replied on the PR. I changed my mind on the above, I don't think it's critical to this proposal (details there). I think @annevk's original idea about target="_self" rel="noopener" would still be useful. Filed whatwg/html#5134.

[bokand]

FYI: There's a question in whatwg/#5523 about whether we should move window.location.fragmentDirective from window.location to elsewhere (document.fragmentDirective?) due to the quirks of window.location. I'd appreciate if we got broader opinions on whether it's worth the work to make window.location smoothly extensible or if it should be avoided in new APIs.

[annevk]

I don't think it's critical to this proposal (details there).

I replied there pointing out a flaw in the reasoning, but that was never followed up on.

[bokand]

Sorry - I still intend to get to it (along with a bunch of other outstanding issues) but have too many balls in the air. I'll carve out some time this week to look at that issue specifically.

[hober]

The spec needs to list which content types this type of fragment applies to, e.g. does this only work for html? what about plain/text documents? SVG? etc...

It's implied to be HTML documents only by section 2.3.4 allowTextFragmentDirectiveFlag since it makes the change in the HTML document loading steps. I agree it'd be useful to make this more explicit. Would a non-normative note be sufficient because of the above or does this need to be normative?

I think you'll need to make at least some normative statements, yes, though perhaps most of this point could be captured in a non-normative note.

[hober]

FYI: There's a question in whatwg/#5523 about whether we should move window.location.fragmentDirective from window.location to elsewhere (document.fragmentDirective?) due to the quirks of window.location.

FWIW, I agree with @annevk's comment here: whatwg/html#5523 (comment)

[hober]

We took another look at this in this week's TAG F2F and we've decided to complete our review.

We're happy that you've tightened up the normative text around word boundaries that we were concerned with, and that you reached out to several other venues to solicit feedback (e.g. uri@w3.org).

We're (still) worried that this is a very significant change to URL syntax and processing that may not have gotten sufficient buy-in from the various relevant standards bodies and other stakeholders. We're also worried that this doesn't have a clear path to standardization. Where do you intend to take this after WICG?

Please file a new design review issue if you end up significantly altering your plans here. Thanks!

[bokand]

Thank you @hober and TAG for the review and constructive feedback!

We're (still) worried that this is a very significant change to URL syntax and processing

I'd just like to get clarification on this point - our original idea of mucking with URLs themselves was dropped. The proposal as it stands it entirely a change to fragment processing in HTML documents only. There are some significant changes here but this seems less scary than changes to URLs so I'd just like to confirm this comment is referring to the most up-to-date spec.

We're also worried that this doesn't have a clear path to standardization. Where do you intend to take this after WICG?

The current spec is monkey-patching HTML so I think it makes sense to move there if/when we can get additional implementer interest.

[lilles]

In addition, Blink now has an intent to ship support for the ::target-text selector as specified in css-pseudo which supports styling the text fragment highlight.

[bokand]

We're (still) worried that this is a very significant change to URL syntax and processing

I'd just like to get clarification on this point - our original idea of mucking with URLs themselves was dropped.

@hober A ping on clarifying this point; this is entirely specified as HTML fragment processing. The spec is now much clearer about how processing the fragment directive works and what it means for various edge cases to do with URLs.