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

It's for this reason that Less started leaning towards separation of args & params with semi-colons, and one of the major risks of bringing "function-like" constructs to CSS (which I still feel is not needed, especially [not before worklets](https://github.com/w3c/css-houdini-drafts/issues/1088) would be expanded to allow [custom functions defined in JS/WASM](https://github.com/w3c/css-houdini-drafts/issues/857)).

Once you start trying to merge the two, you find that, unlike typical programming languages, CSS has many many syntaxes to express the concept of lists. Some lists are space-separated, some are comma-separated, and for some reason, newer & revised color functions use a combination of space and slash-separated. Declaration lists are semi-colon separated, except when they aren't (such as when inter-mixed with child at-rules).

When it comes to mixins and functions, then, you run into a conceptual ambiguity. What did the user actually _mean_? Often times, a comma-separated list in CSS still represents a single conceptual "value".

For example, imagine a user writes (forgive me if this isn't the current proposed syntax):
```css
// file1.css
@function --custom-font-fn(--fonts) { result: var(--fonts); }

// file2.css
.rule {
  font-family: --custom-font-fn(Arial, sans-serif);
}
```

In this case, a developer coming along may assume 1 of 2 things: either the person writing the function definition made a mistake, or the person writing the call made a mistake. Clearly the function requires one value, and that value is clearly a list of one or more font family names... except it isn't clear. It's not intuitive, syntactically, what the output will be. Will `sans-serif` be tossed away? Or interpreted as a single value. I realize you can document the function syntax to make this clear, yet my point is that programming languages reduce ambiguity in these contexts via the list syntax itself.

Less resolved, in discussions, that the construct that was less ambiguous in CSS is semi-colon separation. In every other case, the "value" sent to a mixin / function just felt ambiguous. 

For the Less team, the clearest seemed to be: ideally, mixins / functions should have always been called with semi-colon separators between arguments. But, for backwards-compatibility, they could be used instead of commas to reduce ambiguity.

So, when semi-colons are forced, then it's clear where they "slot" in the call:
```css
  // it's much clearer this is not a "font family list value", but two clearly separated values,
  // since CSS can't assign a value with semi-colon separators to a property
  output: --custom-font-fn(Arial; sans-serif);
```

As an alternative, Less combines the concept of "escaping" with parens, so it allows a single list value like:
```css
  output: --custom-font-fn(~(Arial, sans-serif));
```

It looks like the proposal is doing something similar, but with braces? e.g. Or at least I'm inferring that from:
> --custom-fn({var(--args)})

So this?
```css
  output: --custom-font-fn({ Arial, sans-serif });
```
For me, braces around a comma-separated list seems non-CSS-y to me, since we don't see that elsewhere, but I guess either way there's some net new (unfortunately) in how CSS defines a list. It seems like either way we'll add another "list definition syntax" to CSS, which I wish wasn't the case, since there's already so many.

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


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

Received on Monday, 11 November 2024 22:01:10 UTC