[css-color-4] Computed value and serialization of `Infinity` and `NaN` in color functions

[romainmenke]

What are the expected values and serializations for these examples?

• lab(calc(Infinity) 0 0)
• lab(50% calc(Infinity) 0)
• lab(calc(NaN) 0 0)
• lab(50% calc(NaN) 0)
• ...

manually setting these values seems illogical but they can be the result of calculations and variables. e.g. calc(var(--foo) / var(--bar)) where --bar is possibly zero.

---

Currently browsers do very different things in some area's.

Chrome and Safari seem to agree that lab(50% calc(Infinity) 0) serializes as lab(50% Infinity 0), but that no longer roundtrips because the required calc was removed. That seems like an obvious bug, but maybe I overlooked something.

Chrome renders lab(50% calc(Infinity) 0) as white.
Safari renders lab(50% calc(Infinity) 0) as black.

Chrome also sometimes renders a pink area in certain edge cases

WPT doesn't have any tests for these kinds of values.

[tabatkins]

Chrome and Safari seem to agree that lab(50% calc(Infinity) 0) serializes as lab(50% Infinity 0), but that no longer roundtrips because the required calc was removed.

Yes, that's clearly wrong. The arguments aren't calculations, they're either keywords (channel names) or math functions. We should get a WPT enforcing this.

Rendering is just a consequence of the "clamp it to your actual allowed range" behavior that V&U specifies for infinite (and other arbitrarily-large finite) values. I'm not sure what the actual behavior of a ginormous a value should be, but whatever it is, that's the correct rendering. (I suspect white? But I have no actual knowledge here.)

[romainmenke]

I'm not sure what the actual behavior of a ginormous a value should be, but whatever it is, that's the correct rendering. (I suspect white? But I have no actual knowledge here.)

Also unsure.
Consistency would be nice, but I can imagine that this is very sensitive to implementation details.

In our implementation for the a/b component :

• a very large but finite number: white
• positive and negative infinite: black

color.js seems to produce white and blue after gamut mapping. But I am never sure if I am using that library correctly.

let color = new Color("lab(50% 0 0)");
color.coords[1] = Infinity
color
color.toGamut('srgb')

[romainmenke]

I've added a few tests for serialization of calc(Infinity) : web-platform-tests/wpt#39137

I have no idea how NaN should be handled, so I skipped that for now.

[cdoublev]

I have no idea how NaN should be handled, so I skipped that for now.

If I am not mistaken, only nested math functions (unresolved before computed value) can produce NaN: calc(min(1em, 0px / 0) + 1px) would serialize to calc(1px + min(1em, NaN * 1px)) as a specified value.

If a top-level calculation (a math function not nested inside of another math function) would produce a value whose numeric part is NaN, it instead act as though the numeric part is 0.

https://drafts.csswg.org/css-values-4/#top-level-calculation

I think your tests should serialize Infinity to lowercase.

As usual for CSS keywords, these are ASCII case-insensitive. Thus, calc(InFiNiTy) is perfectly valid. However, NaN must be serialized with this canonical casing.

https://drafts.csswg.org/css-values-4/#calc-error-constants

Hope it helps. =)

[romainmenke]

Thank you @cdoublev

I've changed the tests to lowercase infinity, this indeed matches tests under css-values.

[tabatkins]

The behavior of NaN is specified in https://drafts.csswg.org/css-values/#top-level-calculation - it gets censored to 0 when it would escape the calculation tree. It serializes as NaN, tho, similar to infinity, at whatever level it's been able to infect to, given the simplification rules and what value stage you're serializing.

[romainmenke]

For lab(calc(NaN) 0 0) or lab(calc(0 / 0) 0 0):

• computed value lab(0 0 0)
• serializes as lab(calc(NaN) 0 0)

Would that be correct?

[cdoublev]

It serializes as NaN [...] at whatever level it's been able to infect to

Thanks for the clarification. My understanding of the spec was that it only serializes as NaN in non-top level calculations (or NaN * 1 unit when the calculation type is not empty).

Would that be correct?

I am not in the position to give an answer but it would say yes, then.

[tabatkins]

@romainmenke yes

@cdoublev What part of the spec is leading you to believe that a top-level NaN doesn't serialize as such? I might have made a mistake.

[romainmenke]

I've added some test for NaN : web-platform-tests/wpt@789c766

[cdoublev]

What part of the spec is leading you to believe that a top-level NaN doesn't serialize as such? I might have made a mistake.

The part that we both referred to (edited for clarity):

• If a top-level calculation would produce a value whose numeric part is NaN, it instead act as though the numeric part is 0.
• If a top-level calculation would produce a value whose numeric part is 0⁻, it instead acts as though the numeric part is the standard "unsigned" zero.

Taking Example 38 following this part:

calc(-5 * 0) produces an unsigned zero — the calculation resolves to 0⁻, but as it’s a top-level calculation, it’s then censored to an unsigned zero.

calc(0 / 0) produces 0 — the calculation resolves to NaN, but as it’s a top-level calculation, it’s then censored to zero.

Basically my understanding meant that NaN could only appear in the serialization of unresolved nested calculations.

---

I am also missing why Chrome currently serializes the next example to calc(infinity) instead of calc(-infinity).

On the other hand, calc(1 / calc(-5 * 0)) produces −∞ [...] the inner calc resolves to 0⁻, and as it’s not a top-level calculation, it passes it up unchanged to the outer calc to produce −∞

[tabatkins]

The part that we both referred to (edited for clarity):

That's about how the value actually acts in the property it's used in, when the final result is a NaN. The simplification and serialization of the calculation itself is well-defined by the simplification and serialization algos, and they preserve NaNs at whatever level they show up in.

I am also missing why Chrome currently serializes the next example

Looks like a bug.

[romainmenke]

The tests were merged : web-platform-tests/wpt#39137

---

That only leaves the open question of how to handle enormous values :

Rendering is just a consequence of the "clamp it to your actual allowed range" behavior that V&U specifies for infinite (and other arbitrarily-large finite) values. I'm not sure what the actual behavior of a ginormous a value should be, but whatever it is, that's the correct rendering. (I suspect white? But I have no actual knowledge here.)

I suspect the right value will just fall out of implementations that are free of bugs but maybe good to have a few examples/tests?

@svgeesus Do you know or have an opinion on how something like lab(50% calc(Infinity) 0) which has an absurdly large a should behave?

Anyone writing lab(50% calc(Infinity) 0) manually should expect bogus results, but infinity can be the result of a calculation.

[svgeesus]

@svgeesus Do you know or have an opinion on how something like lab(50% calc(Infinity) 0) which has an absurdly large a should behave?

All colors of the form lab(50% calc((var(--n)*100) 0) where n > 0 have the same (LCH) hue, and increasing chroma. Thus, even if the color itself is imaginary, the gamut mapped used value of the color should be lab(50% x 0) where x is the greatest chroma that can be displayed for that hue and lightness. I would apply the same logic to +Infinity (and -Infinity gives the opposite hue).

Where b is not zero, as a increases the contribution of b on the resulting hue decreases, so as a tends to infinity the hue tends towards b being effectively zero. So I guess infinite values of either a or b make the other component powerless? And thus there are eight effective hues that the color tends towards, depending on the sign of the component and whether only one, or both, have Infinity values?