Add opt-in/opt-out mechanism #80
Comments
|
An alternative (syntax-wise) we're looking into is using feature-policy. However, I think the semantics would be the same as described above. |
|
Is this implemented in M80? |
|
Im thinking that just adding a redirect in a page header that triggers on :~: might work, but really a whole domain needs to be able to block this. regardless, adding this to a browser just violated the security of millions of web pages, mostly medical. |
No, an author-usable opt-out will be in available M82. Users who want can disable this for now using chrome://flags/#enable-text-fragment-anchor |
Add a document policy that lets pages opt out of scrolling that automatically happens on page load. This provides an opt-out to the Scroll To Text feature (see bug and [1]), but also applies to fragment scrolls and scroll restoration. With the DocumentPolicy feature[2] enabled, pages can opt out of these types of scrolling by adding the HTTP header: Document-Policy: force-load-at-top [1] WICG/scroll-to-text-fragment#80 [2] https://github.com/w3c/webappsec-feature-policy/blob/master/document-policy-explainer.md Bug: 1047900 Change-Id: Iebba7fd24fa2e362bfa4a8f77903763b5d95b787 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2073138 Commit-Queue: Nick Burris <[email protected]> Reviewed-by: Ian Clelland <[email protected]> Reviewed-by: Daniel Cheng <[email protected]> Reviewed-by: Kinuko Yasuda <[email protected]> Reviewed-by: David Bokan <[email protected]> Cr-Commit-Position: refs/heads/master@{#748465}
|
In the case of a meta tag, whatwg/html#2335 suggests it should rather be: |
|
We've implemented the opt-out as a force-load-at-top document policy (described in the explainer), and created an origin trial to bridge the gap until document policies ship. I wanted to add some spec text describing the document policy, but I'm not sure where it would live. AFAICT the document policy spec doesn't define a set of policies. @clelland do we have a way of standardizing available policies that I should add |
|
FYI: I have added the OT info to the article. |
|
Hi @nickburris On the page you linked to, it states " To allow websites to opt out of text fragments, we propose adding" Emphasis my own. Then you state, "We've implemented the opt-out " Can you let me know if this actually works right now, or it will be available in M82? Thanks a lot! |
|
This works from Chrome 83–84. The origin trial link to opt-in is https://developers.chrome.com/origintrials/#/view_trial/3253850730775183361. |
|
Thank you for the reply. Sorry if this sounds rude, but it looks really unattractive on some websites I manage. Is there any way to change the highlight colour that you know of? |
|
While at the first sight it looks like
@nickburris I believe this is unstylable on purpose. Can you confirm? |
|
I opted in to the origin trial and it had the effect of disabling element fragment identifier based navigation at all times, not just on load. Is this intentional? Thanks |
|
This is indeed intentional. From the origin trial's description: "The ForceLoadAtTop feature allows sites to indicate that they should be loaded at the top of the page, and not perform any scroll on load, including element fragment identifiers, scroll restoration, and Scroll To Text." |
|
Thanks for the quick reply. My reading of that passage is that scrolling is only restricted on load. |
|
@nickburris to clarify if it's intended for first load only, or throughout the session. |
|
Sorry, that's a bug in the implementation. I've filed https://crbug.com/1091247 The highlight used is the same one as from find-in-page. AFAICT that cannot be changed. I'd support adding styling options - it's something we considered early on and agreed would be useful but didn't make the cut for the initial set of features. That said, there's no immediate plans to add it at this time. |
I guess it's using the |
There's an unofficial registry at https://github.com/w3c/webappsec-feature-policy/blob/master/features.md (to be official per w3c/webappsec-permissions-policy#366). |
Thanks for the link! That looks specific to Feature Policy (now Permissions Policy). The Document Policy spec mentions it has an attached registry but I couldn't find it. I've added related spec text text-fragments in #131 - @clelland can verify if there's a registry we should also add the new document policy to. |
FYI: There's discussions afoot on how to do this in w3c/csswg-drafts#5233 |
|
The ForceLoadAtTop origin trial ended on the 30th Sept and the "Document-Policy: force-load-at-top" method doesn't appear to have shipped yet. Is anyone able to extend the origin trail end date? |
|
The DocumentPolicy is shipping in M86 which is being pushed out in the next few days. |
|
I have seen discussions about allowing authors / sites to opt out, but there seems to be a lack of concern for users to be able to opt out. Granted, this feels like a more general discussion, but perhaps web standards need to be more user-centric as well? EDIT: I forgot there's #122 |
As shown in #76 and #79, there are ways to leak information across origins due to the initial scroll. They rely on specific circumstances on a page so they aren't general but they are possible so we should consider ways to mitigate them.
I think it'd be useful to add a mechanism for a page to opt out of fragment navigation. i.e. Guarantee it'll load at the initial scroll offset. This can opt-out of element-id and name based fragments as well, which are susceptible to the same issues.
IMHO, it'd also be reasonable for UAs to weigh the trade-offs differently so I'd like to explore adding an auto|on|off switch. By default (auto), the UA can decide whether or not to scroll into view. "On" would be a signal that the page has explicitly deemed it ok to scroll on load and allow all UAs to scroll to a fragment whereas "off" would block all UAs from scrolling into view.
The highlights themselves, if implemented according to spec, aren't detectable by pages so I think this opt-in/out need only apply to the scrolling aspect.
A meta tag seems like a good start to me but I'm open to alternatives. e.g.
The text was updated successfully, but these errors were encountered: