Intent to Ship: Document-Policy: force-load-at-top (opt-out for text-fragment)

[David Bokan]

Contact emails

bo...@chromium.org

Explainer

https://github.com/WICG/scroll-to-text-fragment#opting-out

Specification

Main spec: https://wicg.github.io/scroll-to-text-fragment/

Pull-request describing changes being requested here

Design docs

https://github.com/WICG/scroll-to-text-fragment#opting-out

TAG review

For broad text-fragment feature (but this didn't include opt-out discussion): https://github.com/w3ctag/design-reviews/issues/392

Summary

ForceLoadAtTop provides an opt-out for Scroll To Text (and other load-on-scroll behaviors as they are also affected by the issues raised in https://github.com/WICG/scroll-to-text-fragment/issues/76) for privacy sensitive sites, as discussed in https://github.com/WICG/scroll-to-text-fragment/issues/80. The ForceLoadAtTop feature allows sites to indicate that they should always be loaded at the top of the page, blocking any scroll-on-load behaviors including text fragments, element fragments, and history scroll restoration.

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/ONn6qsdwHUo/zHqyNL46BQAJ

Risks

Interoperability and Compatibility

Interop Risk - The usual adoption by other browsers risk applies. Chromium is currently the only shipping implementation of text fragments; however, this feature is tied to that so there isn't much new risk in that regard.

Compatibility risk - none, as a new API existing pages should be unaffected.

Note: as this isn't a standalone feature and is a small follow-up to the already-shipped text-fragments feature (requested by our security reviewers when that was being considered, ready now that DocumentPolicy headers are approved to ship), we haven't solicited feedback specifically for this individual aspect. If API owners feel this is significant enough to warrant I'm happy to reach out to Gecko and WebKit engineers.

Gecko: No signal
WebKit: No signal
Web developers: No signals

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes https://wpt.fyi/results/scroll-to-text-fragment/force-load-at-top.html

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1047900

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5744681033924608

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

On Sat, Aug 8, 2020 at 1:47 AM David Bokan <bo...@chromium.org> wrote:

Contact emails

bo...@chromium.org

Explainer

https://github.com/WICG/scroll-to-text-fragment#opting-out

Specification

Main spec: https://wicg.github.io/scroll-to-text-fragment/

Pull-request describing changes being requested here

Design docs

https://github.com/WICG/scroll-to-text-fragment#opting-out

TAG review

For broad text-fragment feature (but this didn't include opt-out discussion): https://github.com/w3ctag/design-reviews/issues/392

Summary

ForceLoadAtTop provides an opt-out for Scroll To Text (and other load-on-scroll behaviors as they are also affected by the issues raised in https://github.com/WICG/scroll-to-text-fragment/issues/76) for privacy sensitive sites, as discussed in https://github.com/WICG/scroll-to-text-fragment/issues/80. The ForceLoadAtTop feature allows sites to indicate that they should always be loaded at the top of the page, blocking any scroll-on-load behaviors including text fragments, element fragments, and history scroll restoration.

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/ONn6qsdwHUo/zHqyNL46BQAJ

Risks

Interoperability and Compatibility

Interop Risk - The usual adoption by other browsers risk applies. Chromium is currently the only shipping implementation of text fragments; however, this feature is tied to that so there isn't much new risk in that regard.

Compatibility risk - none, as a new API existing pages should be unaffected.

Note: as this isn't a standalone feature and is a small follow-up to the already-shipped text-fragments feature (requested by our security reviewers when that was being considered, ready now that DocumentPolicy headers are approved to ship), we haven't solicited feedback specifically for this individual aspect. If API owners feel this is significant enough to warrant I'm happy to reach out to Gecko and WebKit engineers.

Gecko: No signal
WebKit: No signal

Did we ask for signals for the broader feature?

 

Web developers: No signals

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes https://wpt.fyi/results/scroll-to-text-fragment/force-load-at-top.html

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1047900

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5744681033924608

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a2220a9c-ed97-4a4c-bb5d-57197ff54986o%40chromium.org.

[David Bokan]

Interoperability and Compatibility

Interop Risk - The usual adoption by other browsers risk applies. Chromium is currently the only shipping implementation of text fragments; however, this feature is tied to that so there isn't much new risk in that regard.

Compatibility risk - none, as a new API existing pages should be unaffected.

Note: as this isn't a standalone feature and is a small follow-up to the already-shipped text-fragments feature (requested by our security reviewers when that was being considered, ready now that DocumentPolicy headers are approved to ship), we haven't solicited feedback specifically for this individual aspect. If API owners feel this is significant enough to warrant I'm happy to reach out to Gecko and WebKit engineers.

Gecko: No signal
WebKit: No signal

Did we ask for signals for the broader feature?

Yes, they're listed at https://chromestatus.com/feature/4733392803332096

Mozilla: "Non-Harmful bordering on harmful" https://github.com/mozilla/standards-positions/issues/194 

WebKit: Neutral https://lists.webkit.org/pipermail/webkit-dev/2019-December/030996.html

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Chris Harrelson]

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a2220a9c-ed97-4a4c-bb5d-57197ff54986o%40chromium.org.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/88ddd290-c9fa-4e79-a828-f2b6daaf3f43o%40chromium.org.

[Mike West]

LGTM2.

[Yoav Weiss]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/462386b1-e1ae-4619-9240-8f45f43bd4adn%40chromium.org.