- From: Matthew Dean via GitHub <sysbot+gh@w3.org>
- Date: Tue, 09 Apr 2024 23:18:08 +0000
- To: public-css-archive@w3.org
@LeaVerou > Actually, come to think of it, do we even need a dedicated descriptor? What if the result was held by a custom property, and which one was part of the function definition... That's essentially what Less does, and as such, doesn't need a separate `@function` with a whole separate `@returns` at-rule at the end instead of `@mixin`. Functions are, after all, mixins where you're "selecting" a return value. So, with your example: ```css @function --hypot(--a, --b) returns var(--result) { --result: calc(sqrt(pow(var(--a), 2) + pow(var(--b), 2))); } ``` And presuming a use like: ```css .foo { // Not sure what the proposed syntax is here value: --hypot(1, 2); } ``` The Less equivalent is: ```less .hypot(@a, @b) { --result: calc(sqrt(pow(@a, 2) + pow(@b, 2))); } .foo { value: .hypot(1, 2)[--result]; } ``` In other words, in Less, you just select the property value you want returned by the mixin. Currently, that's by name, but in the future, might be done by (positive or negative) indexed position. While I was initially skeptical of mixins in native CSS (and, by extension, functions), I think the killer feature about this is the ability to define and `@apply` rules (and, hopefully, nested rules) to classes to avoid the necessity of a Tailwind-like system to list dozens of classes in HTML. (Not saying Tailwind isn't useful for some people, just that it could be more general-purpose and applicable natively in CSS.) Having classes "inherit" (or "extend" as the equivalent in Less/Sass) other classes (or, in this case, mixins) would be a huge win. The one thing I would say is my personal preference that `$foo` is not used for variable declaration, now that it's used in both Less and Sass (and others) for variable access / definition. I know pre-processors always run this risk of future syntax clashes with CSS, but I feel like it's reasonable in CSS to prepend variable / mixins declarations with at-rules. I really feel like @mirisuzanne kinda nailed the syntax the first time, although I would make one tweak: ```css @mixin gradient-text( --from: mediumvioletred; --to: teal; --angle: to bottom right; ) { color: var(--from, var(--to)); @supports (background-clip: text) or (-webkit-background-clip: text) { --gradient: linear-gradient(var(--angle), var(--from), var(--to)); background: var(--gradient, var(--from)); color: transparent; -webkit-background-clip: text; background-clip: text; } } h1 { @apply gradient-text(pink, powderblue); } ``` As there is the preceding `@mixin` and `@apply`, there isn't any reason to cloud the semantics of single property names / values with mixin names / values. As in, like named grid lines / columns, the names would never clash with any future CSS syntax (the names are user-defined by definition), so I feel the `--` is just unnecessary noise for the mixin (/ function) name itself. -- GitHub Notification of comment by matthew-dean Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9350#issuecomment-2046187284 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 9 April 2024 23:18:09 UTC