Scroll To Text Fragment

[nickburris]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Scroll To Text Fragment
• Specification or proposal URL: https://github.com/WICG/ScrollToTextFragment

Other information

w3ctag/design-reviews#392

[annevk]

I guess it would help to summarize some of the issues I've seen:

1. Unclear processing model. It seems like this can be done without modifying the URL parser, but what exactly the processing model should be is not clear.
2. There are some risks with letting an attacker scroll a user to a chosen position and it's not clear the proposal goes to the fullest extent to eliminate these, e.g., Scroll To Text w3ctag/design-reviews#392 (comment).
3. The bits of the processing model I do understand mean that this needs to be stripped from the URL at some point to preserve user privacy (though the website can still look at the scroll offset to determine things). This creates a risk for non-implementing user agents and makes the new syntax less useful as a general way of extending fragments.
4. If this effectively triggers window.find() it would have been nice to clean up that first so they can use a shared primitive: Potentially standardize window.find() whatwg/html#3539.

(Also, if that highlight API comes of the ground I suppose it better be isolated from these highlights somehow.)

Overall though it seems like a useful feature to have.

[domenic]

Unclear processing model. It seems like this can be done without modifying the URL parser, but what exactly the processing model should be is not clear.

FWIW in my review of the spec I found the processing model fairly clear and precise. The entry point that you might find most clarifying are:

• https://wicg.github.io/ScrollToTextFragment/#processing-the-fragment-directive
• https://wicg.github.io/ScrollToTextFragment/#navigating-to-text-fragment

That said, it does appear that the draft spec does currently modify the URL parser/serializer. But the way in which it does so seems unobservable to any part of the ecosystem that doesn't specifically look at the "URL's fragment directive" concept. So I think it could be refactored transparently (i.e. with no testable effects) to put that parsing entirely in HTML (in particular in the first link above).

Edit: I see that there is an issue filed to perform that refactoring, at WICG/scroll-to-text-fragment#60.

[fred-wang]

4. If this effectively triggers `window.find()` it would have been nice to clean up that first so they can use a shared primitive: [whatwg/html#3539](https://github.com/whatwg/html/issues/3539).

I agree. I opened WICG/scroll-to-text-fragment#66

[bokand]

Update:

I think we've addressed points 1 and 2 (the latter in a yet to be merged PR WICG/scroll-to-text-fragment#70). Here's how the spec looks with the latter PR merged.

I agree with point 4 but I think this can be done as part of some cleanup at the time we'd merge this into the HTML spec. I don't think it's an issue with the feature itself or hinders interop for following implementations.

Re: point 3:

In addition to privacy, stripping the directive from the URL prevents the directive from interacting with author script in unexpected ways (see issues raised in WICG/scroll-to-text-fragment#15).

It's true that there is some risk here to non-implementing UAs. We believe the risk is low. Since the delimiter appears inside the fragment, a non-implementing UA will interpret it as a non-matching element-id fragment. In most cases this means such URLs will load at the top of the page which is a graceful fallback.

The one concern is pages that use the fragment for state. We've found pages like this that interact badly with the directive to be rare and think the benefit outweighs the risk.

As a (small) mitigation we could add a note in the spec/explainer/outreach to recommend users and tools avoid amending URLs that already have a fragment for now as well as feature detecting (where possible) whether the UA supports directives.

WDYT?

[bokand]

Post US-holiday ping.

Would it be possible to get an official Mozilla opinion on this feature?

[bokand]

There's been some discussion on twitter so I'm going to consolidate it here so it doesn't get missed:

On why we invented a new thing rather than implement fragmention (which is basically interpreting the fragment as the search string):

1. fragmentation doesn't work where the page uses fragment-based routing. Users might want to link to such pages and we can't tell a priori if it will work or not. It'd be confusing why some pages don't work.

2. We initially started with a simple fragmentation-like approach. However, after lots of trials with Google Search we found a naive text string doesn't work consistently in those use cases. Notably, there's issues with ambiguity (particularly in cases like trying to select a table column/row header or dates), and non-contiguous passages that are broken by things like images. I'll see if I can get these results published publicly. We received the same feedback from the WebAnnotations community in the HackerNews post and then again in our issue tracker.

3. Privacy. It makes sense to hide the text query string from even the destination page. Without the :~: syntax and fragment stripping, the page would be able infer sensitive information e.g. a user's search terms.

[bokand]

I'd also point out that we've engaged and taken feedback from several experts in this space ( WICG/scroll-to-text-fragment#4 is a good example). That issue has posts from the author of fragmentation, founder of hypothes.is and others (I believe related to web-annotations).

IMHO, we've been (and will continue to be) openly receptive and grateful for the feedback we've gotten as it definitely improved the outcome - we didn't build this in a vacuum.

[bzbarsky]

Just to be clear, no one is saying you built this in a vacuum; we're just trying to evaluate the proposal and trying to gather as much information as we can so the evaluation can be informed by that.

[bzbarsky]

https://bugs.chromium.org/p/chromium/issues/detail?id=961440 is relevant here as an example of #194 (comment) item 1 -- webmd has issues when it sees a fragment that it does not control.

[dbaron]

My high-level opinion here is that this a really valuable feature, but it might also be one where all of the possible solutions have major issues/problems. So I think the question we should think about is how the problems of the solution chosen here compare to the problems of other options and how they compare to the value of the feature.

[bzbarsky]

@tantek and I looked through:

• https://docs.google.com/document/d/1eK5xcWo1T7M-SguRshahy53zHMvkvVzxIjVWZm34o-U/edit
• https://indieweb.org/fragmention
• https://wicg.github.io/ScrollToTextFragment/
• https://github.com/WICG/ScrollToTextFragment
• https://bugs.chromium.org/p/chromium/issues/detail?id=961440

and various issues on the ScrollToTextFragment repo. We have various concerns about this standards proposal.

Some of the problems it has (e.g. lack of clear processing model) are shared by #234 as well.

Also, both proposals fail to address some use cases (e.g. highlighting the entirety of a particular row on https://www.x-rates.com/table/?from=USD&amount=1) that came up during our discissions about this. Those use cases might be better-served by some other XPointer-like mechanism, possibly; more investigation is needed there.

A draft position we are proposing:

---

Summary position: “non-harmful” bordering on harmful (could be convinced)

There are various use cases that this sort of API could address:

• Search engines linking to the searched-for text,
• Users bookmarking (and sharing) intra-document positions that don’t have pre-provided anchors.
• Marginalia being associated with the right part of the text.
• Citations.

Our general feeling is that some of these use cases are very important to address, but that the specific proposed solution of ScrollToTextFragment is highly biased towards the “search engines” use case and has some aspects that are harmful to the future development of the web, insofar as they encourage the creation of fragile links (so either “harmful” overall or averaged with “worth prototyping” to a summary position of perhaps “non-harmful”). We think it’s worth prototyping this proposal with the harmful aspects removed.

Specific notes we had:

1. The :~: prefix and the stripping of the fragment specifier seem necessary to deal with fragment-routing-based websites. The WebMD case described in https://bugs.chromium.org/p/chromium/issues/detail?id=961440 is a strong indication that such sites exist that users would want to use this functionality with. While it looks ugly, we judge this part worth prototyping on balance.
2. The marginalia use case described at https://indieweb.org/marginalia is not supported as well as it could be, since the fragment specifier is stripped from the URL. That significantly limits the ability of sites to show appropriate marginalia UX when the user loads a link to a specific text fragment. It could probably be addressed by exposing the fragment specifier via the FragmentDirective, modulo whatever the security considerations are with exposing this information to the page. As far as we can tell, those security considerations seem to be entirely driven by the search engine use case, and impose unnecessary constraints on the other use cases. That said, exposing the fragment specifier could be added in a V2 of the API; perhaps along with allowing URLs to opt out of having it exposed. That would need to be planned for in V1 syntax, possibly.
3. The capability to include multiple fragment specifiers does not seem to be clearly motivated by use cases and represents significant complexity. Apart from the complexity it introduces it’s probably “non-harmful”, though the fact that each fragment specifier effectively requires a full document scan per the security considerations document means that in practice links with multiple fragment specifiers are likely not a great user experience.
4. The capability to specify textEnd instead of the full text to highlight disincentivizes quoting the full text. Quoting full text is a practice that is more antifragile, and thus desirable, both for capturing the intent of the link creator, and for enabling better UI for inspecting such URLs by URL inspection libraries. While the proposal acknowledges this and recommends against using textEnd, it’s not clear to us that there is sufficient motivation to include the feature at all, given the problems it can cause. If implementation experience shows that long fragments specifiers a problem in practice, we feel the feature could be added at that point, as long as we carefully define that a comma terminates the search text.
5. The capability to specify a prefix and suffix likewise introduces fragility, as the proposal acknowledges. Again, there seems to be a lack of clear non-hypothetical motivating use cases. While https://docs.google.com/document/d/1YHcl1-vE_ZnZ0kL2almeikAj2gkwCq8_5xwIae7PVik/edit says “Experimentation has determined that it’s often the case that a desired section of text is ambiguous and impossible to target with just a simple match string”, there is no data presented to support that, and publishing + implementation experience with Fragmentions suggests that this is not “often” a problem, and as far as we can tell has not been a problem in actual deployed practice at all. We’re open to data showing otherwise, but have not seen any so far.
6. The security discussion, and the spec, prevent text fragment selection on same-document navigations. This seems like it would create significant user confusion. In particular, if a user pastes a URL with a text fragment selector for the current document in the URL bar, they would expect that to work, while the spec’s security considerations section non-normatively says that it shouldn’t and the processing model normatively prevents it. This specific restriction does not seem to be well-motivated by specific security concerns that we could find, and we would like to understand the motivation here better.
7. The specific rules around incumbentNavigationOrigin https://wicg.github.io/ScrollToTextFragment/#should-allow-text-fragment seem to ignore the common case when that origin is null (representing a navigation coming from the browser UI), and seems to lead to undesirable outcomes in that situation. Again, we would like to understand what specific security concerns are being mitigated here and why this is the right mitigation. This still seems to be largely concerned with the search engine use case, and addresses it at the cost of user-hostile behavior.
8. The actual processing model for searching for text is pretty much undefined. There’s a lot of spec text there, but it’s mutually contradictory and not implementable in its current state. See Initializing the TreeWalker WICG/scroll-to-text-fragment#73 for a basic issue that needs to be addressed before someone can even try to make sense of the text.

---