W3C home > Mailing lists > Public > www-style@w3.org > December 2009

Re: [css3-values] calc()'s <number-multiplicative-expression> incorrect

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
Message-ID: <20091223162459.GA10414@pickering.dbaron.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.


[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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:31 UTC