# Re: Can we have more maths in calc()?

From: Zack Weinberg <zackw@panix.com>
Date: Mon, 7 Apr 2014 21:41:10 -0400
Message-ID: <CAKCAbMhhK0RXdGVK68SyLnC4dXemN3wcRGAX9iYY+iJdp6_==w@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: www-style list <www-style@w3.org>
```On Mon, Apr 7, 2014 at 9:22 PM, L. David Baron <dbaron@dbaron.org> wrote:
> On Sunday 2014-04-06 21:36 -0400, Zack Weinberg wrote:
>> If I can have _just two_ additional calc() features, min() plus being
>> allowed to divide one <length> by another (the result being a
>> dimensionless number) would mean not needing JavaScript in a scenario
>
> For what it's worth, my previous post on why min() and max() are
> hard(ish):
> http://lists.w3.org/Archives/Public/www-style/2011Oct/0735.html

OK, I can see why you would be unenthusiastic about min and max on
<length> particularly when percentages get involved, but note that the
use case I described only requires them for <number>.  Can the same
mess still creep in if they are restricted to <number>?  (I'm trying
to see if we could do this piecemeal.)

> Adding division by lengths requires deciding how to handle division
> by zero.  Currently calc() handles division by zero by rejecting
> such values at parse time, but that's not possible with division by
> lengths.

Are there any circumstances where  (expr) / <length> risks division by
zero when the denominator is not syntactically detectable as zero? Not
(expr) / (expr) where the denominator happens to be type length, but a
literal <length>.

Again, piecemeal seems to be the way to go here.

zw
```
Received on Tuesday, 8 April 2014 01:41:33 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:39 UTC