bramus
commented
2 years ago Recently stumbled upon the limitation where I wanted multiple items to be sticky inside the same parent container, but without overlapping each other.
Given this markup:
<main>
<article>
<h1 />
<h2 />
<h2 />
</article>
<article>
<h1 />
<h2 />
<h2 />
</article>
</main>I want the <h1> elements to be sticky against the top edge of <article>, and want the subheadings <h2> to stick against the preceding <h1> that's already stuck.
Right now I fixed it by fixating the top for <h2> to equal the height of <h1>, but that only works if all <h1> elements have the same height.
article :is(h1, h2) {
position: sticky;
top: 0;
}
article h2 {
top: var(--height-of-h1); /* But what if the <h1> text wraps?! Uhoh! */
}👉 What I'm looking for is an easier way to say “Hey <h2>, stick against the already sticky <h1>”
Note that it's not a simple as saying “stick against the previously stuck element“, as you'd then end up with the 2nd <h2> sticking against the first <h2>, sticking against the <h1>.
💡 Could potentially be solved by leveraging some other specs and by expanding the functionality of selector() to mimic document.querySelector (see https://github.com/w3c/csswg-drafts/issues/5884#issuecomment-867117769)
h2 {
top: selector("h1:has(+ &)"); /* Selects the h1 that precedes self (&) */
}
johannesodland
brechtDR
sillvva
WickyNilliams
kizu
xiaochengh
https://drafts.csswg.org/css-position-3/#sticky-pos
TLDR Should "sticky" be defined by its own property that sets edge and distances within a containing block defined by the elements "offset parent".
I know that "sticky" behavior has already landed in all major browsers, buuuut I'm still gonna lay out how it confuses me after putting it through the ringer.
Rehashing Sticky
When something is "sticky" it boils down to these bits...
After setting an element as
position: stickythose bits are gathered in these ways...overflowset correctly).inlinewithposition: relativeand valid box offsets).auto, such asbottom: 0px.Issue 1 - Dual implication of the margin property?
The easiest issue to spot with this is mixing the use of margin for both normal flow AND the "sticky constraint rectangle". Its use for "SCR" in any meaningful way forces an author to offset that margin in normal flow with a sibling element, getting nice and hacky.
EXP Bottom sticky flag that's hidden in the fold, but scrolls in just after
EXP Nested lists with sticky headers/labels
So why not gather this length in a different way? Similarly to why
scroll-marginwas created to not just infer or force *hacky layouts for an author to fully leverage snapping?Issue 2 - Containing block as nearest block level ancestor?
Some aspects of layout require particular structures (like what's shown in this spec), so using the elements nearest block level ancestor instead of allowing authors more control over the creation of a "sticky constraint rectangle", has major tradeoffs.
I'd imagine using the box of the elements nearest positioned parent would give more control to an author instead of current proposal? Or at least using the "offset parent" until reaching the scrollport, then using that scrollbox?
Issue 3 - Other position schemes would be useful?
When we are already limited by the current containing block definition for "SCR", it's worse that we can't even use another position scheme to move the element around within that containing block. Not allowing for these position schemes, can force an author to sacrifice document semantics, when trying to place an element in a desired normal flow to then "stick" based upon that shifted position. Think of simply sliding an element around "relatively" or even "absolutely" pushing an element to the bottom side of its offset parent to then leverage "sticky" behavior at the bottom scrollport edge, when semantically the element isn't at the end of its sequence). And creating a hacky flex/order/margins/transform solutions doesn't fix the issues that come with not having access to relative/absolute position schemes. Even when losing flow placeholding with absolute, it can still be a desirable case.
Again, using an elements nearest positioned ancestor for the containing block could give meaningful positioning to the sticky element. Allowing the sticky element to leverage relative or absolute schemes for itself against its offset parent? I'd say even forcing that sticky behavior can only be applied to a positioned element in the first place, like how box offsets require position. Caveat being that fixed position affords no sticky affect.
Solution for all 3 issues?
In my understanding the information needed to set up sticky behavior (as well as proper optimizations, so one doesn’t need to set isolation or will-change, like is often needed now) is better suited from a separate property (and not creating a position scheme) such as...
A property where you could set a list of "sticky" edges, with their corresponding sticky start distance from scrollport edge AND end distance in the opposite direction from the edge of its containing block. If just the edge is set, then lengths are computed as
0? If only the start is set, the end computes to0which is surely a common case. For the property to have any affect the element, it must be positioned with a meaningful relationship to its offset parent containing block to create a "SCR". I've scraped through the spec and created an assortment of experiments leveraging sticky-ness and it seems like what I'm proposing (though most likely far too late to ever be considered anything more than vain) would be viable.