[csswg-drafts] [css-position][css-anchor-position] Duplicating "sticky" behavior for anchored elements (#10248)

tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-position][css-anchor-position] Duplicating "sticky" behavior for anchored elements ==
Note: this is just musing on the problem; I don't have a great idea of what the solution would look like yet.

Imagine you wanted to anchor a popup to some element elsewhere in the page (so you use fixpos or top layer for the popup). This anchor is in a scroller (perhaps just the root scroller). When the anchor scrolls off the page, you want the popup to stick around, a la stickypos.

Today, you can't do that. If you write something like `top: max(0, anchor(--foo bottom))`, intending it to line up with the bottom of the anchor *unless* it would go above the top of the screen, it instead happily goes above the top of the screen, staying stuck to the bottom of the anchor. This is because we keep it lined up with the anchor even across scrolling by applying a *post*-layout translation that matches the scroll offsets between the popup and the anchor. The actual inset is still calculated as if all the scrollers are in their initial position

In other words, we do *not* "correctly" adjust the result of `anchor()` to compensate for scrolls, in such a way that it can be usefully compared to a `0` (or *any* other value that depends on the CB, or a different anchor).

This behavior is well-motivated: we want anchored things to *always* look "correct" when flush against their anchor; having them lag by a frame because we need to pipe information from the scrolling thread back to the main thread and do layout is unacceptable. So scroll compensation has to happen in such a way that it can be done on the scrolling thread, which means it cannot adjust layout. (On the other hand, the expectations aren't nearly as strict for a larger movement, like from switching to a different `@position-try`. So we *can* lag by a frame, and full layout is acceptable.)

But "sticky" behavior still seems like it would be useful; stickypos is popular, after all. Stickypos gets away with its behavior (depending on the position of two things in different scroll contexts) because it is *guaranteed* to not adjust layout - it's just a magical relpos. We can't depend on that in abspos/fixpos, because if you change both insets in an axis you might change the element's size.

---------

In conclusion, I suspect we might want to spend some time thinking about a sticky adjustment mode that is separate from stickypos (so it can be used with abspos/fixpos anchor positioning), and which can guarantee it won't trigger layout.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10248 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 25 April 2024 19:34:05 UTC