Re: [csswg-drafts] [css-contain-4] Define a range syntax for style container queries (#8376)

The CSS Working Group just discussed `[css-contain-4] Define a range syntax for style container queries`, and agreed to the following:

* `RESOLVED: accept 3 part resolution in https://github.com/w3c/csswg-drafts/issues/8376#issuecomment-2751161553`

<details><summary>The full IRC log of that discussion</summary>
&lt;kbabbitt> miriam: a lot of interest in style queries where we're looking at value of custom prop on parent<br>
&lt;kbabbitt> ... a lot of interest in a range syntax there<br>
&lt;kbabbitt> ... e.g. instead of "is the value of my-custom-lenght exactly 1em"<br>
&lt;kbabbitt> .. should be able to say "is it more or less than 1em"<br>
&lt;kbabbitt> ...various use cases<br>
&lt;astearns> proposal: https://github.com/w3c/csswg-drafts/issues/8376#issuecomment-2751161553<br>
&lt;bkardell> s/my-custom-lenght/my-custom-length<br>
&lt;kbabbitt> ... anders proposed we should be able tyo solve this<br>
&lt;kbabbitt> ... my final comment linked to his proposal<br>
&lt;bkardell> s/tyo/to<br>
&lt;kbabbitt> ... adopt MQ range syntax including sandwich form<br>
&lt;kbabbitt> ... each part can be an order reference to a custom prop<br>
&lt;kbabbitt> ... equals syntax would match based on value<br>
&lt;kbabbitt> ... so 1.0 would equal 1<br>
&lt;kbabbitt> .. whereas current syntax would match serialization which is how it works already<br>
&lt;kbabbitt> ... so that would be breaking<br>
&lt;kbabbitt> ... some more detail in there<br>
&lt;kbabbitt> ... as I understand proposal, we wouldn' tneed to register custom props with any particular type<br>
&lt;TabAtkins> q+<br>
&lt;kbabbitt> ... would parse them as any of the numeric types to see if they match<br>
&lt;kbabbitt> ... if not return false<br>
&lt;kbabbitt> ... thoughts?<br>
&lt;astearns> ack TabAtkins<br>
&lt;kbabbitt> TabAtkins: support this<br>
&lt;kbabbitt> ... as described exactly<br>
&lt;kbabbitt> ... one detail of this: this technically means you could just do pure numeric comparison<br>
&lt;kbabbitt> ... don't need to mention custom prop at all<br>
&lt;kbabbitt> ... think that's fine<br>
&lt;kbabbitt> ... going back to yesterday, with if() doing comparisons<br>
&lt;kbabbitt> ... we should amend that to match<br>
&lt;kbabbitt> ... so that condition and if function work the same way<br>
&lt;kbabbitt> astearns: any other places besides style queries where we need this?<br>
&lt;kbabbitt> TabAtkins: only other similar place is MQs<br>
&lt;kbabbitt> ... those are explicit that you need a media feature on one side<br>
&lt;kbabbitt> astearns: OK<br>
&lt;kbabbitt> miriam: other nice to have here would be special casing 0 to allow comparison to length<br>
&lt;astearns> ack dbaron<br>
&lt;kbabbitt> dbaron: I like the initial proposal<br>
&lt;kbabbitt> ... haven't looked into in as much detail as others<br>
&lt;TabAtkins> don't necessarily need a zero special-case. sign() returns -1, 0, 1 i think, right?<br>
&lt;kbabbitt> ... a little nervous about what TabAtkins just said<br>
&lt;kbabbitt> ... there's a bunch of restrictions around style queries that don't apply to ? 10px<br>
&lt;kbabbitt> ... maybe restrictions do apply, was thinking they didn't<br>
&lt;kbabbitt> ... so never mind<br>
&lt;kbabbitt> TabAtkins: there's other restrictions on other conditions, but style queries are resolved on element itself, not container, should be fine<br>
&lt;emilio> q+<br>
&lt;astearns> ack emilio<br>
&lt;kbabbitt> emilio: on the 0 and lengths: do we know if we allow unitless lengths in MQs right now?<br>
&lt;kbabbitt> ... I think we might now<br>
&lt;kbabbitt> s/now/not/<br>
&lt;kbabbitt> ...not that there's a big use case<br>
&lt;kbabbitt> ... would prefer to defer it<br>
&lt;kizu> We allow: https://codepen.io/kizu/pen/ByaPWQv<br>
&lt;kbabbitt> ... because when you're parsing the terms you dont know what's going to be on the right hand side<br>
&lt;kbabbitt> ... need to work backwards<br>
&lt;kbabbitt> ... 0 > 0 comparing lengths or numbers?<br>
&lt;kbabbitt> astearns: in the interest of time, I think we should punt on unitless 0 for now<br>
&lt;kbabbitt> emilio: seems fine esp if we do in MQs<br>
&lt;kbabbitt> astearns: Proposal is to accept 3 part resolution in Anders's comment<br>
&lt;TabAtkins> https://github.com/w3c/csswg-drafts/issues/8376#issuecomment-2751161553<br>
&lt;miriam> https://github.com/w3c/csswg-drafts/issues/8376#issuecomment-2751161553<br>
&lt;kbabbitt> astearns: questions or comments?<br>
&lt;kbabbitt> lea: [asking about colon semantics]<br>
&lt;kbabbitt> astearns: that's describing what syntax has now<br>
&lt;kbabbitt> lea: does property registered or not matter?<br>
&lt;kbabbitt> miriam: registering fixes that<br>
&lt;kbabbitt> miriam: if unregistered, blue != blue<br>
&lt;kbabbitt> TabAtkins: bit about colon isn't meant to change behavior<br>
&lt;TabAtkins> (blue is equal to blue, but it's not equal to #0000ff<br>
&lt;TabAtkins> )<br>
&lt;kbabbitt> lea: do we want to allow these kinds of bare idents in there?<br>
&lt;kbabbitt> TabAtkins: we allow bare idents in MQ conditional form<br>
&lt;kbabbitt> ... so consistency<br>
&lt;kbabbitt> TabAtkins: "width &lt; 600px"<br>
&lt;kbabbitt> astearns: objections?<br>
&lt;kbabbitt> RESOLVED: accept 3 part resolution in https://github.com/w3c/csswg-drafts/issues/8376#issuecomment-2751161553<br>
</details>


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


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

Received on Wednesday, 2 April 2025 18:26:09 UTC