- From: L. David Baron <dbaron@dbaron.org>
- Date: Wed, 23 Dec 2009 11:24:59 -0500
- To: Shinichiro Hamaji <hamaji@chromium.org>
- Cc: www-style@w3.org
On Tuesday 2009-12-22 23:31 +0900, Shinichiro Hamaji wrote: > On Thu, Dec 17, 2009 at 6:06 AM, L. David Baron <dbaron@dbaron.org> wrote: > > > > In http://dev.w3.org/csswg/css3-values/#the-calc-function , there is > > currently text: > > > > # <number-multiplicative-expression> := > > # <number-term> | > > # <length-multiplicative-expression> S* '/' S* <length-term> | > > # <length-multiplicative-expression> S+ 'mod' S+ <length-term> > > I'm not sure, but I guessed the intention of this grammar is that > users can calculate how many ems they can put by calc(100%/1em). This > would explain why there isn't a rule for multiplication here. I think you're obviously correct. > However, I can see a sentence that says "Issue: At a later ... > division by length units etc. may be added." in the draft. Sorry if my > uneducated guess is totally wrong. Yes, that "Issue" does disagree with this text. > Anyway, if we will have '/' and mod for numbers, I think we should add > '*', too. Otherwise, the users may complain why they can > calc((2/2)*2px) but cannot calc((2*2)*2px). My personal preference is > supporting both, i.e., > > # <number-multiplicative-expression> := > # <number-term> | > # <length-multiplicative-expression> S* '/' S* <length-term> | > # <length-multiplicative-expression> S+ 'mod' S+ <length-term> > # <number-multiplicative-expression> S* '*' S* <number-term> | > # <number-multiplicative-expression> S* '/' S* <number-term> | > # <number-multiplicative-expression> S+ 'mod' S+ <number-term> Such a change does make sense. However, I think if we want the spec to allow division by values, it's better not to use the grammar to do the dimension-checking. For example, the current grammar allows these: (3em / 100%) * 3em 3em / 100% * 3em 3em * (3em / 100%) but disallows this: 3em * 3em / 100% which seems very strange. I would much rather they either be all allowed or all disallowed. I think it would be better to restructure the grammar so that the atomic unit allowed numbers or property-values (what it currently calls lengths, except modified per [1]), and the multiplicative expressions, additive expressions, and terms were not separate for numbers and values. Then the implementation would be required to track the dimension (unitless, value, value^2, 1/value, etc.) of the multiplicative and additive expressions and consider the expression a parse error if: * any additive expression had operands of different dimension, or * the final dimension was not value. This would also make it simpler to extend calc() to operating on properties that take <number> as values, such as 'line-height'. This could be done by simply changing the dimension check (second bullet in previous paragraph) so that properties allowing numbers allow unitless results. We might want to do this now. It would also make it simpler to extend calc() towards allowing units other than the ones accepted by the property in calc() expressions, by simply requiring different units (length, time, angle) to be tracked separately (with frequency being 1/time and resolution being 1/length). I think we probably don't want to do this in the first CSS level with calc(), although I don't think it's that hard. -David [1] http://www.w3.org/mid/20091216214248.GA5217@pickering.dbaron.org -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Received on Wednesday, 23 December 2009 18:29:32 UTC