W3C home > Mailing lists > Public > www-style@w3.org > July 2010

Re: [css3-values] proposal for handling division and units in calc() ?[ACTION-205]

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 26 Jul 2010 09:49:52 -0700
Message-ID: <AANLkTimswPTrdH7L26JGEDy4=eduN-g6sVcjzyn1Uu_j@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: "L. David Baron" <dbaron@dbaron.org>, "www-style@w3.org" <www-style@w3.org>
On Mon, Jul 26, 2010 at 9:24 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> OK, I realized later that what I said about percentages was pretty silly, for any case where '1' means something different than '100%'.
> So the main problem is that you need to know at parse time if there is a division by zero so you can throw out the declaration, and you can't know that until you get computed values, right?
> It just seems odd that it would be OK to write 'calc(0.333333333in)' but not 'calc(1/3in)'. I know there are other ways to work around that as an author, but still...

Those are actually completely different expressions - one has a unit
of "in", the other has a unit of "1/in".  ^_^  This is more obvious if
you put in the required spaces around the operator - you get "calc(1 /
3in)", which is obviously not what you want.  Express it as calc(1in /
3), which should still be legal under dbaron's changes.

> What if you just parsed as normal, and then anything that would end up meaning "divide by zero" was nudged into meaning "divide by 0.000001", or something similar that would not be rounded to zero even if the final used value is rounded to zero?  In that case, you wouldn't need to discard the declaration at parse time.

Well, we'd decided before that it was probably most sensical to have
run-time /0 errors evaluate to whatever the default value is for the
property.  This isn't ideal either, but is slightly closer to the
ideal "ignore" behavior that we want and use for parse-time errors.

> By the way, I'd be fine with not allowing units in the divisor that were not allowed as the final value (so no 'Hz' or  's' for lengths).

That's equivalent to just not allowing bad units in the first place,
since if a bad unit appears in the dividend, but you're not allowed to
put bad units in the divisor, the quotient is stuck with the bad unit.

You have to be all-in or all-out here.  Either we do full dimensional
tracking (which, though interesting, is definitely of niche usefulness
and shouldn't be necessary for v1), or we restrict it to only valid

Received on Monday, 26 July 2010 16:50:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:48 UTC