[css-contain-3] Move style() to the feature level in the grammar

[andruud]

I just wanted to check if we still want to keep style() at its current level in the grammar now that size() is removed. It is not consistent with previous choices (@supports / selector()), which places the function at or near the "leaf nodes". We should probably do the same for this case, i.e. style( <style-feature> ).

[mirisuzanne]

I think the feature is usable either way, if we decide to go that rout - but I do think there is a pretty good expectation that people will want to string together multiple style selectors, and I like that this allows it to happen inside a single function.

[mirisuzanne]

To clarify the difference here, the two options look like…

A feature-level syntax might be a bit simpler from the spec/implementation side:

@container card-component (style(--card: feature) and style(--mode: dark)) or style(background: maroon) { … }

But the current higher-level syntax provides a bit more sugar for authors, since the function is only required once, and can contain multiple style() conditions:

@container card-component style(((--card: feature) and (--mode: dark)) or (background: maroon)) { … }

My thoughts:

• My preference is for the higher-level syntax sugar, but it's not a big difference, and there's no functionality at stake
• This decision would likely apply to any new non-size features added in the future (eg 'state queries')

[andruud]

High-level syntax sugar is totally fine, but since it looks like a deviation from the pattern established by @supports/selector(), just making sure it's a deliberate choice, and that it still makes sense now that size() is gone. 🙂

[css-meeting-bot]

The CSS Working Group just discussed [css-contain-3] Move style() to the feature level in the grammar, and agreed to the following:

• RESOLVED: Keep the current behavior

The full IRC log of that discussion

<dael> Topic: [css-contain-3] Move style() to the feature level in the grammar
<dael> github: https://github.com//issues/7073
<dael> miriam: When we defined both size and style functions for the @container rule we made them so they could wrap larger chunks of syntax so can have multiple style queries in style
<dael> miriam: Seemed useful as syntax sugar. Since then removed size and left only with style and possibility of future functions
<dael> miriam: What we're looking at is do we still want style and any future functions to have that sugar of allowing multiple queries or statements inside the function? Or restrict to each function is a query?
<dael> miriam: Provided 2 examples, don't look terribly different. Lean slightly toward keeping flexibility but very slight. Anders argued to remove it
<Rossen_> ack fantasai
<dael> fantasai: My thought is that it's annoying to type something over and over again. If you have a complex style query it would be annoying to type style again and again. Syntax has built in logic to handle multiple. I think for author friendliness it's better to allow
<fantasai> s/Syntax has/Selectors has/
<dael> Rossen_: If Anders is not here; anyone in favor of dropping?
<fantasai> s/multiple/multiple boolenan logic/
<dael> miriam: I haven't heard from anyone else in that direction
<dael> Rossen_: I'm fine with taking a resolution and revisiting in case Anders has a strong position and reason. From listening to WG seems we're leaning more to keep it
<dael> Rossen_: Other opinions?
<dael> Rossen_: Objections to keep the current behavior?
<dael> RESOLVED: Keep the current syntax

[mirisuzanne]

@andruud if you want to push on this more, feel free to reopen and put back on the agenda for some time you can make your case to the group?

[andruud]

Nope, it's fine. 🙂