[css-contain-3] How should style containment by default be handled in the syntax?

[SebastianZ]

In #7066 it was resolved that all elements are style containers by default. Though the syntax for container-type doesn't reflect that fact.

There was already some discussion in #7066 around that. This issue is meant to focus on what to do in order to make it clear to authors that specifying a container type for an element doesn't overwrite style containment.

Here are some ideas that came up earlier:

1. Make the style keyword mandatory
   That means, if a user wants to specify another type of containment like size containment, they would have to write container-type: size style;.
2. Cover that with additive cascade
   @andruud and @mirisuzanne suggested to keep the keywords as they are and instead push additive cascade. That would mean to introduce some syntax that adds another type of containment to the default style containment. Discussion around that is happening in [css-cascade] Additive CSS #1594.
3. Introduce new keywords that include style containment
   Like for the contain property, there could be new keywords introduce that cover multiple types of containment including style containment.

Anything I've forgot that got mentioned before? Any new ideas?

Sebastian

[mirisuzanne]

I'm not convinced we need to do anything more here. We already resolved that all elements are style containers no matter what value is used on container-type. That means there is no need for a container-type: style value, and no need to handle keeping it vs overriding it. I don't know of any use-cases where it would even be useful to override. As I understood it, we already solved this by not giving authors any syntax for setting or removing style containers.

We do still want additive cascade, but I think it's more useful for something like container-name, where conflicts are more likely, and the values are all custom idents out of our control.

[mirisuzanne]

Related: style queries don't require style containment.

@SebastianZ is there still something you think needs addressing here?

[SebastianZ]

I don't know of any use-cases where it would even be useful to override.

@emilio would probably say "performance reasons". But as @fantasai said on the last call, a none value could be introduced later to allow to opt out of style containment to improve the performance.
So, let's close this issue in favor of discussing a none value and/or pushing additive CSS.

Sebastian