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

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