Also sprach L. David Baron:
> > product : unit [[ "*" S* unit ] | [ "/" S* NUMBER ]] *;
>
> This is a little different from what I'd been thinking. This change
> would mean that:
> calc(3em / (3 + 2))
> is an error while:
> calc(3em * (3 + 2))
> is valid. I would prefer changing NUMBER in your proposed change
> back to unit to avoid that; the change in the constraints is
> sufficient to do what I was proposing.
Ok. Done.
> This also led me to reread the whole formal grammar in order to
> understand the change. I noticed that there's a typo (misplaced
> quote mark) that requires the following change to fix:
> -min : "min(" S* sum [ "," S* sum ]* )"" S*;
> +min : "min(" S* sum [ "," S* sum ]* ")" S*;
Good catch.
> > > 4. Leaf values inside a calc() expression must all be either (a)
> > > numbers or (b) legal values for the property, or things that
> > > would be legal values if it weren't for range restrictions (such
> > > as the restriction that 'width' accepts only positive values).
> >
> > How about percentages?
>
> Percentages should be accepted when they are allowed values for the
> property, just like any other units.
That works for percentages. However, we must somehow prohibit keywords
and such from being accepted, e.g.:
calc(inherit)
I'd like to see the text quoted above (as 4.) merged with this text:
The semantic constraints are as follows: The context of the
expression imposes a <em>target type</em>, which is one of length, frequency,
angle, time, or number. Any PERCENTAGE token in the expression has the
target type. The NUMBER tokens are of type number, and the DIMENSION
tokens have types of their units ('cm' is length, 'deg' is angle
etc.). At each operator, the types of the left and right side have to
be compared and, if compatible, they yield a <em>result type</em>, roughly as
follows (the following ignores precedence rules on the operators for
simplicity):
But I think you can do it better than me.
-h&kon
HÃ¥kon Wium Lie CTO Â°Ã¾eÂ®Âª
howcome@opera.com http://people.opera.com/howcome