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

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

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

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

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

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

@foo

[css-values-4][css-syntax-3] Define <foo()> and <@foo>, plus some lig…

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.

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

Loirooriol commented on Nov 16, 2020

SebastianZ commented on Nov 16, 2020

fantasai commented on Oct 15, 2021

tabatkins commented on Oct 16, 2021

fantasai commented on Oct 21, 2021

tabatkins commented on Oct 21, 2021

SebastianZ commented on Oct 24, 2021

css-meeting-bot commented on Nov 17, 2021

tabatkins commented on Nov 17, 2021

tabatkins commented on Oct 10, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions