Closed sesse closed 1 year ago
Many details of float handling can change things that depend on precise integers and non-dyadic rationals. Distribution can, sure, but just addition can result in things not adding up to exactly what you'd expect. CSS doesn't even specify the float size; pure numbers will probably be doubles, but impls use fixed point for lengths (with different bases!), so even trivial values can trigger browser differences.
The overall conclusion is just that CSS math is very rarely that dependent on exact results.
Gonna go ahead and close this; the only possible "fix" would be to go full JS and say that all CSS math is done in IEEE-754 doubles, with a precisely defined order of operations for all mathematical stuff. That's definitely not going to happen, since impls purposely use non-doubles for a number of reasons.
So yeah, CSS math is gonna (continue to) be somewhat underdefined.
Note that CSSOM already specifies a strict order of operations, so implementations are not really that free in practice.
Hi,
I noticed that css-values-4 says that we should “simplify” a * (b + c) to ab + ac. However, in practice this means web pages will change; as long as all browsers implement these values as floats, these are not equivalent.
Even barring overflow and underflow cases, something as innocent as floor(3 (4/3 + 1)) will be different from (3 (4/3) + 3) (one becomes 6, the other becomes 7). For a case that doesn't involve floor(), 3 (1 + 7/6) will round to 6 before and 7 now. (In the context of the standard, that would be someone writing e.g. calc(3 (1px + 7em/6)) assuming em = 1px, just for the sake of the example.)
Constant folding makes sense, but is this really a good thing?