[css-contain-3] Define a syntax for style-based container queries

[mirisuzanne]

Container Queries should allow us to write conditional rules based on the computed styles of an ancestor container, since, according to @andruud:

Knowing the computed style (and even layout) of the container before evaluating the container query is already needed for normal (size) queries.

I'm branching this issue off from #5989 (What container features can be queried?) and #5624 (Higher level custom properties that control multiple declarations) – to specifically discuss syntax for querying a container's computed styles as part of css-contain-3.

Several of the use-cases mentioned so far (actual syntax TBD):

1. testing for a discrete value on a property, eg (background-color = red) or (--pill = on)
2. testing that a custom property has any not-guaranteed-invalid value, eg (--is-small)
3. testing range comparisons of length values, eg (50vw < 400px) or (--small > 50vw)

And some of the issues to address:

• We need to define how discrete values are compared (is it a token sequence? how is whitespace handled? etc)
• Custom properties used in range queries may need to be registered with @property
• Some values (like % lengths) evaluate differently on different properties. What do they mean in a query?

I'd like to get more use-cases and issues documented here, so that we can work through them in more detail.

[andruud]

We can't do (background-color = red) though, right? (E.g. width is both a feature and a property).

[mirisuzanne]

@andruud that's right, we have to work around features like (width = 30em), (width >= 30em), (min-width: 30em). Maybe a wrapping property() or computed() function?

[fantasai]

Agenda+ to add style queries. Proposal:

• style queries use style() function; for disambiguation, size queries use size() function
• style queries query the computed value, with the value in the query also computed wrt the query container element
• style queries cannot query ranges (for simplicity initially, and to avoid confusion since many computed values resolve to lengths but are not comparable to lengths until after the computed value stage)
• style queries can be combined using the boolean logic and syntax from @supports

Note: @mirisuzanne and I drafted this proposal into the ED at https://drafts.csswg.org/css-contain-3/#style-container in f209f6a

[andruud]

Nice.

So you opted to not have <general-enclosed> at all? Just asking since it would make e.g. size(width > 10px) or future(something) a parse error.

[mirisuzanne]

@andruud We absolutely need to think through the behavior we want here for future syntax. I think we also might want to consider defaulting queries without a function to be size queries - but that likely needs conversation in the WG.

[fantasai]

@andruud <general-enclosed> needs to parse without invalidating the entire rule, but it's not valid syntax. If you put random stuff in there, the browser shouldn't choke on it -- but neither should your syntax checker say your style sheet has no errors.

[andruud]

@fantasai My point was that as currently proposed, the browser would "choke on it". 🙂

[FremyCompany]

I am generally happy with the proposal, but was wondering:
Is attribute syntax something we could look into?

... style(width)$='%' ... {
   /* style to use if the container is percentage-sized */
}

This would allow to use custom properties that are space-separated lists of toggles, then use |= to query each token independently.

Just food for thought.

[css-meeting-bot]

The CSS Working Group just discussed [css-contain-3] Define a syntax for style-based container queries, and agreed to the following:

• RESOLVED: Accept proposal in ED. Split range syntax and attributes to new issue

The full IRC log of that discussion

<dael> Topic: [css-contain-3] Define a syntax for style-based container queries
<dael> github: https://github.com//issues/6396
<fantasai> i/Topic/astearns: Resolved, unless someone comes back with a strong opinion later
<dael> miriam: style based container queries are idea we can look at container and check computed value of a property and query that and change things for desc for value of property
<dael> miriam: Mostly used for high level custom prop where have set of values, check on parent, and based on query make changes
<dael> miriam: Other use cases, that's main
<dael> miriam: fantasai and I added proposed syntax to spec.
<dael> miriam: At this point it uses normal property syntax so : between. Some issues about supporting range syntax or attribute selector syntax
<dael> astearns: Opinions?
<dael> TabAtkins: Defining equality as something we haven't done in css. Will require some work. Wait, we have equality for transition. Ignore me. On to fantasai
<astearns> ack fantasai
<astearns> s/TabAtkins.*$//
<dael> fantasai: We talked about potentially having range. Was hesitant b/c if want to catch range of values for width you would not be able to do with style query b/c can only compare length but not auto or other keyword-based width values
<smfr> q+
<dael> fantasai: Reason I didn't want to add range syntax for computed style is b/c will add confusion. Some point in future may have use cases to add but best for now to keep to equal or not
<astearns> ack smfr
<dael> fantasai: Mostly will do lengths and use container queries for things with sizes
<dael> smfr: A bit confused. Understood container queries limited to elements with certain values on contain property.
<dael> smfr: Feature here sounds like could be independant of contain property. Features here apply whe not using?
<dael> miriam: Resolved earlier to use sytax to establish containers. Then browser establishes containement behind the scenes. This would rely on container type that doesn't apply containment in background
<dael> smfr: Makes sense
<dael> astearns: Other comments?
<dael> astearns: My understanding is we're looking for resolution to accept what's in ED and leave range syntax and attributes to future issues
<dael> miriam: wfm
<dael> astearns: fremy it was your comment about attributes. Okay to ask you to open new issue?
<dael> fremy: Isn't it same issue but delay to new level? I can open a new one if people prefer
<dael> fantasai: Yes please
<fremy> fantasai: ok, will do
<dael> astearns: Prop: Accept proposal in ED. Split range syntax and attributes to new issue
<dael> RESOLVED: Accept proposal in ED. Split range syntax and attributes to new issue