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

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?

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?

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

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.

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

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

I'd suggest not, at first.

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

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.

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?

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.

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>

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

@lilles

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

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?)

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.

Bug 1967440 [wpt PR 52666] - Support parsing of container style queri…

Bug 1968553 [wpt PR 52784] - Evaluate range container style queries i…

Evaluate range syntax in container style queries

Bug 1973070 [wpt PR 53277] - Evaluate range syntax in container style…

Bug 1973070 [wpt PR 53277] - Evaluate range syntax in container style…

Navigation Menu

Repository navigation

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

36 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

LeaVerou commented on Jan 30, 2023

SebastianZ commented on Jan 30, 2023

tabatkins commented on Jan 30, 2023

mirisuzanne commented on Jan 30, 2023

LeaVerou commented on Jan 30, 2023

SebastianZ commented on Jan 30, 2023

tabatkins commented on Jan 30, 2023

mirisuzanne commented on Jan 31, 2023

una commented on Feb 2, 2023

una commented on Feb 7, 2023

tabatkins commented on Feb 7, 2023

mirisuzanne commented on Feb 7, 2023

tabatkins commented on Feb 7, 2023

mirisuzanne commented on Feb 7, 2023

36 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions