Re: [csswg-drafts] Proposal: Custom CSS Functions & Mixins (#9350)

> @devingfx As an author, I would _love_ something like `@same-as`, but I suspect implementing it would be _very_ tricky, even with severe restrictions about the type of selectors that can be used there.
> 
> Even beyond implementation, there are several conceptual issues too:
> 
> * Which selectors do you pull in? Do you pull in rules from different origins or different cascade layers? If so, do they maintain these associations?
> * What about selectors that mean the same thing but with different syntax? E.g. would `@same-as .foo` pull in `[class~="foo"]`, `:is(.foo)`, `:where(.foo)`, `:not(:not(.foo))`? Or even `[class="foo"], [class^="foo "], [class*=" foo "], [class$=" foo"]`? What about subsets like `[class="foo"]` or `[class^="foo"], [class$="foo"]`? If not, you'd end up with different results than an element with an actual `foo` class, but if you do, I suspect figuring out the bounds of equivalency might be non-tractable.
> 
> Lastly, even if `@same-as` _were_ possible, it does not cover all use cases with mixins, as it does not support parameterization.

So I admittedly haven't really thoguht too deeply about it, so maybe I am actually just missing something obvious here, but is there any real benefit to parametrising mixins when they are used instead of setting custom properties on the element and using those from within the mixin?

For the vast majority of use-cases, a simple setup like

```css
button {
   border-radius: var(--button-corner-radius);
}
.button {
   --button-corner-radius: .2em;
   @same-as button;
}
```

The benefit I see to this approach is that it encourages setting custom properties on root nodes and letting them cascade, which makes me think ideally, even mixins using the proposed mechanism should still default to configuration via custom properties rather than arguments, whenever possible.

Short of using the same mixin twice with different configurations, which to me doesn't seem like something that'll happen much in practice, this mostly seems like a way of preventing these variables from cascading.


> xactly, `@sames-as` – or `@include ` in [#3714](https://github.com/w3c/csswg-drafts/issues/3714#issuecomment-1407783568) – could only really work with a special kind of selector that did not actually match anything in the (HTML) document directly.

This is true in theory, but in practice could be mitigated by prefixing selectors like `.mixin-button`; not the most elegant solution, admittedly, but it makes the problem way less severe.

As for your example, I think that is overlooking a point: If you want to make this airtight and prevent awkward prefixing, you only need to provide a selector type that *can* be used for this; you wouldn't have to prefix *every* mixin with a special selector. In your example, all the mixins already select something in the DOM, so those selectors could be re-used. At least the first two, assuming some really tight restrictions on which selectors to allow for mixins (restricting it to classes and ids sounds reasonable, although I see no reason not to just match the selector exactly).

Those are just some thoughts on this alternative proposal though, I still generally think the way it currently works is good and honestly wouldn't want bikesedding to get in the way of getting to use this feature soon. Also I believe I've seen some browser already started prototyping this anyway, so discussing massive changes at this point might just not be productive anyway. In summary: Either of these would be better than no mixins at all.

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


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

Received on Wednesday, 28 February 2024 07:09:11 UTC