[css-anchor-position-1] Could anchor positioning work for defining the targets of sticky elements?

[kizu]

Not to confuse with #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

position: sticky;
top: 10px;

we virtually anchoring our element to the max() of either the nearest ancestor scroll container’s scrollport + 10px, and its containing block.

In pseudo-code we could express this as if it was

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?

(originally posted in #2496)

Specs:

• anchor positioning
• sticky positioning

[kizu]

Another potential use-case for this — accumulating the sticky elements, like when headers of different heights are stacking together. Right now, we have to either hardcode the top of the following stuck elements reusing the heights of the previous elements, or use JS and resize observers to read the previous elements' heights and apply them dynamically to the following stuck elements.

An example of such headers: https://kizu.dev/scroll-driven-animations/#joined-sticky-headers — there I had to hardcode the additional offset.

With anchor positioning working with sticky elements, I can see using it something like “max(viewport top edge, previous sticky element's bottom edge)”. For sticky elements, probably it would make sense to treat regular values as relative to the viewport edge, as they're treated now, and mentions to the stuck anchors would use their bottom edge position relative to the viewport edge instead.

And if the acceptance criteria would stay the same — using the last available sticky element that comes in the tree before the one where we're using the anchor(), then the code for this could be very concise:

.header {
    anchor-name: --header;
    position: sticky;
    top: max(0, anchor(--header bottom));
}

And that's it! Each consecutive header would compare the bottom edge of the previous header and the top edge of the viewport, and would either stick to the viewport, or to the previous header.

[bramus]

Another potential use-case for this — accumulating the sticky elements, like when headers of different heights are stacking together.

This functionality has been requested before, for example in #2496 (comment).

I like the syntax you proposed, but am concerned when you have multiple of the same elements that need to stick.

<main>
<h1></h1>
<h2 id="first"></h2>
<h2 id="second"></h2>
<h3></h3>
<h2 id="last"></h2>
</main>

If you have the h3’s stick against the h2’s, and the h2’s against the h1 you basically want an h2 that is about to get stuck to push an earlier h2 that was stuck out of view, instead of overlapping it (as they currently would do). In the snippet above, #second should push #first out of view.

Furthermore, the #last h2 would need to push not only the preceding h2 #second out of view, but also the h3. If they would stack against each other, the #last h2 would be stuck against the h1, yet the other h2’s and the h3 would still be visible underneath.

[kizu]

I think this might be a case where wrapping things in sections could help. This way, each sticky element would know where it should stop being stuck.

Something like this (hard-coded modified top there): https://codepen.io/kizu/pen/zYMmdMb?editors=1100

<main>
  <h1>First-level header</h1>
  <section>
    <h2>Second-level header 1</h2>
  </section>
  <section>
    <h2>Second-level header 2</h2>
    <h3>Third-level header</h3>
  </section>
  <section>
    <h2>Second-level header last</h2>
  </section>
</main>

Screen.Recording.2023-07-27.at.00.26.33.mov

Now that we have subgrids (and display: contents), wrapping content with sections this way should be ok.

[bramus]

Yes, but adding extra depth/structure is not always possible. Think of a markdown file that gets converted to HTML, which is quite common.

[kizu]

Agree (though, usually, if you have access to the markdown engine, you could hack around the addition of the sections in your project).

I would need to play a bit more with things, but I think it could be possible to then use explicit unique anchor names for various headers, and use min()/max() to define how the stickiness should behave.

Either way, in my opinion, if it is possible to provide a convenient and concise API for a case when we can control HTML and then improve the other cases, even if in a rather awkward/hacky manner — it is better than nothing.

If there were a better and more feasible proposal, it would be nice to have anything that would improve the current position: sticky, but I think anchor positioning (as it is defined now) can be reused to improve stickiness substantially.