[css-values-4] Clarify that function component values need to be followed by parentheses

[SebastianZ]

In https://drafts.csswg.org/css-values-4/#component-types the different component value types are defined.

And Function definitions are mostly specified separetely from where they are used, so they are referenced by non-terminal values like <image()> in https://drafts.csswg.org/css-images-4/#image-values.

So far, there is no note in the specification how the names of those values should look like. This causes some confusion like in w3c/fxtf-drafts#410.

In order to clarify that and make it consistent across specifications, I suggest to formalize that the names of those values need to be followed by an opening and a closing parenthesis.

Sebastian

[Loirooriol]

So for example in https://drafts.csswg.org/css-grid/#repeat-syntax, you would rename <track-repeat>, <auto-repeat>, <fixed-repeat>, <name-repeat> to <track-repeat()>, <auto-repeat()>, <fixed-repeat()>, <name-repeat()>?

What if you have a disjunction of different function values, like in <transform-function>? Should it be <transform-function()>?

[SebastianZ]

Yes, or do it the other way round and don't allow parentheses within those names. The point here is to have a clear definition for how they should look like to get consistency.

Sebastian

[fantasai]

I think Images 4 is the one that's wrong here, we've traditionally not used parentheses in value types (see, e.g., <url>, which is the oldest functional notation). If there's other specs with this problem, let's tag them here and fix them.

[tabatkins]

Parens in non-terminals are just a way to implicitly refer to the grammar of the given function, like <'color'> refers to the 'color' property. It's not meant to be a general policy one way or the other.

Things like <url> aren't referring to the url() function, they're referring to anything that represents a URL, which can also be a <string>.

[fantasai]

@tabatkins That is totally not true. <url> never represents a <string>.

[tabatkins]

So fantasai and I discussed this a bit, and I realized I'd forgotten that this <foo()> grammar non-terminal was actually just something I added to Bikeshed as a linking convenience (and have been using for several years), not something we ever actually added to the Value Definition Grammar.

Like I said in my previous comment, the point of it is to serve the same purpose as <'width'> - a shorthand way to say "this non-terminal represents the grammar of the 'width' property, minus the CSS-wide keywords" - where <foo()> is a way to say "this non-terminal represents the grammar of the foo() function". Otherwise you have to explicitly provide a <dfn type>&lt;foo-function></dfn> element in the grammar block as well as the <dfn function>foo()</dfn>; with this shorthand you can just supply the <dfn function> variant (perhaps inside the grammar block, perhaps outside) and it Just Works.

It also serves as an automatic namespacing mechanism - rather than defensively naming function grammars as <foo-function> to avoid collisions, or just YOLOing it as <foo> and ensuring we never add an unrelated non-terminal of that name, we automatically get a reasonably non-colliding name. (See <image> vs <image()>, for example.)

So, all the examples Oriol provides are invalid - none of those are the definition of the named functional notation. The non-terminals used there are indeed standard non-terminals, and should continue to be written as such.

We should, however, add this syntax to the Value Definition Grammar if we're going to keep using it. (Also for at-rules as <<@rule>>, which Bikeshed also allows.) And I should update the bits of my specs where I wrote grammars like foo() = foo( bar | baz ) to instead be <foo()> = foo( bar | baz ).

Agenda+ to ask if we want to add this convention, or just keep to only ident-based non-terminals.

Examples:

    <image> = <url> | <linear-gradient()> | ...
    <linear-gradient()> = linear-gradient( ... )

    <repeat()> = <track-repeat> | <fixed-repeat> | <auto-repeat> | <line-repeat>
    <line-repeat> = repeat( ... )

[SebastianZ]

Tab's explanation and suggestion sound totally logical to me. So 👍🏻 for that from my side.

Sebastian

[css-meeting-bot]

The CSS Working Group just discussed [css-values-4] Clarify that function component values need to be followed by parentheses, and agreed to the following:

• RESOLVED: Add this to the Value Definition Grammar

The full IRC log of that discussion

<fantasai> Topic: [css-values-4] Clarify that function component values need to be followed by parentheses
<fantasai> github: https://github.com//issues/5728
<emilio> fantasai: So tab added bikeshed functionality in which he can link to a function definition using `<ident()>`
<emilio> fantasai: but this is not actually valid according to our value definition grammar
<fantasai> <'property-name'>
<fantasai> <keyword>
<emilio> ... that has quoted property references and terminal kws (^)
<emilio> ... so should we add this to the value-definition grammar and update all specs to use this convention?
<emilio> ... a subtle thing is that only terminals that represent a function will use this
<emilio> ... historically we haven't done this, e.g., `<url>`
<emilio> ... so the question is do we want to extend our syntax in this way
<fantasai> chris_: I would find this useful, have needed <foo> vs <foo()>
<fantasai> astearns: So proposal is to add <name()> to our grammar
<fantasai> s/grammar/grammar for specs/
<fantasai> astearns: Will that require going back and fixing everything?
<fantasai> fantasai: I think it would be useful to make things consistent
<fantasai> fantasai: but I wouldn't do it for <url>
<fantasai> astearns: If not required, it's better; would prefer not to mess with old things
<fantasai> astearns: Any other opinions?
<fantasai> RESOLVED: Add this to the Value Definition Grammar

[tabatkins]

Note that switching all our <url> references to <url()> would be absolutely wrong, since src() is another <url> value.