[css-functions-mixins] Handling superfluous arguments

[JaneOri]

Copying from the main thread #9350 (comment)

Two quick questions...

1. vars containing values with commas would spread across params on a call to a function, right?

--args: 1, 2, 3;
--val: --custom-fn(var(--args)); /* called with 3 arguments? */

2. If my custom function only takes 1 param, is it okay to call it and still pass in 10 values where the last 9 are ignored?

if yes on q 1, (and helped along with a 'yes' on q 2) this opens the door to arrays which means CSS libraries (with minor restrictions) can begin providing shorthand properties in their API! That's gonna be sick!

@function --at-0 (--p0) { result: var(--p0); }
@function --at-1 (--p0, --p1) { result: var(--p1); }
@function --at-2 (--p0, --p1, --p2) { result: var(--p2); }
...

.library-border {
  --size: --at-0(var(--api-shorthand));
  --style: --at-1(var(--api-shorthand));
  --color: --at-2(var(--api-shorthand));
  border: var(--size, var(--api-size, 1px))
    var(--style, var(--api-style, solid))
    var(--color, var(--api-color, black));
}

<div class="library-border" style="--api-shorthand: 2px, solid, hotpink;">
  I have a 2px solid border that's hotpink!
</div>

.

@mirisuzanne replied:

Those are interesting questions. I think it would be good to open separate issues for them at this point. I don't have an immediate answer, but would be interested in the discussions/implications.

.

@tabatkins replied

vars containing values with commas would spread across params on a call to a function, right?

Per current specs, yes. (And I think that's good.) If you want to make sure that a variable only expands into one argument, you can call the function like --custom-fn({var(--args)}).

If my custom function only takes 1 param, is it okay to call it and still pass in 10 values where the last 9 are ignored?

Yeah, we should raise this as a separate issue, as there are multiple possible answers and none of them are "obvious".

.

I LOVE the option to not expand the args using the curly braces. Awesome
The current functions spec does not appear to mention this yet
Splitting into separate args by default is an exciting possibility, I agree it's good (great!) so I really appreciate it! ty!

The 2nd question though appears to be the main discussion point for now!

Thank you!

[andruud]

@JaneOri Can we use this issue to discuss (2) specifically? ("If my custom function only takes 1 param, is it okay to call it and still pass in 10 values where the last 9 are ignored?")

If yes, we can we rename the issue to something like [css-mixins] Handling of superfluous arguments, or something else to summarize the question?

[tabatkins]

Yeah, (1) isn't an issue, just a question (and the answer is "yes"). I've renamed this issue. And as for "The current functions spec does not appear to mention this yet", it is called out in Example 3, but it's not in the grammar because it's not custom-functions specific; it's a new generic functionality defined in Values 5 for any function that takes an "arbitrary value" argument.

For (2), I don't think that I have a strong opinion either way. I think I'm lightly inclined towards making it an error, as it is in most programming languages (and in CSS for built-ins).

The use-case you mention (building arrays using custom functions) should be addressed more directly, I think. I've been sitting on an nth-item() suggestion for a long while which would do this, and actually passes the index as an argument so it's more dynamically usable.

[mirisuzanne]

I agree with Tab here:

• It seems risky to accept arguments that haven't been defined in most use-cases
• In this case, nth-item is a better solution

[JaneOri]

excellent, I appreciate the responses and appreciate your conclusions!

apologies for the my delay in responding, I hadn't checked my GH notifications in over a week - been busy with fun stuff!

[css-meeting-bot]

The CSS Working Group just discussed [css-functions-mixins] Handling superfluous arguments, and agreed to the following:

• RESOLVED: If you have a function call with too many arguments, it's invalid

The full IRC log of that discussion

<miriam> go for it
<kbabbitt> TabAtkins: question raised, what to do if more arguments passed than defined
<kbabbitt> ... is this invalid, are arguments ignored, or something else
<kbabbitt> ... some discussion back and forth in issue, conclusion we're coming to is to make variable-arity part of validity of function call
<kbabbitt> ... so invalid call if wrong number of arguments passed
<kbabbitt> ... if we want to do variable-arity functions we can do that more explicitly
<kbabbitt> ... unless anyone has a good argument for doing something else with too many arguments, we'll stick with plan in the issue
<kbabbitt> ... which is to make it an invalid function call
<kbabbitt> astearns: comments/questions?
<kizu> +1
<kbabbitt> Proposed: If you have a function call with too many arguments, it's invalid
<miriam> +1
<kbabbitt> RESOLVED: If you have a function call with too many arguments, it's invalid