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

The containment requirement seems promising: [containment spec quote](https://drafts.csswg.org/css-contain-2/#ref-for-natural-height:~:text=%20can%20do%20so%20without%20fear,the%20containment%20box's%20size%2C%20ad%20infinitum)

> 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](https://github.com/w3c/csswg-drafts/issues/5979#issuecomment-777797452), 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? 

-- 
GitHub Notification of comment by argyleink
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5979#issuecomment-783650319 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 22 February 2021 20:22:50 UTC