Re: [csswg-drafts] [css-contain-3] Revisit decision to make `style` the default `container-type` (#7066)

> How about simply making inline-size and size also be style containers (they already imply style containment)?

This seems like a one-off solution that would protect only the `style` container-type from overrides. The concern that @fantasai has raised is that we may want a more generic solution for any number of future container types that may overlap and conflict in different ways. I get that concern.

But I also agree with @andruud's assertion that _these problems already exist many other places in CSS_. To that point,  `container-name` should also ideally be 'additive' – allowing authors to establish different names in different places and for different reasons, without those names overriding each other. That problem is not easily solved by breaking out more longhands. A container can have multiple size names, just as likely as it has names relating to different container types. I don't think it makes sense to have style-names and size-names and state-names, etc. So it makes sense to me that a 'generic' solution should be _even more generic_ (we need additive cascade), rather than looking for a solution that is generic only to container-types. 

But generic additive cascade is not an easy problem to solve. So, short-term, do the longhands help us get there?

## the longhand approach

Say browsers launch with two longhand properties, and plans for a third (if not more):

```css
/* launching soon… */
size-container: [none | size | inline-size];
container-name: [none | <custom-ident>+];

/* someday later… */
style-container: [none | style];
```

If we stop there, it works. When `style-container` lands, authors can add it as desired, without causing any `size-container` conflicts. But as soon as we add a shorthand, we're back where we started – a single property that overrides future properties:

```
/* launching soon… */
container: <container-name> / <size-container>?;

/* someday later… */
container: <container-name> / <size-container>? <style-container>?;
```

In the immediate, authors will set `container: name / inline-size`, seeing it as a helpful shortcut. But as soon as we add style containers, that new longhand is already in conflict with any use of the existing shorthand. Authors are overriding a value that didn't even exist when they initially wrote the code.

Maybe that's what @fantasai had in mind – longhands, without any shorthand? I think it works, and sidesteps @lilles concerns about merging multiple shorthands. This seems like a viable path to me (tho I still want additive cascade for container-names).

## on the utility of 'style queries' generally

Along the way, several people have questioned if 'style queries' are even useful, especially if we have individual inline functions like `toggle()`/`cycle()` or even `if()`. I'm working on a larger summary of the use-cases here, and will post that soon. But the quick summary is, functions like `toggle()` only work when:

1. you want to set a _single property_
2. based on the parent value of _only that same property_

That works (and is even elegant) if you want to simply cycle a `font-style` between `normal` and `italic`, based on the parent `font-style`. But it falls apart as soon as you get any more complex about the relationships:

1. adding multiple conditions
2. styling a different property than you query
3. styling multiple properties based on a shared condition 

All of those become more essential for use-cases discussed in #5624, but are even required for this simple case (based on a demo from @una elsewhere):

```css
@container style(font-style: italic) {
  em, i, q {
    background: lightpink;
  }
}
```

-- 
GitHub Notification of comment by mirisuzanne
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7066#issuecomment-1155705859 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 14 June 2022 20:57:23 UTC