- From: Steve Kobes via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Nov 2018 23:01:32 +0000
- To: public-css-archive@w3.org
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). -- GitHub Notification of comment by skobes Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3319#issuecomment-438851634 using your GitHub account
Received on Wednesday, 14 November 2018 23:01:33 UTC