- From: Tab Atkins Jr. <notifications@github.com>
- Date: Fri, 10 Feb 2017 11:06:19 -0800
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/300/279036110@github.com>
> Echoing @morewry, wouldn't want to lose mixins. They're very powerful for doing what authors have been doing with preprocessor mixins for years (mixing in a bag of styles in many places), and don't see why they couldn't work hand in hand with parts should the need arise. `@apply` really isn't very good at this, tho - it's roughly equivalent in power to a zero-arg `@mixin` from Sass (with the added benefit that you can set different values in different subtrees). Zero-arg mixins are *convenient*, but all the *real* useful mixins, in my experience, use arguments; you can only do pretty simple things with zero args. `@apply` can't realistically be expanded into becoming an arg-full mixin syntax, either; at least not conveniently/readably. (If/when we invent "late-binding var()" you can get something approaching it, but it's not very convenient.) Partial solutions, tho, have a tendency to suck the air out of the room for "real" solutions, unless you have an evolutionary path to the "full" solution. There isn't one for `@apply` to become a full mixin solution, tho; we'll just have to invent something new, and the existence of `@apply` already partially solving the problem will make creating a new thing much less attractive. I'd rather just invent the full thing; getting it together will already be a huge fight. ^_^ -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/300#issuecomment-279036110
Received on Friday, 10 February 2017 19:06:57 UTC