Currently, the spec defines that a <dashed-function> is:
<dashed-function> = --*( <declaration-value>#? )
This, as written, requires you to pass a token for each argument, and absent any further processing, means that --foo() passes no args, while --foo( ) passes a single arg as a whitespace token.
(This applies to both custom function and to mixins; they reuse this same definition.)
Is this... actually what we want?
On the one hand, it seems accidental: both the "using <declaration-value> rather than <declaration-value>?" thing and the "don't trim whitespace from the start/end of the value" parts are just omissions on my part and weren't intentionally making a choice one way or another.
On the other hand, if we define that args are whitespace-trimmed and that --foo() passes no args, then I think it's impossible to pass a single empty argument. It's possible to pass two or more, like --foo(,), so that's an odd lack.
On the third hand, the spec makes it an error to pass too many arguments (too few is fine, they take their default values), so we'd have to specially handle the case of "empty parameter list, receives a single empty argument". That's probably just fine as a special case, tho.
On the fourth hand, I think this would make it impossible to ever get an untyped first parameter to take its default value. --foo() would pass an empty argument, which would be valid for an untyped arg (same as for an untyped custom property), and so would set the parameter appropriately.
On the fifth hand, is a trailing comma implying another argument, or not? If you spread a function call over several lines, one arg per line, it's common to want to allow using a comma at the end of each line. JS allows this, for example. Doing this would imply a final empty argument if we're not careful. On the other hand, var() and attr() allow a trailing comma to indicate an empty fallback, distinct from no fallback.
I think we have to bite a bullet somewhere in here; these conditions can't all be satisfied well.
I propose:
- You can pass empty arguments.
- We trim whitespace from the start/end of arguments, same as we do for properties. (And things like
var() fallbacks, tho I think that's unspecified...)
- We retain the strict "commas between arguments" rule, so a trailing comma (like
--foo(x, ) does mean you're passing an second, empty argument.
- We special-case the "single empty argument" case to instead mean "no arguments". There is no way to pass exactly one empty argument.
/cc @tursunova
Currently, the spec defines that a
<dashed-function>is:This, as written, requires you to pass a token for each argument, and absent any further processing, means that
--foo()passes no args, while--foo( )passes a single arg as a whitespace token.(This applies to both custom function and to mixins; they reuse this same definition.)
Is this... actually what we want?
On the one hand, it seems accidental: both the "using
<declaration-value>rather than<declaration-value>?" thing and the "don't trim whitespace from the start/end of the value" parts are just omissions on my part and weren't intentionally making a choice one way or another.On the other hand, if we define that args are whitespace-trimmed and that
--foo()passes no args, then I think it's impossible to pass a single empty argument. It's possible to pass two or more, like--foo(,), so that's an odd lack.On the third hand, the spec makes it an error to pass too many arguments (too few is fine, they take their default values), so we'd have to specially handle the case of "empty parameter list, receives a single empty argument". That's probably just fine as a special case, tho.
On the fourth hand, I think this would make it impossible to ever get an untyped first parameter to take its default value.
--foo()would pass an empty argument, which would be valid for an untyped arg (same as for an untyped custom property), and so would set the parameter appropriately.On the fifth hand, is a trailing comma implying another argument, or not? If you spread a function call over several lines, one arg per line, it's common to want to allow using a comma at the end of each line. JS allows this, for example. Doing this would imply a final empty argument if we're not careful. On the other hand,
var()andattr()allow a trailing comma to indicate an empty fallback, distinct from no fallback.I think we have to bite a bullet somewhere in here; these conditions can't all be satisfied well.
I propose:
var()fallbacks, tho I think that's unspecified...)--foo(x, )does mean you're passing an second, empty argument./cc @tursunova