[css-contain-4] Define a range syntax for style container queries

[mirisuzanne]

The css-contain-3 spec provides a 'style container feature', allowing authors to query the computed value of a given property on the container. However, that query is currently limited to the declaration syntax, which provides a simple equality comparison:

@container style(--color-mode: dark) { … }

As discussed in #7068, there are also use-cases for range comparisons on container properties:

@container style(padding > 1em) { ... }
@container style(--primary-color-lightness > 80) { ... }

For custom properties, this might require a defined syntax using @property? Or would we want a way to define the value type on the query itself? Thoughts?

[LeaVerou]

For syntax, we can just adopt the MQ operators.

I think it makes sense to require these properties to be registered as <integer>, <number>, <length>, <percentage>, or <length-percentage> (am I forgetting anything?), we can always expand later.

Or, crazy idea here, given this is fairly limited and these types can be detected syntactically, what if we don't require registration at all? Would that be possible? Is there any ambiguity I'm missing?

[SebastianZ]

I think it makes sense to require these properties to be registered as <integer>, <number>, <length>, <percentage>, or <length-percentage> (am I forgetting anything?)

<angle>, <frequency>, <time> and their <*-percentage> counter-parts, <ratio> and maybe some more.

For syntax, we can just adopt the MQ operators.

I assume that includes the full range syntax, so one could write

@container style(1em < padding < 3em) { … }

Correct?

Sebastian

[tabatkins]

There is indeed no ambiguity when limited to comparisons of this type - there's no keywords or similar that can be interpreted differently on context, just plain numbers and dimensions.

And math functions, which is the only thing that makes me slightly concerned, just due to the potential complexity. But I suspect it's fine.

[mirisuzanne]

Another complexity: is it allowed to mention multiple properties? style(margin < 3em < padding) { … }

[LeaVerou]

Another complexity: is it allowed to mention multiple properties? style(margin < 3em < padding) { … }

I'd suggest not, at first.

[SebastianZ]

Another complexity: is it allowed to mention multiple properties? style(margin < 3em < padding) { … }

That syntax doesn't make sense to me. I'd say we should stick to the syntax defined for media queries. So that could be expressed as style(margin < 3em) and style(padding > 3em). This also makes it more readable, in my opinion.

Sebastian

[tabatkins]

Yeah, agreed that we should stick to the MQ syntax for now - either a property compared to a literal, or a property sandwiched between two literal comparisons.

[mirisuzanne]

I marked this for contain-4, but not sure if it needs to be deferred from l3? It doesn't seem like a big lift on the spec side, but may be a larger consideration for implementors?

[una]

I just mentioned this in the older thread, but this would be a very useful feature. And +1 to the MQ range syntax as a mechanism to query values by.

[una]

We would need to limit (and define the limitations) of the syntax options for range queries? I.e.

Valid:

• <length>
• <number>
• <percentage>
• <length-percentage>
• <integer>
• <angle>
• <time>
• <resolution>

Invalid:

• <image>
• <url>
• <custom-ident>
• <transform-function>
• <transform-list>
• <color>

[tabatkins]

Yes, it would be all the numeric types. Not colors, tho.

[mirisuzanne]

@lilles raised a question this morning about how to resolve <length-percentage> on custom properties - where it's not clear how percentages compare to numbers.

[tabatkins]

Percents aren't comparable to lengths in contexts where they don't resolve against a length, so they'd just be false, I suppose? That is, --foo > 50% can be true if --foo: 75%, but if --foo: 75px it'll always be false. This should be the same behavior as comparing a <length> custom property to an angle; we can't tell at parse time whether the comparison is syntactically valid, so all we can do is say it's false when we actually make the comparison.

(Do we want to try and do syntax validation on known properties? Or should we just consider them the same way, where doing a nonsensical comparison like padding-left > 50deg is false?)

[mirisuzanne]

I think it would be ok to do without parse-time syntax validation - but I would probably expect unknown rather than false in both cases.

[tabatkins]

We don't use unknown for "this doesn't make sense", we use it for "this conceivably has a true/false answer, but we happen to not know what it is; a future browser might, tho". So nonsense comparisons are simply false, not unknown.

And in a custom property, %s do not resolve against anything, so they're incomparable with any other types, just as much as lengths and angles are incomparable.

[andruud]

Are we going with the idea that registration isn't required, but the custom property side is interpreted according to the type of the literal side?

[tabatkins]

Right; registration doesn't add anything to the equation in this case. If we see --foo > 2em, we know that we're gonna be comparing the property value to a length, so we can interpret it that way immediately.

I mean, maybe registration lets you fast-path a false for nonsensical comparisons, but that's it.

Tho hm, do we ever want to allow something like --foo > --bar? In that case, registration would be useful.

[andruud]

Great, just wanted to clarify that so we know what to implement.

Tho hm, do we ever want to allow something like --foo > --bar? In that case, registration would be useful.

It could work without as well? We just try to parse a numeric thing on both sides, and check if they're compatible.

[tabatkins]

We just try to parse a numeric thing on both sides, and check if they're compatible.

Yeah true.

[mirisuzanne]

Does this logic seem like something we could add to css-contain-3, or would need to be deferred to L4?

[tabatkins]

This also seems to have implications for the non-range syntax, yeah? Like, we'd want style(--x: 1.0) to match an --x: 1;, because the two are numerically equal. But style(--x: 1.0 foo) wouldn't match --x: 1 foo;, because the value isn't a single numerical value, so we'll instead use serialization matching.

(I think this is fine, fwiw.)

[andruud]

Should we consider making : always serialization-matching, and = only "recognized-type"-matching?

EDIT: It seems risky to always interpret things as <number> (when possible), with no way for the author to actually opt out of this behavior. It would mean e.g. style(--x:0100) would match --x:10e1, which might not be what the author wants at all.

Having multiple behaviors for the same operator also feels shaky. It would be better if : always did text matching, and = never did text matching.

[mirisuzanne]

I like the consistency, and since authors have both options, they can opt into either behavior.

[andruud]

Right; registration doesn't add anything to the equation in this case.

...

We just try to parse a numeric thing on both sides, and check if they're compatible.

...

consider making : always serialization-matching, and = only "recognized-type"-matching?

---

This has marinated for ~two years: can we make progress here now?

Proposal:

• We adopt MQ's syntax, including the sandwich form (e.g. a < b < c).
• Every part can be a literal, or a reference to a custom property.
• = matches by value (a number 1.0 is equal to a number 1), whereas : matches by serialization (a value 1.0 is not equal to a value 1).

For e.g. style(A > B):

• If A/B is a custom property reference, substitute with the value of the custom property.
• (EDIT:) Substitute arb-subs within A/B.
• Parse each side according to <number> | <percentage> | <length> | <angle> | <time> | <frequency> | <resolution>.
• If both sides have the same type, compute each side, do the comparison, and return the result.
• Otherwise, return false.

Note that this allows style(--foo < --bar), but also style(10px < 10em) which we could disallow if we think it doesn't fit here.

Note also that you can't compare a <length> to a unitless zero in in this approach, e.g. style(--length > 0) does not work: it needs to be style(--length > 0px). We could special-case this if we wanted, by considering zero implicitly compatible with other numeric types for comparison purposes.

[kizu]

but also style(10px < 10em) which we could disallow if we think it doesn't fit here.

I don't think there is any reason to disallow this, as this can be a quite common use. Probably not on its own (although, you could want to check the value of 1em), but when used with mixed custom properties.

Note also that you can't compare a <length> to a unitless zero in in this approach, e.g. style(--length > 0) does not work: it needs to be style(--length > 0px). We could special-case this if we wanted, by considering zero implicitly compatible with other numeric types for comparison purposes.

Hmm, as an author, I would expect the 0 = 0px to be true, in the same way 1.0 will be equal to 1, as long as we know the type. Like when we have a style query with a registered <length> custom property, a 0 and 0px comparison will be always true: https://codepen.io/kizu/pen/ByaPWQv, so I'd vote for special-casing 0 to be more flexible.

[mirisuzanne]

I like the proposal, and would love for it to move forward.

style(10px < 10em)

There would be other versions of this that are less useful (px vs inch?) - but this seems like it would have solid use cases, since em are resolved against the container font size.

I'd vote for special-casing 0 to be more flexible.

Me too

[andruud]

Hmm, as an author, I would expect the 0 = 0px to be true, in the same way 1.0 will be equal to 1, as long as we know the type. Like when we have a style query with a registered <length> custom property, a 0 and 0px comparison will be always true: https://codepen.io/kizu/pen/ByaPWQv

Sure, OK. Note, however, that this is more like <number> | <length>:

@property --x {
  syntax: "<number> | <length>";
  initial-value: 0px;
  inherits: false;
}
#child {
  color: red;
  @container style(--x: 0) { /* false */
    color: green;
  } 
}

But we can certainly still make 0 = 0px work.

[andruud]

but also style(10px < 10em) which we could disallow if we think it doesn't fit here.

I don't think there is any reason to disallow this, as this can be a quite common use. Probably not on its own (although, you could want to check the value of 1em), but when used with mixed custom properties.

Given #11104, is it dumb that both if((10px < 1em):value) and if(style(10px < 1em):value) are allowed?

[mirisuzanne]

Given #11104, is it dumb that both if((10px < 1em):value) and if(style(10px < 1em):value) are allowed?

@andruud Are both resolving relative lengths on the same element? I don't know if it's a good or bad idea, but I'm curious if they mean the same thing?

[andruud]

Yes, as far as I understand, they mean the same thing.

[mirisuzanne]

For discussion sake, the proposal is here: #8376 (comment) - follow-up comments provide some additional details and clarifications.

[tabatkins]

If we're accepting style(10px < 1em), then we can edit the resolution in #11104 to just use style() for that use-case.

[css-meeting-bot]

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

The full IRC log of that discussion

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