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()>?

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

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.

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>.

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

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( ... )

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

Sebastian

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

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

Added definitions of <foo()> and <@foo> to the appropriate specs. Since you approved the plan before the CSSWG resolution, I'm assuming satisfied; lmk if there are any issues otherwise.