- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Jul 2024 16:03:35 +0000
- To: public-css-archive@w3.org
@Crissov why is this goal, especially when the end result is not meeting a good chunk of user and author needs? Remember that [theoretical purity is at the bottom of the PoC](https://www.w3.org/TR/design-principles/#priority-of-constituencies).
----
@andruud There is certainly overlap, though preprocessors have historically supported cosntructs for both, and authors have used both so it seems they do serve distinct user needs. That said, if we can do mixins via a similar mechanism and reduce the number of primitives authors need to learn, even better. It would be good to enumerate the conceptual differences in terms of user needs to see if some of the different reuse mechanisms we are discussing could be merged.
A first stab:
- Conceptually, mixins don’t necessarily match anything and don’t really stand alone, they only get meaning when included. Though in theory, that could be represented by a new selector type (e.g. placeholder selectors) + `@like` + a way to set custom property values on that included rule (since it doesn’t match anything, so there are no existing values).
- `@like` is designed to pull in base styles defined independently by the page and is quite limited in terms of pulling in descendant rules, whereas mixins can have descendant rules of any amount of complexity. Though the ergonomics of `@like` are not actually harmed by relaxing this, this restriction primarily exists to make it easier to implement.
- Higher level custom properties are also similar to mixins, but cascade normally and only provide a single argument (though future extensions to `@property` could allow more elaborate parsing)
- Functions are related, but IMO have a distinct purpose, to reuse complex expressions.
As a terrible handwavy strawman just to get the conversation going, what if `@like` could have two forms:
1. `@like <meta-selector>` (as described above)
2. `@like <meta-selector> { <custom-property-declarations> }`
The declarations in 2 would be used to set any base values for custom properties that don’t have one. Since placeholder selectors match no element, their custom properties have no values anyway, so effectively this sets them. Some prose wrangling would be needed to make sure this also sets registered custom properties, instead of having them default to their initial value.
Note this doesn’t cover registering scoped parameters. But perhaps that’s a problem that needs to be solved at the `@property` level anyway.
Even if we decide we want to pursue mixins as a separate path later on, something like `@like` could alleviate the immediate need for many types of mixins, buying us more time to figure out the design of mixins and how they fit in to the rest of the language.
--
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10222#issuecomment-2203683210 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 2 July 2024 16:03:36 UTC