- From: Miriam Suzanne via GitHub <sysbot+gh@w3.org>
- Date: Tue, 14 Jun 2022 20:57:22 +0000
- To: public-css-archive@w3.org
> 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