[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.