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