[css-position-3] Revisit the scroll position of sticky-positioned boxes · Issue #7930 · w3c/csswg-drafts (original) (raw)

In #1459 I raised an issue around the behavior of scrolling sticky elements (or descendants) into view. In particular since scrolling an element into view used the sticky element's current bounding border box returned from getBoundingClientRect, this could result in:

• Repeated attempts to scroll the element to the top. E.g. If sticky elements not anchored to top: 0 are linked to in the anchor or the anchor itself is a part of the sticky element not at the top the anchor will (usually, unless resricted by their containing block) move after you scroll to their previous location.
• Anchor links and scroll into view not making anchor content visible. E.g. if the sticky containing block contains subsequent sticky elements those later elements typically cover up the earlier one. https://jsbin.com/simivof/edit?html,output is an example of this.

As a result, we updated the spec to use the non-offsetted position for scroll operations.

Since this update, chromium implements this behavior behind experimental web platform features which fixes this issue as well as issues with input fields combined with scroll-padding (e.g. bug 1178622) however the experimental behavior has also raised many bugs about the scrolling being unexpected (e.g. bug 1334207). I expect we will see many more bugs filed if we attempt to enable this behavior by default as input fields within sticky headers is a common practice for search fields.

The TLDR, we have two options:

1. Scroll to the current position - Current behavior in Chrome (without flag), Firefox and Safari.
2. Scroll to the non-offsetted position - Current spec behavior implemented in Chrome behind experimental web platform features flag.

I propose that we revert the spec change and go back to the currently shipping behavior (option 1) for two main reasons:

• It is the current behavior implemented in all major browsers and position: sticky use is rapidly increasing (at roughly 12.5% of Chrome page loads right now). Changing this is likely to break the experience on a lot of those sites.
• It is very hard for developers to work around issues caused by scrolling to the initial position, however there are (or could be) ways for developers to mitigate the issues with scrolling to the current position. In particular:
  • The anchor scrolling bug fixed by this issue could (at least in the identified use cases) be fixed by the developer changing the anchor to an element outside of the sticky positioned element.
  • The input scroll-padding issue could be fixed by improvements to the css-scroll-snap spec (see [css-scroll-snap] Support scroll-padding on all elements. #7931) which would allow developers to exclude the sticky positioned element from the scroll-padding. For now, they could work around it by applying scroll-margin to the particular elements that may be scrolled into view, though this is cumbersome.