- From: Roman Komarov via GitHub <sysbot+gh@w3.org>
- Date: Thu, 01 Jun 2023 21:06:05 +0000
- To: public-css-archive@w3.org
Wanted at first to create a new issue, but thought that I could just comment in this one. The content of the issue I wanted to create: # [css-anchor-1] Could anchor positioning work for defining the targets of sticky elements? Not to confuse with https://github.com/w3c/csswg-drafts/issues/8448 where we would want to attach things to sticky elements and use their current sticky offset, but kinda the other way around: What if when we had an element with `position: sticky;` we could use `anchor()` for its inset properties? We can imagine that right now, when we set ```CSS position: sticky; top: 10px; ``` we virtually anchoring our element to the max() of either the nearest ancestor [scroll container’s](https://drafts.csswg.org/css-overflow-3/#scroll-container) [scrollport](https://drafts.csswg.org/css-overflow-3/#scrollport) + 10px, and its [containing block](https://drafts.csswg.org/css-display-4/#containing-block). In pseudo-code we could express this as if it was ```CSS position: sticky; top: max(anchor(scrollport top) 10px, anchor(containing-block top)); ``` Now, there are a lot of issues with the current sticky positioning, both for cases when we're limited by the containing block, and when we're limited by a stray `overflow: auto` that we want to ignore (these issues make us use portalled elements to the end of the body in production, as we cannot rely on `position: sticky` due to the possible wrappers that break it). After playing a bit with anchor positioning, I think that it could be a very elegant way to solve this maybe? What if when we'd use the `achor()` in inset properties for a sticky element we would essentially “ignore” the current way it handles the corresponding property (the fact that it uses two different wrappers to determine the offset), but would just use what we would give it? This way we could potentially “skip” any wrappers, like when we would want to only target a specific parent with `overflow: auto`, and we could also “skip” any extra wrapper divs that could go over our sticky element (like inside grids, and so on). Main issue I see is that we could actually want to target the _scrollports_ in a lot of cases, and not just the elements, not sure what would be the best way to handle this. But, overall, given that, in theory, we should be free to modify the offsets of the sticky elements based on other things similarly to how we can absolutely position things in a safe way, maybe we could reuse the anchors this way? Cc @xiaochengh & @tabatkins — I wonder if there are considerations that I miss, and how complicated is current sticky positioning from the point of adding something like that. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2496#issuecomment-1572783736 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 1 June 2023 21:06:07 UTC