[css-scroll-anchoring-1] Questions about anchor node selection

[eqrion]

Hello! I'm working on implementing this specification in Gecko. Here's the intent email.

I have a few questions regarding the anchor node selection algorithm. [ref]

1. Should position: sticky be considered an excluded sub tree like position: fixed?
2. Should scrolling boxes be considered opaque for the purposes of candidate selection? (e.g. they can be scroll anchors but stop candidate selection from traversing their children) If not, then it seems a node could be the anchor for two different scrolling boxes. I'm unsure if that's desired.

cc @skobes @theres-waldo

[eqrion]

I was going to file this in a separate issue, but I think it makes sense to post it here.

Currently the specification says:

Conceptually, a new anchor node is computed for every scrolling box whenever the scroll position of any scrolling box changes. (As a performance optimization, the implementation may wait until the anchor node is needed before computing it.)

When is a scrolling boxes anchor initially computed, and what are the cases the anchor needs to be recomputed?

From skimming the Blink code for ScrollAnchor, it looks like:

• A scrolling box can only have an anchor when it's scrolled from its origin
  • So scrolling boxes only get an anchor after scrolling for the first time
  • Scrolling to the origin will remove the anchor, causing it to be 'anchored to the origin'
• Removal of the anchor node will cause the anchor node to be recomputed
• A scroll adjustment suppression happening with a non-zero adjustment will cause the anchor node to be recomputed

Is this assessment correct?

[skobes-chromium]

I'm excited to see this intent. :)

Blink excludes position: sticky as well as position: fixed. Sticky objects aren't suitable anchor nodes, since even if they're currently un-stuck, we don't know that they won't be stuck after a future scroll anchoring adjustment.

If scrollers are nested it is possible for outer and inner to both anchor to the same object (inside inner). I'm afraid I can't remember the reasoning behind descending into inner scrollers for anchor selection. It may have been so that the outer scroller could "finish" an adjustment if the inner scroller didn't have enough room to scroll the desired distance. But I'm not confident Blink handles that case properly.

You're correct that we don't do any scroll anchoring (including anchor node computation) when the scroller is at its origin.

In Blink the anchor node gets computed at layout time, with caching and invalidation triggers. The invalidation triggers are the two you mentioned (removal of anchor node, adjustment suppression) plus a third trigger which is when any explicit (user- or script-initiated) scroll occurs.

The caching and lazy recomputation are designed to ensure:
(1) if there are N relayouts without any user scrolls, we don't recompute the anchor N times (because the anchor node gets reused)
(2) if there are N user scrolls without any relayouts, we also don't recompute the anchor N times (because we don't need it until there's a layout)

The spec is written to permit these optimizations (but doesn't mandate them).

[eqrion]

Thanks for the reply, that helps a lot!

The only comment I have is that the current implementation in Gecko doesn't select an anchor inside of another scroller. If this behavior is required for some reason it'd be good to know the reason, but otherwise it doesn't make sense the way it's implemented.

As for the rest of the clarifications, I think we should add the bit about 'position: sticky' and the parts about when scroll anchors are recalculated to the specification. I don't want to mandate optimizations in the spec, but the parts about not selecting an anchor at the origin, and invalidating after adjustment suppression seem to be about correctness.

I can open a PR with these details if there's not a problem.

[skobes-chromium]

Yes we should update the spec for the issues with sticky and origin; feel free to open a PR. I thought we had something in there about not scrolling away from the origin but I can't find it now. :-/ Thanks!