Finer-grained opt-out

[geofft]

Right now it seems like the only way to opt out is via the origin trial that disables all scrolling-to-not-the-top, including via traditional anchors (even anchors from the same site, same page, if I'm reading that right?) and via reopening closed tabs.

I'd like a way, as an author, to disable scroll-to-text-fragment (or even just scroll-to-text-fragment from outside sites) while keeping anchors working and while allowing users who have manually scrolled to restore their position. I don't think it's helpful for my users to be linked to arbitrary locations in the page from Google Search, and I'd like control over that without giving up on anchors entirely (I'm totally fine with Google Search linking to anchors that I've defined).

As far as I can tell, there isn't even a way to determine with JS that scroll-to-text-fragment was used, so I can't automatically un-scroll: "It's stripped out from the URL during document loading so that it's completely invisible to the page."

(I'd also like a way to disable scroll-to-text-fragment entirely as a user and automatically strip the anchor from URLs in the location bar, largely because I find the user experience frustrating, but I suppose I should report that to my user agent than to the spec itself.)

[bokand]

Thanks for the feedback.

Right now it seems like the only way to opt out is via the origin trial that disables all scrolling-to-not-the-top

That's correct (though the opt-out is coming out of origin-trial and shipping in Chrome M86).

I don't think it's helpful for my users to be linked to arbitrary locations in the page from Google Search

I can understand that point of view, but IMHO there's a trade-off to keeping a consistent experience for users.

Google Search is only one use case here - it might be reasonable for sites to have an opt-out from Google Search generating a text-fragment link on a page (though I can't speak for Google Search).

OTOH, I'm weary of blocking the feature itself. UAs can provide user features to link to specific parts of text. It would be confusing and difficult to explain why the feature only works on some pages but not others.

The original reasoning for the opt-out is that there are some narrow cases where scrolling-on-load can leak information (see #76). The opt out mentioned above was introduced to make it easier for authors who fall into such a case to protect against it, but it applies to all the scroll-on-load methods since they're all vulnerable.

As far as I can tell, there isn't even a way to determine with JS that scroll-to-text-fragment was used

Correct, but I do think there are uses for exposing this in a JS api. Given that I think you could build what you want. I've proposed one such API shape in #128

(I'd also like a way to disable scroll-to-text-fragment entirely as a user and automatically strip the anchor from URLs in the location bar, largely because I find the user experience frustrating, but I suppose I should report that to my user agent than to the spec itself.)

Yeah, this would be up to the UA. Speaking for Chrome specifically, Chrome tends to avoid adding customization options. That said, I agree the current UX leaves much to be desired; it's under active redesign. Feel free to file a bug at https://crbug.com/new

[geofft]

Thank you for the reply! And I appreciate that Google Search is not really in scope here (though I assume there was some coordination between the teams internally :) ) - mostly I just think that this spec can say "These are recommended and discouraged uses of this feature," and if some site chooses to go forward with a discouraged use, that's on them.

This spec is introducing a new behavior relative to the existing scroll-on-load features; the ability of an outside site to control the display of my site, both in terms of scrolling and in terms of highlighting. Previously, the only ways to trigger a scroll on load are a) the site itself offers anchors (and it can choose to add them where it wants and perhaps add none if it wants) or b) the browser is restoring a page previously scrolled by the user (and that's part of the site-designed interaction with the user). Now the user agent can scroll on a request by a third-party site. Yes, technically, it is the user agent doing it in response to a user click, but the user agent is really fulfilling a request from a third party.

Now I think this feature is neat enough that I might even use it internally (and I'm definitely not asking for it to be off by default), but I'd like some way to control what a third party does to the display of my site.

The specific use case I have is that I run a website that contains discussions about personal digital security, and (as I'm sure you know from working on the web platform :) ) this topic often has subtleties and use-case-specific complexities. I'm worried about a third party (any third party, really, though Google seems to be the primary user at the moment) linking to my site and highlighting "Personally, we don't think antivirus is worth the risk" (or whatever) halfway into a section without the prior paragraph of why we made this choice and what the tradeoffs are and why that answer doesn't apply to everyone. I'm fine with third-party sites linking to a section header if I make an anchor to it.

(And yes, Google Search has their "snippets" feature which can quote a part of my site in big text without context, and that's a problem too, but I expect I can't do anything about that and it's out of scope for this project anyway.)

UAs can provide user features to link to specific parts of text. It would be confusing and difficult to explain why the feature only works on some pages but not others.

Sure, but this is already the case: if I delay loading the body in some fashion, then the UA won't be able to scroll to it, right? This can even be done unintentionally by a sufficiently-slow client-site-rendered site. (Actually, maybe I missed this, but when is the fragment evaluated? DOMContentLoaded? Later? Continuously?) Or, alternatively, if the text is inside an iframe, or the text is actually an image because you used Microsoft FrontPage twenty years ago and haven't updated your site, or whatever, then the UA won't be able to find it.

Or what if it's one of those fancy startup landing pages where scrolling down actually just moves some shiny images sideways? I think it would be less confusing for those to start from the beginning instead of part of the way through, and I don't think people would intuitively expect a feature for scrolling through text-based sites to "scroll" these pages too.

Basically, since the web is already not a Gopher-style (or HTML 2.0-style) collection of text documents with minimal markup, there will be some sites where this doesn't work, so I don't think that people will in practice expect the feature to work consistently everywhere.

(BTW, looking around at the linked issues, Mozilla's "non-harmful bordering on harmful" position seems to match my view - I think this feature is has a bunch of neat and useful use cases, but I also have worries about it going wrong, and I don't have a good sense of how they weigh against each other.)

Given that I think you could build what you want. I've proposed one such API shape in #128

Yeah, I think that could work. It'd be something like window.addEventListener('DOMContentLoaded', event => {if (window.location.fragmentDirective && !window.location.hash) {window.scroll(0, 0)}}) I guess? (Assuming it is DOMContentLoaded?)

[bokand]

Apologies for the delay

I'm worried about a third party (any third party, really, though Google seems to be the primary user at the moment) linking to my site and highlighting "Personally, we don't think antivirus is worth the risk" (or whatever) halfway into a section without the prior paragraph of why we made this choice and what the tradeoffs are and why that answer doesn't apply to everyone

IIUC this is the "editorializing" concern that a third-party can selectively pull quotes from the content. This has been discussed in other issues like #109. It's a fair point. My own take is that this actually helps in most cases though. The alternative is a quote with a link to the page or a screenshot of the text. A user that won't read the surrounding context is unlikely to read the whole article and just take it at face value. Putting the user within the relevant context actually improves the odds that a user might read the surrounding context IMHO. Our goal is to replace the screenshot of a highlight, common on Twitter; those often don't even come with a link to the source.

That said, it's not my place to decide for authors what's worth worrying about and I agree authors should have full control over how their content is presented. To that end, you may be interested in the upcoming ::target-text proposal - this is currently being prototyped in Chrome. You'll still get scrolling but you could hide the highlight which might be a reasonable compromise?

Basically, since the web is already not a Gopher-style (or HTML 2.0-style) collection of text documents with minimal markup, there will be some sites where this doesn't work, so I don't think that people will in practice expect the feature to work consistently everywhere.

There's definitely cases where it won't work but the idea was to extend the capabilities to make it work in more cases over time. My hesitation here is it would be a step in the other direction.

Actually, maybe I missed this, but when is the fragment evaluated? DOMContentLoaded? Later? Continuously?

As per spec, this is part of the scroll to the fragment steps which happens as part of the navigation but allows some UA-defined wiggle room. In Chrome, IIRC, this will happen after the first layout after parsing, then again at the Load event.

[jnjaeschke]

I had an internal discussion with @zcorpan and I feel it makes sense to hijack this issue instead of creating a new one.

I could see in the Blink implementation that there are some domains excluded explicitly. My interpretation is that no text directives can be created in web pages that are in that list.

While it does make sense to not create links with text fragments for pages like Google search, Facebook, Twitter start page, Reddit start page, etc., I don't think it is a good idea to have this hard-coded on the User Agent's end. It's impossible to have an exhaustive list, and while the current blacklist may be a sensible selection, at the end of the day it's the page author's decision.

Therefore I would suggest the page being able to allow the user agent to create a text directive or not. I'm not sure if force-load-at-top could be used for this as well -- but in most cases I would expect a page that doesn't allow scrolling to a text fragment would also not want the User Agent to create a Text Fragment. But I may be missing edge cases here (?)

[tomayac]

+1 to not hardcoding this list of known-not-to-work origins. But also -1 to making this page opt-out more than an optional indication. One way to handle this could be additional text that the UA shows if a page has opted out, like in this poor mockup:

[bokand]

(note: there's some relevant discussion in #226)

The blocklist above does not block text directives on those pages. It prevents Chrome UI from showing the "Copy Link to Highlight" option. A manually/externally created text directive URL to these pages will still work.

The reason the option is hidden is that these are popular pages that change frequently or are personalized so link-to-highlight is unlikely to work well on these pages, it's likely to cause end-user confusion. I agree an explicit block list isn't a great solution, but this is a browser UI product decision rather than a web platform issue. (aside: it'd be nice for this feature, and others, if "personalized feed" style pages had some way to declare themselves as such - "this content is likely to be different across time and users").

Using force-load-at-top as a signal to hide the UI option also makes sense to me - I thought we already did that but trying it now it seems not - I filed a bug to track this in Chrome.

[bokand]

I'm going to close this issue in favor of #226 - lets continue the discussion there.

[zcorpan]

#226 is about separating text fragment scrolling opt-out from regular fragment scrolling. The opt out of "copy link to highlight" context menu item discussed above seems like an orthogonal issue (and no comments about this in 226). Can we repurpose this issue for that, or start a new issue?

[bokand]

I'd prefer to file a new issue since this one started off as separating text-fragment scrolling from regular fragment scrolling, just as #226.

That said, do we need a separate issue for that? It seems to me that whether or not "Copy link to highlight" is shown should be determined by whether or not text-fragment scrolling is enabled, is that not the case?