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

It sounds like people aren't opposed to a pow operator, right?

On Mon, Apr 7, 2014 at 6: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

We currently have a clause for table layout that allows it to treat
calc() as "auto" regardless, if the implementation feels like it.
Would it be okay to extend that clause to min()/max() too?

As far as I know, the weird "constraints bubble up" aspect of table
layout is explicitly not part of any other layout system, and staying
that way.  For the similar effect in Flexbox, we instead render such
percentages as "auto" and then resolve the percentage against that
length, which would be fine with min()/max().

> 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.  Like the min()/max() issue, it creates a bunch of new
> error cases that we need to decide how to handle, though in this
> case they're at least more clearly error cases that authors would
> percieve as error cases.

I'd like to deal with this at some point, though, so we can have mod as well.

> Division by lengths (or times, etc.) also makes the rules for unit
> analysis a bit harder, since it introduces the possibility of a
> valid calc expression with multiple types of units (e.g., lengths,
> times).  This isn't insurmountable, but requires a decent amount of
> work.

Why is this harder?  You already have to run checks on every
individual expression to make sure that the types are right, even if
they're all number or the same type, to make sure that, for example, a
division expression has a <number> or an expression that types to
<number> on the right.  It doesn't seem any more complicated to handle
more types.  Unless you're doing some odd checking, like doing a first
pass to check that everything is either a number or a single type,
then just doing simplified "number or non-number" checking on the args
at each operator.

~TJ

Received on Tuesday, 8 April 2014 23:01:41 UTC