Re: [csswg-drafts] [css-contain-3] Define a syntax for state-based container queries (#6402)

The CSS Working Group just discussed `state-based container queries`, and agreed to the following:

* `RESOLVED: Defer state queries to L2`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: state-based container queries<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/6402<br>
&lt;fantasai> miriam: Resolved recently on style-based queries<br>
&lt;dgrogan> +1 to TYLin, I think this resolution effectively makes transfer size suggestion redundant<br>
&lt;fantasai> miriam: this is about being able to query some state of the container such as being in-view or being stuck (while position: sticky), etc.<br>
&lt;fantasai> miriam: There's also been some discussion of doing this through pseudo classes<br>
&lt;fantasai> miriam: but unlikely we can query the element itself and change its styles<br>
&lt;fantasai> miriam: fantasai and I were thinking to defer this to the next level<br>
&lt;TabAtkins> +1 to deferring while we figure this out<br>
&lt;TabAtkins> nope, fine with the rest<br>
&lt;fantasai> astearns: Any comments/concerns?<br>
&lt;fantasai> Rossen_: What are we losing in L1 if this wasn't well-defined?<br>
&lt;fantasai> miriam: we would be leaving this functionality out entirely. Can't query these aspects of container state<br>
&lt;fantasai> Rossen_: what type of scenarios would be broken or impossible?<br>
&lt;fantasai> miriam: I don't think this was an expected feature, so doubt anyone will miss this<br>
&lt;fantasai> miriam: but things it might add are  e.g.<br>
&lt;fantasai> miriam: header that change size when it becomes sticky<br>
&lt;fantasai> miriam: being able to make changes to its stuck state, or maybe trigger animations when it comes into view -- but work happening on that in other places<br>
&lt;fantasai> miriam: those of the main use cases we've thought through so far<br>
&lt;astearns> ack fantasai<br>
&lt;florian> fantasai: the reason I wanted to defer wasn't that we weren't sure<br>
&lt;florian> fantasai: but that a lot of these have complicated interactions<br>
&lt;florian> fantasai: in the sticky case for example, if we have a way to select when something is stuck<br>
&lt;florian> fantasai: then we can change not only that size, but the layout of the page too<br>
&lt;florian> fantasai: finding a way to prevent that isn't the way it's working right now<br>
&lt;florian> fantasai: these are important use cases to work on, but the answers are very complicated<br>
&lt;miriam> +1<br>
&lt;argyle> related https://github.com/w3c/csswg-drafts/issues/5979<br>
&lt;fantasai> s/we can change/it changes/<br>
&lt;florian> fantasai: so I don't think it makes sense to deal with them in the same level as other things that are much more solid<br>
&lt;fantasai> Rossen_: Unsure about cost-benefit tradeoff here<br>
&lt;fantasai> Rossen_: don't want to be broken by default<br>
&lt;fantasai> fantasai: This isn't undefinin anything, this is just deciding not to add a feature<br>
&lt;fantasai> fantasai: not going to break anything<br>
&lt;argyle> q+<br>
&lt;fantasai> astearns: My thought is that if we are defining all of the things that this feature would depend on without thinking about the implications of this feature, we might paint ourselves into a corner<br>
&lt;fantasai> astearns: only reason to keep in L1 is to make sure L1 is defined compatibly<br>
&lt;fantasai> astearns: but I'm not concerned about that dead-end<br>
&lt;fantasai> Rossen_: That's my concern also, so want to keep it in L1 so it nags us<br>
&lt;astearns> ack argyle<br>
&lt;fantasai> argyle: It's a nice to have<br>
&lt;fantasai> argyle: and also introduces a lot of very complex problems to solve<br>
&lt;fantasai> argyle: Shared a GH issue of how to get around the looping issue for :stuck , e.g.<br>
&lt;fantasai> argyle: it's complicated<br>
&lt;fantasai> argyle: but things folks want to do are in L1 already<br>
&lt;fantasai> argyle: there are nice queries like overscroll or whatever, that we could have, and maybe we could allude to the possibility of doing that<br>
&lt;fantasai> argyle: maybe we could do one or two, not all of them<br>
&lt;TabAtkins> I'm sorry, but I am still utterly confused by what Rossen is referring to by "breakage". This is a proposal for brand new functionality; deferring it, by definition, can't break anything. (The use-case just remains unsolved for now, but it's been in that state for years already with no progress.)<br>
&lt;fantasai> argyle: punt additional use cases and additional state queries to L2<br>
&lt;TabAtkins> no need to q+ me, that's it<br>
&lt;TabAtkins> ack<br>
&lt;TabAtkins> ack TabAtkins<br>
&lt;fantasai> argyle: I'm excited about the ideas, but ok to defer<br>
&lt;fantasai> astearns: I just want us to keep this thing in mind and not block off development<br>
&lt;fantasai> astearns: I think it's fine to defer to L2, anyone object?<br>
&lt;gtalbot> [crikets chirping sound]<br>
&lt;fantasai> RESOLVED: Defer state queries to L2<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6402#issuecomment-942498366 using your GitHub account


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

Received on Wednesday, 13 October 2021 16:50:53 UTC