You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 positionIn 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 a0
(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.
The text was updated successfully, but these errors were encountered: