- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Apr 2019 22:42:59 +0000
- To: public-css-archive@w3.org

So this is actually a larger issue; in level 3 I could always simplify a valid calculation into a summation of ordinary units, and the current serialization text assumes that is still true. Adding in the min/max/clamp functions invalidated that (requires a summation of units and an arbitrary number of functions), but adding in unit algebra blew it away completely. There are now valid calculations that I can't simplify down further than an operator-tree. So, to what degree to I want to simplify? I could still require simplifying mult/div by numbers, and require that summations be sorted in the existing specified way, to maintain compat with Level 3 calc() simplifications. I don't *think* I want to go any further than that; even if I could simplify in some cases (like simplifying `1in / 10px * 1em` to just `9.6em`) it would be complex to specify and not really clear to authors what's happening, I think. So my proposal is precisely that: * mult/div by a literal number must be simplified away * summations must be sorted in a compatible way to the old specification - ordinary units are sorted alphabetically by unit (with number and % in their specified positions), followed by functions and more complex sub-calculations (wrapped in parens) in source order. * infinite values are serialized as `1/0`, with the numerator having the appropriate canonical unit for the type Still not completely sure what to do with NaNs. They're fully infectious; a NaN argument to any function results in NaN, and a NaN at any depth in a calculation causes the top-level calculation to be NaN. Maybe simplify the whole thing to `calc(1/0)`? Do this even if the original math function wasn't calc(), like `clamp(0px/0, 1px, 50px)` serializing to `calc(1/0)`? That has a possibility of being valid, tho; `z-index` would accept that value. I think I need to define an always-invalid math function form, like a literal `calc()`, which is *grammatically* valid in itself, but has no type and thus is invalid in all contexts it can ever be placed. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3768#issuecomment-479685056 using your GitHub account

Received on Wednesday, 3 April 2019 22:43:01 UTC