Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-position][css-anchor-position] Duplicating "sticky" behavior for anchored elements#10248

Open
tabatkins opened this issue Apr 25, 2024 · 0 comments

Comments

@tabatkins
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant