W3C home > Mailing lists > Public > www-style@w3.org > April 2014

Re: [css-values] Concrete proposal for unit algebra in calc()

From: Zack Weinberg <zackw@panix.com>
Date: Thu, 10 Apr 2014 21:14:38 -0400
Message-ID: <534741FE.60409@panix.com>
To: www-style list <www-style@w3.org>
On 04/10/2014 05:20 PM, Tab Atkins Jr. wrote:
> On Thu, Apr 10, 2014 at 12:43 PM, Zack Weinberg <zackw@panix.com> wrote:
>>
>> In section 8.1.2 (type checking), replace the second two bullet points
>> in the list with the following:
[...]
> 
> So this does require you to manually keep the units singular, right?
> You're not allowed to write "calc(1px * 2px / 3px)", because due to
> order-of-operations you'll first evaluate the multiplication and hit
> clause 6.  You'd have to reorder to "calc(1px / 3px * 2px)" or add
> parens to "calc(1px * (2px / 3px))" to produce a valid expression,
> right?
>
> I'm okay with this, as it keeps the implementation much simpler, just
> making sure that's intended.

Right.  It simplifies the specification as well as the implementation,
and we can always relax it later if there's demand.

>>     If the value resulting from a complete `calc()` expression is
>>     infinite, it is clamped and becomes the most positive value
>>     allowed in the target context.
>>
>> | NOTE: This deliberately differs from the behavior specified in IEEE
>> | 754 in order to avoid introducing NaNs and negative zero into CSS,
>> | However, implementations using IEEE 754-conformant floating point
>> | arithmetic internally can produce the above semantics by treating
>> | -Inf, +Inf, and NaN as "infinite", and -0 as equivalent to +0.
> 
> This "most positive value" will be implementation-defined in most
> cases, as very few value contexts actually have an upper cap.  Is that
> acceptable?

I think it is.  I decided on this approach because I didn't want to
declare the property invalid at used-value time; I suspect that would be
seriously inconvenient for implementations.  So division by zero needs
to produce some definite value, and treating it as +Inf (which then gets
clipped to the maximum supported value) avoids a discontinuity with the
behavior when the denominator is very small but nonzero.

In practice, I think division by zero is more likely to happen because
some parameter under user control has been pushed outside a sensible
range (the font is made very small, or the window is made very narrow,
perhaps) than because of a flat-out mistake in the style sheet.  In that
light, the actual value chosen doesn't matter all that much.

zw



Received on Friday, 11 April 2014 01:15:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:21 UTC