[css-contain-4] Extend style query syntax?

[mirisuzanne]

In #6396 we accepted the current syntax for style queries using the basic (property: value) declaration syntax. That's a good start for properties with discreet values - but there are many use-cases where a more powerful syntax is required:

• For number/size values, we might want to support a range syntax?
• For more complex multi-value properties, we might consider something more like the attribute selector syntax?
• For colors, it might be useful to query their luminosity or contrast in some way?

More discussion and use-cases are in #6396, but we resolved to open a new issue for addressing these questions.

[LeaVerou]

• For number/size values, we might want to support a range syntax?

I think this is the top use case in this list, and should likely be prioritized.

• For more complex multi-value properties, we might consider something more like the attribute selector syntax?

Are there use cases for that, e.g. in component libraries?

• For colors, it might be useful to query their luminosity or contrast in some way?

I'd prefer a generic solution where we have functions for these things (e.g. for colors see #6937 , we could have a similar one for contrast too — we could even call it color-contrast() now that that name is free! 😁 ) and the syntax allows for comparison between values so we could use these functions. E.g. for your color example, that would look something like color-extract(lab.l of var(--accent-color)) > 80.

However, I’m not sure how the current syntax can co-exist with value comparison, since <ident>s can also be values. It might be good if we can resolve on that and have a clear path to future syntax before this ships and we paint ourselves into a corner.

[mirisuzanne]

• For more complex multi-value properties, we might consider something more like the attribute selector syntax?

Are there use cases for that, e.g. in component libraries?

I think this would just be syntax sugar. There are a number of use-cases like this speech bubble demo, where you might want to query multiple values (in this case the inline and block axis). Right now the demo is a bit repetitive, querying each potential combination – but that could either be simplified by using individual properties for each axis (already possible), or by allowing a more powerful query syntax.

So there are use-cases, but I think there are other solutions available - so it may not be a priority.

However, I’m not sure how the current syntax can co-exist with value comparison, since <ident>s can also be values.

So really there are two different use-cases for a range comparison syntax:

• Comparing a value against the computed value of a property (eg --my-number > 20)
• Comparing two values (eg color-extract(lab.l of var(--accent-color)) > 80)

The former seems to me like it would be compatible with the current syntax – but the latter might not be. The problem there is determining what should be parsed as a property, or as a value. But I think that second example has an additional problem, where some values (such as percentages) resolve differently on different properties? In my mind, that may need an entirely different syntax that allows for defining the property to resolve the values against. I wonder if we might want a new 'value queries' feature, in addition to ranged 'style queries'. Something like:

@container style(--my-number > 20) { ... }
@container value(color-extract(lab.l of var(--accent-color)) > 80) { ... }
@container value(16px > 50%, font-size) { ... }

It may be that allowing % isn't very useful/practical, and there's no need for the property argument – but this would still provide a clearly distinct syntax for parsing the two different use-cases.

[LeaVerou]

Actually, thinking about it, we can do this with the current syntax (provided we get ranges), by simply using a helper variable:

.container {
	--accent-color-l: color-extract(lab.l of var(--accent-color));
}

@container style(--accent-color-l > 80) {
	/* .. */
}

[mirisuzanne]

Good catch. In that case, I think we should work on defining a range syntax for properties – but I don't think we need to prioritize new syntax for the other use-cases listed, or worry that they will conflict. If we do want syntax sugar around either use-case down the road (or if other use-cases arise), it's possible to provide additional query functions to distinguish between query types.

I opened a new issue for the range syntax, and suggest we close this one.

[una]

Big +1 to having these computed values as query options. Does this also include computed range queries? I.e. if you wanted to style a weather card based on a percent chance of rain:

@container style(20 < --chance-of-rain < 50) {
	/* ... */
}