It looks like we're normalizing NaN and infinity too early; this results in a bunch of test failures seen in https://wpt.fyi/results/css/css-values?label=experimental&label=master&product=chrome&product=firefox&product=safari&aligned&view=interop&q=label%3Ainterop-2023-mathfunctions.

E.g. all our current failures on the trig-function tests at https://wpt.live/css/css-values/sin-cos-tan-serialize.html relate to serialization of NaN or infinite values.

I poked at the trig functions a bit, and a patch like https://treeherder.mozilla.org/jobs?repo=try&revision=89acb2d5850e80e576861b3ecbdae126d268f699 resolves the currently-failing sin-cos-tan-serialize tests. However, I wonder if some of this belongs better at a lower level -- should the cssparser serializer be modified to handle NaN & infnity?

Handling this would improve our Interop-2023 score.

Our failures in https://wpt.fyi/results/css/css-values/acos-asin-atan-atan2-serialize.html seem to be the same thing described here.
e.g. test expectation:
'rotate(acos(-1.5))' as a specified value should serialize as 'rotate(calc(NaN * 1deg))'.
with failure message:
!EQ("rotate(calc(NaN * 1deg))", "rotate(calc(0deg))")

https://wpt.fyi/results/css/css-values/round-mod-rem-serialize.html seems to be the same thing described here:
The failures look like this (from the wpt.live live test output):

assert_equals: 'calc(NaN)' should round-trip exactly in specified values.
expected "calc(NaN)" but got "calc(0)"

So we're not preserving an author-specified NaN value in our serializations, essentially.
(6 of the subtests there are Firefox-specific -- I'm talking about those ones. The other 6 subtests that we fail are failed by all browser engines in the same way, where everyone ends up with 1 or none in the serialization, which the test doesn't like. Those common failures are probably something different & perhaps a test bug.)