[css-mixins] `<dashed-function>` syntax seems invalid about csswg-drafts

[cdoublev]

Somewhat related... Sometimes specs:

• disallow whitespace between component values, like '<', <type-name>, and '>'
• require whitespace, like between two <complex-selector-unit>s if the <combinator> between them is omitted

But it is not explicitly required after using in using ( <dependency-list> ). Obviously there would be a function if the whitespace was omitted, so this may not be worth clarifying. (Please tell me if I should open a separate issue.)

An omitted whitespace between two symbols, eg. <foo><bar>, does not mean that a whitespace in the input is disallowed. My point is that if whitespaces were defined to be disallowed between an expression defining a function's name and (, a syntax like <function-name>(<declaration-value>#) for <dashed-function> would be unambiguous.

Fwiw, I think this would be confusing and error-prone. A simpler solution is to rewrite with using <dependency-block>.

Also note that disallowing a whitespace before a multiplier or '>', or after '<', sets a precedent whereas <foo> +, while a bit confusing, is unambiguous to parse since multipliers are not allowed to appear unquoted in a value definition.

In my humble experience, spec authors often omit whitespace in various cases:

• a| b
• <a><b>
• [a b ]
• fn( a b)

They can all be parsed fine. I expect CSS authors to also omit whitespaces. This may be relaxed later, but perhaps they would appreciate some forgiving syntax. I think functions are the only ambiguous case.

[tabatkins]

Re: your whitespace comment, there's a bit more, too. Here's the syntax, currently:

&lt;@function> = @function <<function-name>> [ ( <<parameter-list>> ) ]?
	[ using ( <<dependency-list>> ) ]?
	[ returns <<type>> ]?
{
	<<declaration-rule-list>>
}

In addition to the using detail (using () is allowed, using() is illegal), the main parameters are also separate and optional, so @function --foo () is allowed, but @function --foo() is illegal.

This seems odd; in JS, function foo() {...} is, I think, the most common syntactic form (even tho function foo () {...} is allowed in JS, too). I think we should probably at minimum switch to that; possibly we can allow both forms, if useful. This is a novel syntactic form, so even tho it's kinda unprecedented, that might still be acceptable.

@andruud , did you intend to write both of these locations with that whitespace, or was it unintended?