Re: [csswg-drafts] [css-contain-4] Extend style query syntax? (#7068)

> > * 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](https://codepen.io/miriamsuzanne/pen/vYjMjGd?editors=1100) 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:

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

-- 
GitHub Notification of comment by mirisuzanne
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7068#issuecomment-1409091878 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 30 January 2023 18:13:17 UTC