You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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":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. Themf-*
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>
forinterpolate()
<calc-sum>
forcalc-interpolate()
<color>
forcolor-interpolate()
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>
The text was updated successfully, but these errors were encountered: