- From: Zack Weinberg <zackw@panix.com>
- Date: Wed, 23 Apr 2014 20:08:55 -0400
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: www-style list <www-style@w3.org>
On Wed, Apr 23, 2014 at 7:56 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On the telcon today we accepted this proposal for V&U Level 4 That was fast! Yay. > , but with some changes: > > * We should allow negative infinity; at minimum, it's produced by > subtraction with a finite LHS and infinite LHS, or the negation of an > infinite value. If you allow -Inf then you have to decide what +Inf + -Inf means, and at that point I suspect it's easiest to just adopt the IEEE rules, NaN and all. As there are no comparisons in calc(), the further "NaN != NaN" headache does not arise. But it is then also necessary to decide on the behavior of -Inf and NaN as the final result. -Inf logically becomes the most negative allowed value (which in many cases will be 0), but I'm going to suggest that NaN be treated as *positive* infinity to raise the odds that someone will notice the math error. Gecko can reasonably log a console message at computed-value time whenever a division by zero occurs, but I'm not sure about used-value time. > * We'll discuss whether to accept full IEEE semantics; given that > impls are probably using them for the values of at least some types > anyway, it might be worthwhile. (Lengths are generally fixed-width in > impls, but I dunno how most impls store other types like resolution or > time.) I think it's all C 'float' in Gecko, but don't quote me on that. > * We'll allow unit powers other than 1/0/-1. So, calc(1px * 2px / 3px) is valid then? That's probably most convenient for authors. > In addition, you suggest that every computation with an infinity > results in an infinity. Obviously the intent is to make infinities > infectious, but as suggested it means that invalid unit math doesn't > invalidate the calc(). I suspect that the infinity should still > participate in unit-checking? Err, yeah, that was an oversight on my part. Infinities should retain their dimensions. Also, given what Matt Rakow said earlier today, I think the inverse length stuff should be dropped. zw
Received on Thursday, 24 April 2014 00:09:18 UTC