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

On 04/10/2014 06:41 PM, Simon Sapin wrote:
> On 10/04/2014 20:43, Zack Weinberg wrote:
[...]
>>     4. If the left side is a <number> or <integer> and the right side
>>        is a <length>, resolve to <resolution>.
>>     5. If the left side is a <number> or <integer> and the right side
>>        is a <time>, resolve to <frequency>.
> 
> If we have those last two, should we also have these?
> 
> (<number> or <integer>) / <resolution> = <length>
> (<number> or <integer>) / <frequency> = <time>

Probably; I just missed those possibilities.  I'm not sure how necessary
the special cases for the 1/x units are, though.

>>      If a (sub-)expression contains a division by zero which was not
>>      detected at parse time,
> 
> Having two different ways to handle division would confuse authors
> unless they learn the details of when each one is used, which they
> shouldn’t have to as it’s likely to be non-obvious.
> 
> Would it make sense to not detect divisions by zero at parse time at all
> and always do as below?

I would be fine with that behavior.  I doubt anyone is intentionally
relying on calc(foo / 0) being invalid, right now.

>>      the value of that (sub-)expression is
>>      infinite.  The result of any further computation on infinite
>>      values is also infinite, except that dividing any finite value
>>      by an infinite value produces zero.
> 
> So Inf/Inf and 0/0 are both infinite? This is implied by the proposed
> text, but might be worth mentioning explicitly.

Right.  As the note says, the rules here are in order to avoid dragging
in NaN and negative zero, which would have consequences far beyond this
module.  I'm not super happy about treating -ve/+0 as +Inf, but I think
that is vanishingly unlikely to come up in real life, and the moment you
have -Inf you have a bunch more indeterminate cases to kick around.
Also, in scenarios where division by zero results from a genuine
stylesheet bug, a used value that is much too positive is more likely to
be noticed than a used value that is much too negative, especially as
*any* negative value becomes zero in so many CSS contexts.

>>      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.
> 
> "Most positive value" seems hard to define when the context indicates no
> upper bound.

As I just said to Tab, in those cases the implementation-defined upper
limit (whatever that may be) is fine.  Note the wording immediately
above which asserts that an upper limit must exist.

zw