[css-conditional-5] Add `container()` as a leaf of the @when rule

[bramus]

It would be nice to also see a container() function as a leaf of the @when rule, in addition to the already specced media() and supports() functions.

The syntax would preferably be the same as the @​container rule:

container() = container( [ <container-name> | [ name(<container-name>) || type(<container-type>+) ] ]? <container-query> )

(Perhaps the optional part should not be optional here, for performance reasons? 🤔)

Use case: it would allow stuff such as easy dark mode toggling based on the value of a custom property on a style container:

@when media(prefers-color-scheme: dark) or container(root style(--color-scheme = dark)) {
  body {
    --primary-color: #efefef;
    --primary-bg-color: #333;
  }
}

[andruud]

This requires that @when has @container-style handling of inner (name-defining) at-rules. In other words, inner at-rules would apply regardless of the condition.

[tabatkins]

Yeah, @container just plain works differently from all the other conditional rules. I don't think it can be usefully merged in, unfortunately.

[mirisuzanne]

I think conceptually the @when rule is syntax sugar for things we can already do. It's already possible to combine media, supports, and container queries by nesting. It seems to me that the behavior here would only have to match the existing behavior of those rules when combined?

This would also make #6917 possible without any special container syntax. That seems to me like exactly the underlying problem that @when is designed to solve - nesting can be clunky, and OR combinations are repetitive. I would very much like to make this work if we can.

[andruud]

It doesn't seem impossible provided we have a workable solution for inner at-rules. Using @layer as an example:

@media(a) { @layer x; } -> affects layer order only when a is true.
@container(b) { @layer x; } -> affects layer order regardless of b.
@when media(a) or container(b) { @layer x; } -> ???

[tabatkins]

Right, I don't think that's a solveable problem. I'm strongly against the layer interpretation changing based on precisely what queries you use in a @when rule; that means something that should be a no-op (adding an or false-query() branch) might have knock-on effects.

Further, it's not just combining the known media/supports/container queries, but combining any query in the future, too - we can't predict what unknown-new-query(foo) will do to the semantics of layers and similar things, so we'll have to define a behavior and that has a chance of locking the behavior in when the query is widely supported. Right now we only have to deal with the truth value of an unknown query, which is much safer and more limited. (Tho even then we have to decide whether to use the 3-value boolean logic, like MQs, or 2-value, like SQs. Luckily, defaulting to 3-value at the top level is fine.)