[css-selectors] :stuck pseudo-class feature suggestion

[o-t-w]

I would like to propose a new pseudo class for use in conjunction with position sticky.
When an element with a position of sticky is fixed, it would have a pseudo class of :stuck
I see people do this all the time with javascript.

One example can be found https://percussionplus.co.uk/checkout/ where the checkout gets a box-shadow when it goes from acting as if it was statically positioned to acting as if it was fixed positioned.
One very common use case: People often animate the height of sticky headers when the user starts scrolling.

I'm sure this would be easy for browser vendors to implement.

[frivoal]

Actually, this wouldn't be easy at all, and falls into a class of problems that unlikely to be solvable in CSS: selectors and pseudo classes in particular cannot depend on layout, because otherwise they could be used to modify layout in a way that made them no longer match, which would modify the layout back to where it was, so they match again, and we get stuck in an infinite loop of contradictions.

For a simple example:

:stuck { position: static; }

Now what?

Some of the changes you might want to apply with a :stuck pseudo class may be safe and not trigger such loops, but selectors are a generic mechanism, and would enable this kind of contradictions, so even though the problem you're trying to address seems legitimate to me, selectors are unlikely to be the answer.

[o-t-w]

You could simply disallow/make invalid anything that could cause an infinite loop.

[tabatkins]

You could simply disallow/make invalid anything that could cause an infinite loop.

Say we did this, and explicitly disallowed setting position in a rule targeting a :stuck element. Okay, this works for this case.

Next week, someone comes up with a similar circularity they want to allow (like my Toggle States proposal, which has properties interacting with :checked). We disallow that circularity too.

Now someone writes

.foo { toggle-states: 2; toggle-initial: 1; } /* makes it checked */
:checked { position: sticky; }
:stuck { toggle-states: none; }

When it's checked, it becomes sticky. (Assume the page is scrolled such that it becomes stuck immediately.) When it's stuck, it becomes uncheckable, which means it's no longer sticky, so it's not stuck, so it goes back to being checkable, and so it's checked, and so it's sticky, and so it's stuck, and so it's uncheckable...

If you add a third selector/property pair, the number of cycles you need to manage gets even larger.

The only way around this is to define that none of the properties that affect selectors can be used in rules using any of the selectors affected by properties. That ends up with a lot of confusing action-at-a-distance: it's weird that using :checked means that you can't set position: sticky any more.

Instead of doing all of this, so far we've just short-circuited the entire debate and disallowed selectors from being affected by properties.

[o-t-w]

Ok, all of that makes sense, thanks.

[cvrebert]

See also https://discourse.wicg.io/t/a-pseudo-class-for-when-an-element-is-stickily-spec-term-positioned/947/20

[hunboy]

I've worked around this behavior, and run in to some troubleshots.

the position: sticky behaves as a position: relative element by the spec. So when we change the height of the :stuck element, the complete layout changes based on the new height. As a workaround I defined margin-bottom for the :stuck element.
Here is the workaround code:

https://jsfiddle.net/utasir/92L8L85q/18/

I've added 1 indicator to the code, but this is against the separation theory of the style and html structure.
A compromised solution would be useful whilst this ticket is closed.

[zipper]

@tabatkins There are already possible CSS circularity problems, so should we remove :hover pseudo selector as well to prevent it?
https://codepen.io/zipper/pen/NYNEzM

[inoas]

Use JS(*) for that.

While I use :hover, :target and :checked a lot I don't think behavioral things should be in CSS (neither should be :active or :visited). In fact I think behavioral CSS should be deprecated and be disable-able. So: Adding more of these doesn't sound like a good idea to me.

(*) My 2 cents: JS still has its big issues in terms of language design, privacy and performance (DOM), but: use JS for behavior, not CSS; And if all it means is toggling classes - that's OK!
However: All built-in browser JS libraries and JS std-lib functions should really become bundled into standardized modules so that for privacy (or preformance) reasons people can disable whole modules/parts of JS/JS-browser-std-lib easily. If done well using HTML for semantic structure, CSS for layouting and JS for behavior/interaction becomes a sane thing again

[zipper]

The biggest advantage of position:sticky (apart from being very easy to use) is that you get rid of JS. So adding JS to detect when the position is stuck is contra productive. Then I could have just stayed with JS solution in the first place, even for sticking the element.

Checking if the element is stuck with JS means I have to do all the logic (including unstucking the element when bottomed the parent element) and don't need position:sticky at all. When I know (by some piece of JS), the element is stuck, I could "stuck" it by myself using position:fixed. So why bother with position:sticky in the first place (in this kind of use case)? The :stuck pseudo selector makes sense for me. Isn't position:sticky behavioural think by itself btw? So when arguing against behavioural thinks in CSS, this should be deprecated aswell?

[jonjohnjohnson]

@zipper position:sticky provides more than just swapping to position:fixed if you were running tabs on a scroll event. It also works within internal scrolling nodes, so you'd have to swap to position:absolute AND make sure the sticky-like element's offsetParent was the outer element of the node that is scrolling. It also behaves 'fixed' in one axis, unlike actual position:fixed fixing to a root context in both scrolling directions. So if you need to change something about the stuck element when it's stuck, yes JS is needed, otherwise it's out of scope of what position:sticky at least offers.

PS Even using the boundingClientRect of a sentinel element alongside the boundingClientRect of a sticky element is simpler and more foolproof than running JS to swap in position:fixed.