[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

[yisibl]

Can the specification add examples or other instructions to further clarify the not case? (I can submit a PR)

Implementers are still susceptible to misunderstandings or misinterpretations. see: parcel-bundler/lightningcss#158 (comment)

That's not what the grammar in the spec says though. I don't see a test that implies it either. It only tests that not is not a valid container name, not that it can't start a condition.

[devongovett]

The grammar says:

@container [ <container-name> ]? <container-condition> {

... 

<container-name> = <custom-ident>
<container-condition> = not <query-in-parens>
                      | <query-in-parens> [ [ and <query-in-parens> ]* | [ or <query-in-parens> ]* ]

...

The keywords none, and, not, and or are excluded from the <custom-ident> above.

This leads me to believe that @container not (width <= 500px ) is valid, with the not being interpreted as part of the container condition rather than the name. The not <query-in-parens> case doesn't seem to require parentheses around it. I would also expect @container name not (width <= 500px) to be valid based on this grammar.

Chromium seems to disallow this and require parens around the condition. Is this a bug, or should the grammar be updated to match? Am I misinterpreting the spec somehow?

FWIW, Safari TP and Firefox dev edition seem to still treat not as the name rather than part of the condition. No browser is able to parse @container name not (width <= 500px) at all.

[mirisuzanne]

Yes, both of these are valid, with not being part of the condition rather than the name. If implementations are getting that wrong, we should at least create a WPT, and file bugs - and potentially clarify the spec.

@container not (width <= 500px ) { … }
@container name not (width <= 500px) { … }

[devongovett]

Opened a PR to add a test here: web-platform-tests/wpt#34849. There was also one incorrect test, which might have contributed to implementations getting this wrong.

[lilles]

Since the spec changed without test changes after the implementation/tests were written, the spec change went unnoticed and the previous syntax is what's currently implemented in both Chrome and Safari.

[lilles]

Should all be covered by https://wpt.live/css/css-contain/container-queries/at-container-parsing.html