[css-selectors] Proposal for allowing selectors that depend on layout (:stuck, :snap, :on-screen, etc)

[argyleink]

Spec and WG writings:

• https://www.w3.org/TR/selectors-4/
• https://wiki.csswg.org/faq#selectors-that-depend-on-layout

Relevant proposals/issues:

• :snap proposal [closed]
• :stuck proposal [closed]

Background:
Proposals like :snap and :stuck have been rejected because the layout could be changed on the matched element, thus undoing what was done, which then redoes the effect.. forever. This can be seen in :hover effects that change layout and cause the mouse to go out and in of the element as fast as the browser can draw it all. Not good. Reasonable reason to reject the ideas.

Proposal:
Layout dependent selectors can only be selector participants and never the subject.

/* wouldn't work, not allowed */
:stuck { 
  position: static; 
  box-shadow: 0 1ex 1ch hsl(0 0% 0% / 25%);
}

/* would work */
:stuck > nav { 
  position: static; 
  box-shadow: 0 1ex 1ch hsl(0 0% 0% / 25%);
} 

The cycle is heavily mitigated or entirely eliminated by not allowing the layout relevant selector to target the element with the desired layout pseudo class. We provide the hook, but prevent the hook from changing itself. Thoughts?

Conclusion:
Instead of attempting some list of approved styles for layout dependent pseudo classes, 1 rule could help prevent tons of footguns while simultaneously unlocking many new effects. The catch is that developers will need an extra node in the component so the layout effect and the styles are separated (aka: the element being stuck isn't what has the box-shadow).

Update 1

as suggested by Oriol

1. pseudo-class cannot be part of a selector with + or ~
2. pseudo-class cannot be mixed with :has()

[Loirooriol]

I don't think this restriction is enough. Being able to select the contents means that you can affect the size of the sticky element through auto sizes, and thus whether it's stuck or not. See demo, which uses JS to crudely polyfill :stuck as .stuck, and only uses it in #sticky.stuck > *. It flickers since .stuck keeps toggling.

This circularity may be more obvious for similar proposals like :overflowed-content (#2011). Changing the contents can clearly affect whether the element has overflowing contents.

[argyleink]

agree that :overflowed-content isn't a candidate here 👍🏻

demo makes sense, bottom: 0 was a good position to expose. this proposal definitely isn't bullet proof, but feels like you need to get creative to find a way to break it. thanks for sharing your creativity.

[Loirooriol]

What about adding the additional constraint that :stuck can only match elements with size containment? I guess this would break the dependence on the contents.

[Loirooriol]

Also, I guess that there should be a child or descendant combinator (or pseudo-element?) after :stuck. + or ~ are not enough because if :stuck can impact later siblings, they can affect the size of the containing block, which can affect whether the element is stuck. Alternatively, the containing block should also have size containment.

And mixing with :has() should be invalid, or :has(> :is(:stuck > *)) would bypass the restriction.

[argyleink]

@Loirooriol interested in your thoughts regarding ways to make a child not snap given this proposal?

if :snap is only featured on children with scroll-snap-align: start, this proposal certainly prevents the snap-align value from being changed cyclically. Are there clever ways to change snapped items children contents insomuch they unsnap from the parent?

[Loirooriol]

No idea, I know very little about snapping

[tabatkins]

No, in fact the spec is pretty explicit about staying snapped to an element as the page mutates; only user action or unrecoverable mutations (like the snapped element being removed) should change the snap.

[argyleink]

The containment requirement seems promising: containment spec quote

By itself, size containment does not offer much optimization opportunity. Its primary benefit on its own is that tools which want to lay out the containment box's contents based on the containment box's size (such as a JS library implementing the "container query" concept) can do so without fear of "infinite loops", where having a child’s size respond to the size of the containment box causes the containment box's size to change as well, possibly triggering further changes in how the child sizes itself and possibly thus more changes to the containment box's size, ad infinitum.

Sounds like this proposal (adding pseudo classes that can only be a selector member) in combination with contain: layout which "nothing outside can affect its internal layout, and vice versa" as suggested by Oriol, would:

1. restrict all mutations to children
2. restrict all children mutations to not affect the container box

Those conditions seem like they do remove the infinite potentials, complimenting each other. Creates an effect similar to how position: relative results, that it's original box is still there but it's off doin whatever. In this new case, given new current browser state, a box is styled different but without modifying the original box space / page layout. A stuck header could freely change height due to children changing and not cause an infinite loop.

This would also unlock :overflow as well?

[Loirooriol]

I wonder if instead of a pseudo-class with some syntax restrictions, this could work with container queries? See #5989 "What container features can be queried?". Maybe whether the container is a sticky element in a stuck state?

If :overflow would mean that the element overflows its containing block, then yes, I think that limiting the effect to the descendants and requiring size containment could do the trick.

[wle8300]

How about using JavaScript Events?

myStickyElement.addEventListener('stuck', function () {
  this.classList.add('is-stuck');
});
myStickyElement.addEventListener('unstuck', function () {
  this.classList.remove('is-stuck');
});

This was discussed in #1660 (comment) back in 2017, and it's still open

[SebastianZ]

How about using JavaScript Events?

Later in that thread, @upsuper pointed out that events are working synchronously and would therefore slow down the layout. The suggestion back then was to use something asynchronous like an Observer.

Anyway, the discussion here is about a pure CSS way to handle those use cases. And the proposal @argyleink and @Loirooriol came up with sounds very promising to me so far. Also, it is orthogonal to any solution that involves JavaScript, i.e. they don't exclude each other.

Sebastian

[wle8300]

@SebastianZ I see. Thx for the simple explanation!

[LeaVerou]

Very clever idea, indeed this addresses most use cases!

However, do note that this is based on the fact that compound selectors before the subject can never target the same element as the subject. This is true today, but may not be true in the future. If we start adding pseudo-classes that avoid circularity by depending on this fact, it could severely restrict the types of new combinators we can add.

For example, there have been discussions about a preceding sibling combinator possibly being implementable (i.e. the opposite of +, let's call it <+ for the purposes of this discussion). This would re-introduce circularity, as you could do .foo:stuck + .bar <+ .foo.

Also, remember the reference combinator? Among other things, it allowed authors to target labels of elements, i.e. label /for/ input. Depending on the placement of the label, you could do input:stuck + label /for/ input to apply the pseudo-class to the input itself. It was dropped due to lack of implementor interest, but this would prevent it and anything like it from ever happening.

We may well decide that the value these pseudo-classes add outweighs the value of combinators that could go backwards. However, it should be a conscious decision to accept that tradeoff, and we should first explore variations of this proposal that don't force us into adding this restriction.

[SebastianZ]

To handle that case it could be defined that the layout depending selector excludes the element from being the subject. In other words, .foo:stuck + .bar <+ .foo or input:stuck + label /for/ input would not match the stuck elements.

Sebastian