[css-position-3] Revisit the scroll position of sticky-positioned boxes

[flackr]

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.

[flackr]

@tabatkins WDYT?

[css-meeting-bot]

The CSS Working Group just discussed [css-position-3] Revisit the scroll position of sticky-positioned boxes, and agreed to the following:

• RESOLVED: Revert the change to how scroll position of sticky positioned boxes are calculated

The full IRC log of that discussion

flackr: There's a lot in the issue. Basically many years ago we tried to come up with a scrolling position behavior for sticky poisition elements when they overlap. Solved one use case but breaks another common on. Never launched in any browser
flackr: Prop is revert that change and explore other ways to handle this use case. For this issue it's just to revert
smfr: What's the behavior after the revert?
flackr: Current impl behavior that scrollposition of sticky position element is it's calcuated position
smfr: Doesn't use it's inflow position; that static position I think it's called
flackr: Sticky position, I think, yes. No one impl it those and many bugs against experiment
smfr: What about in fixed, assume it's in view?
flackr: Correct
TabAtkins: Sorry I missed ping flackr. This seems reasonable. No option is ideal but current impl behavior seems fine and compact impact is scary. Fine with prop
flackr: I have follow-up on improving edge cases but that's seperate
astearns: Concerns on reverting?
astearns: Prop: Revert the change to how scroll position of sticky positioned boxes are calculated
RESOLVED: Revert the change to how scroll position of sticky positioned boxes are calculated
astearns: I'm assuming discussion about other solutions are separate issues?
flackr: Yes