[css-contain] <container-name> in @container ambiguities

[emilio]

Two thoughts:

• <container-name> kinda conflicts with <container-condition>, as not can be a valid <container-name>, how should @container not (width > 300px) be parsed? There's an obvious answer, but probably that means that not should not be a valid <container-name>?

• Per spec <container-name> includes none and multiple <custom-idents>, is @container foo bar (width > 300px) expected to be valid? I don't see any test for multiple container names in the rule, so just checking whether that's intentional or not.

cc @andruud @mirisuzanne @anttijk

[mirisuzanne]

• I agree, we should disallow not as a <container-name>
• I don't think we want none in the @container <name> syntax, so should probably clarify that production either way. I would lean towards allowing multiple names in a query, and defining them to act as a combined filter, so that a container for your query would have to match both foo AND bar names. It's more important that we allow multiple names on a container itself (the property), but given that containers may have multiple names, it seems useful that you could be more explicit about combinations of names that need to be present for a query.

[css-meeting-bot]

The CSS Working Group just discussed [css-contain] <container-name> in @container ambiguities, and agreed to the following:

• RESOLVED: disallow 'not' as a container name
• RESOLVED: 'none', 'not', 'and', and 'or' would be disallowed. Only a single name allowed in @container rule

The full IRC log of that discussion

<dael> Topic: [css-contain] <container-name> in @container ambiguities
<dael> github: https://github.com//issues/7203
<dael> miriam: The way we have container-name at the start of an @container rule can be confused currently with keyword not
<fantasai> +1 to disallowing not
<TabAtkins> +1 to disallow "not"
<dael> miriam: @container might start with either container-name or not. First part is to disallow 'not' as a container name
<jensimmons> +1 seems obvious to me
<dael> Rossen_: I see support
<dael> Rossen_: Should be straightforward. Other opinions? Or objections?
<dael> RESOLVED: disallow 'not' as a container name
<dael> miriam: Next part is a question. not clear if you can query multiple names in an @container rule and what happens if you did. and or or condition?
<dael> miriam: Container can have multiple names. You can say if you use multiple names you need both or all. Or say this or that. Or disallow multiple names
<dael> miriam: Sort of use cases of any of the above. And all can be handled by other naming conventions. no clear reason to go one way or another
<dael> miriam: Most obvious to me if we allow multiple names is they're allr equired
<Rossen_> ack fantasai
<dael> fantasai: I think ligit use cases for AND and OR so logical thing to do is apply bool syntax here. Might not want to do that b/c that's adding a lot. I suggest only 1 container name, disallow not, and, and or. Consider in the future if we want a more powerful syntax
<dael> Rossen_: Reserve the bool names for now, only allow 1 container name, and that gives us future extensibility for bool and multi naming
<dael> miriam: Makes sense to me
<dael> fantasai: miriam you mentioned about disallowing none?
<dael> miriam: So none can't be the name of a container. none as a container name just removes container names. I don't think need to explicitly disallow, but could clarify that
<dael> fantasai: Makes a difference as to if rule is invalidated. I lean toward invalidating it
<dael> miriam: 'none', 'not', 'and', and 'or' would be disallowed. Only a single name allowed in @container rule
<dael> Rossen_: Sounds like a good summary. Opinions or objections?
<dael> RESOLVED: 'none', 'not', 'and', and 'or' would be disallowed. Only a single name allowed in @container rule