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

> I suspect implementing it would be _very_ tricky

@LeaVerou I suppose that the algorithm of selector need to be inverted somehow to get the features (tagname, attributes, classes) to virtualy add to the element... But I'm pretty sure it can be spec'ed, isn't it?

> Do you pull in rules from different origins or different cascade layers? If so, do they maintain these associations?

I'm not sure to understand what associations issue is there, but yes rules from other origins are pulled in because `@same-as` is not aware of it: It simply adds feature to the node, whatever this features are defined elsewhere or not or not yet. The "matches" algoritm apply as if any JS script added the features to the node at the time of this `@same-as` declaration apply.

> 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"]`?

Everyone would work because the node virtualy has the class `foo` !

>  but if you do, I suspect figuring out the bounds of equivalency might be non-tractable.

Not sure what the issue here... :S

---------------------

> @LeaVerou  Lastly, even if `@same-as` _were_ possible, it does not cover all use cases with mixins, as it does not support parameterization.

> @kizu 
> The main one is that arguments don't have to be unique. If we have two mixins, where each wants to accept the same-named “variable” `--a`, it will result in a conflict, while if it is passed as an argument, there won't be a name conflict, as we define the arguments inside the mixin call.

Like what @DarkWiiPlayer said in his comment, I'm not sure the complexity of parametrisation brings to  the table that custom-vars already brings... I mean at least for the mixin part, for really complex case you still can use a more complex `@function`...
@kizu I have the intuition that if 2 mixin use the same semantic variable name (and because author would know it comes from the element and it's not special to the mixin) it's ok for it to be the same var name, like by exemple:

```CSS
.btn { background-color: var(--bg-color, var(--color, red)) }
.bordered { border: 2px solid var(--border-color, var(--color, blue)) }
.orchid { --color: darkorchid; }
#id1 {
  @same-as .orchid.btn.bordered;
}
#id2 {
  @same-as .btn.bordered;
  --bg-color: darkgreen;
  --border-color: green;
}
```

--------------------
> with a special kind of selector that did not actually match anything in the (HTML) document directly.
> 
> ```css
> $fg, .foo { color: var(--color, red); }
> $bg, .bar { background: var(--bg, red); }
> $br, [round] { border-radius: 5px; }
> ...
> ```
@Crissov it defeats reusability, this is a no go for what I imagine `@same-as` is.

----------------------
BTW, is this "light mixin" alternative worth a separate issue/discussion ?




-- 
GitHub Notification of comment by devingfx
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9350#issuecomment-1968854959 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 12:13:13 UTC