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

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...

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.

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).


On Jul 25, 2010, at 9:00 PM, L. David Baron wrote:

> On Sunday 2010-07-25 17:27 -0700, Brad Kemper wrote:
>> On Jul 25, 2010, at 11:48 AM, "L. David Baron" <dbaron@dbaron.org> wrote:
>> 
>>> 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,
>> 
>> Can you elaborate on why this is difficult? It seems to me that if
>> any value that is in units allowed by the property could be
>> coerced into a percentage, and from there it is a short hop to
>> being a unitless number. I assume that dividing by percentages is
>> still OK anyway, isn't it, since a percentage is just another way
>> to represent a digital number? 
> 
> Percentages aren't just like numbers; they mean whatever percentages
> mean for the property, which is something with units.
> 
> It's difficult from a specification and implementation perspective
> because it requires figuring out what to do with division-by-zero
> after the cascade has already happened (so there's no fallback).
> 
> It's difficult (in the sense of being a good bit of work) from an
> implementation perspective because one has to write code to track
> the different dimensions represented by units so that the
> implementation can determine that
>  calc((500px / 10Hz + 50px * 3s) / 1s)
> computes to
>  200px
> and is therefore a valid value for 'width'.  But I'd feel like I was
> wasting my time writing code to do that, because I don't see why
> anyone needs it.
> 
> -David  
> 
> -- 
> L. David Baron                                 http://dbaron.org/
> Mozilla Corporation                       http://www.mozilla.com/

Received on Monday, 26 July 2010 16:24:53 UTC