The boolean expression multiplier, <boolean-expr[]>, was introduced to allow defining conditions (booleans) with a unified syntax (#10457).

With <boolean-expr[ <cq-test> ]>, the production specified in [ ] is injected as <test> in this "template":

<boolean-expr[ <test> ]> =
    not <boolean-expr-group>
  | <boolean-expr-group> [ [ and <boolean-expr-group> ]* | [ or <boolean-expr-group> ]* ]

<boolean-expr-group> = <test> | ( <boolean-expr[ <test> ]> ) | <general-enclosed>

Basically, it is a solution to define context-sensitive productions.

In #10790, I tried to show that it would be useful to unify the syntax of <media-feature>, <size-feature>, <scroll-feature>.

<size-feature> and <scroll-feature> are defined as "the same as for a media feature", which works, is simple, but is arguably not ideal. <media-feature> produces <mf-plain>, <mf-name>, <mf-value>, etc. The mf-* prefix makes their names context specific, and although <mf-name> expands to <ident>, which is context-free, it is restricted to the feature names accepted in the context.

Another example of syntaxes to unify is *-interpolate(), which produce the same value definition but with different <output-value> depending on the context:

• <whole-value> for interpolate()
• <calc-sum> for calc-interpolate()
• <color> for color-interpolate()
• etc

But color-interpolate() also needs to produce <color-interpolation-method> as a specific interpolation option. The syntax expression multiplier would come short here. It does not allow defining multiple context-sensitive productions for the same unified syntax.

Another problem of the syntax expression multiplier is that a new template must be defined for each syntax to unify.

On the other hand, there does not seem to be much more use cases. There are <color-stop-list> and <angular-color-stop-list>, and perhaps selector productions in some functional selectors.

But I think these limitations force defining these interpolation functions with specific productions, and prevent defining granular productions like <interpolation-global-options>, <interpolation-stop>, <interpolation-stop-options>, etc. These productions may be useful to help defining and understanding how *-interpolate() works, and to implement them.

Anyway, below are some alternatives to the expression syntax multiplier, demonstrated with the color-interpolate() use case.

(1)

• <interpolation-map <output-value>="<color>" <stop-options>="<color-interpolation-method">

(2)

• <color-interpolate()><output-value> = <color>
• <color-interpolate()><stop-options> = <color-interpolation-method>

(3)

• <color-interpolate()/output-value> = <color>
• <color-interpolate()/stop-options> = <color-interpolation-method>

(4)

• <output-value context="color-interpolate()"> = <color>
• <stop-options context="color-interpolate()"> = <color-interpolation-method>