- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sun, 25 Jul 2010 14:27:04 -0700
- 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 UTC