Re: [csswg-drafts] [css-values-4] How to serialize infinite values? (#3768)

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