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: Sun, 25 Jul 2010 14:27:04 -0700
Message-ID: <AANLkTinwc49wyPds-4nLugCMWDTZ_QYR9LSRdiw8LrSZ@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: www-style@w3.org
On Sun, Jul 25, 2010 at 11:48 AM, L. David Baron <dbaron@dbaron.org> wrote:
> In http://lists.w3.org/Archives/Public/www-style/2010Jan/0468.html I
> was given an action item to write a proposal for how to handle
> division and units inside calc().  The questions this proposal needs
> to resolve are:
>
>  (a) what values are accepted as the leaf values inside a calc()
>      expression,
>
>  (b) what units can be divided inside a calc expression, and
>
>  (c) if calc() allows division by values, how is division by zero
>      handled?
>
> My tentative conclusion is that supporting division by values is not
> among the top use cases for calc(), and since it poses considerable
> difficulty for both specification and implementation, we should not
> support division by values in the first level of the calc()
> specification.

Agreed that, while division by values is useful, it's not of primary
importance.  I'm okay with shifting that to the next level of calc().

> Therefore, I propose that:
>
>  1. We drop the 'mod' operator since it only makes sense when
>    both operands have the same units.
>
>  2. The right operand to the '/' operator be required to be unitless
>    (that is, a number or an expression composed of numbers).
>
>  3. Division by zero be a parse error (as I think it was in earlier
>    drafts of the specification, perhaps?).
>
>  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).

All of these seem acceptable, given the restriction above.  (In
particular, it's rather nice that divide-by-0 errors can now be caught
at parse time.)

~TJ
Received on Sunday, 25 July 2010 21:27:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:29 GMT