[css-values-5] Express which keywords are valid in calculations in syntax definitions

[romainmenke]

Some examples:

color: rgb(from purple r g calc( b / 2 ));
height: calc-size(auto, calc(size / 2));

Currently there is no way to express in syntax definitions which keywords are valid in which context.
This can only be done in prose.

This would be useful for static analysis tools (i.e. linters)

With the addition of the boolean expression multiplier there is bit of a precedent to define and communicate such things.

Could we use this or something similar for math expressions?

<modern-rgb-syntax> = rgb( [ from <color> ]?
        [ <number> | <percentage> | <math-function[ r | g | b ]> | none]{3}
        [ / [<alpha-value> | <math-function[ alpha ]> | none] ]?  )

Where <math-function[ foo ]> is equivalant to calc( <calc-sum[ foo ]> ) | min( <calc-sum[ foo ]> ) | ...

<calc-size()> = calc-size( <calc-size-basis>, <calc-sum[ size ]> )

[cdoublev]

In my opinion, the boolean expression multiplier should not be used like this, and is not even the best solution for expressing boolean conditions.

The common point between boolean conditions, color component keywords, intrinsic size keywords, the nesting selector, is a context-sensitive production. <test> expands to a set of values that is entirely defined by the context, while <calc-keyword>, <type-selector>, <subclass-selector>, expand to a set of values that may be extended by the context.

Basically, the boolean expression multiplier avoids repeating a bunch of productions with the same structure but different values.

Besides, if you define <math-function> as an alternative to numeric types in color functions, it would be unclear if these numeric types can be replaced in other productions, unless you explicitly add <math-function> as an alternative, which seems unrealistic ^^

I mentioned different solutions to express context-sensitive productions before. Here is another one using "type attributes":

<rgb() calc-keyword="<calc-keyword> | r | g | b">
<calc-size() calc-keyword="<calc-keyword> | min-content | max-content">
<boolean-exp test="<cq-test>">

[cdoublev]

I do not know if you intentionally left out infering which color component keywords are valid outside calculations.

The relative color syntax is partially encoded in color function definitions: it includes [from <color>]?, but not the corresponding component keywords, which seems unfortunate.

A fully encoded example for rgb() could be:

rgb() = <legacy-rgb-syntax> | <modern-rgb-syntax> | <relative-rgb-syntax>

<legacy-rgb-syntax> = rgb([ [ <percentage>#{3} | <number>#{3} ] , <alpha-value>? ])
<modern-rgb-syntax> = rgb([ <rgb-component>{3} [ / [ <alpha-value> | none ] ]? ])
<relative-rgb-syntax> = rgb([
  from <color>
  [ <rgb-component> | <rgb-component-keyword> ]{3}
  [ / [ <alpha-value> | none | <rgb-component-keyword> ] ]?
])
<rgb-component> = <number> | <percentage> | none
<rgb-component-keyword> = r | g | b | alpha

This is more consequential, but perhaps useful for readers.

This does not address the issue in calculations though, whereas a prose defining that any numeric value in a color function can be replaced with a corresponding component keyword, addresses both concerns, which is more straightforward.

I do not know if the authors of CSS Colors 5 already considered this.

[romainmenke]

I am not sure if context specific productions can be used here as the channel keywords aren't valid everywhere in a relative color function.

This is invalid: rgb(from hsl(calc(r) 0 0) 0 0 0)

calc(r) is only valid in the channel positions for rgb(), not in the hsl() color in this example.

---

This does not address the issue in calculations though, whereas a prose defining that any numeric value in a color function can be replaced with a corresponding component keyword, addresses both concerns, which is more straightforward.

Indeed but this issue is specifically about avoiding prose and being able to express it in a syntax definition :)

I do not know if you intentionally left out infering which color component keywords are valid outside calculations.

Those can indeed already be expressed today and doing so would be slightly better, but I am unsure if it is worth it as long as we can not express what is valid as a calc-keyword.

My use case is linters where it isn't realistic to write manual parsers/validations for everything as no one is willing to fund such efforts. Being able to express it in syntax definitions makes it possible to use @webref/css as a data source and css-tree as the validator.

As I understand it this is something that browser implementers are also interested in.

[cdoublev]

I am not sure if context specific productions can be used here as the channel keywords aren't valid everywhere in a relative color function.

This is invalid: rgb(from hsl(calc(r) 0 0) 0 0 0)

Yeah, the suggested productions comply with this.

Cc @svgeesus to get its feed back.