Hi @DevSDK,

We briefly looked at this today during a breakout and had a question. We were a little troubled by:

According to the spec, It says "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 +∞." Therefore NaN will be calculated as positive infinity.

What is the reasoning to make NaN behave as +Infinity?

Hi @LeaVerou ,

I guess my explainer need more description.

According to the specification, Only output NaN value from calc() will be +Inf. (Inside of calc(), NaN acts NaN).

I will edit my explainer to make this clear.

cc. @xiaochengh

@tabatkins spec editor in case I missed anything

The situation here is that:

• All calc() must be valid at parsing time, because parse-time value range checking is basically impossible
• Even if calc() result is NaN, we still need to make the CSS property value valid. We can't put a NaN there

So treating calc() result NaN as positive infinity looks like an arbitrarily chosen fallback to me.

Or would it better if we want to follow the same approach as custom properties that, any propety value involving a NaN calc() is invalid at computed time, and is resolved as initial/inherit? Or is it overengineering?

@LeaVerou We've talked about this in CSS calls already (or in the issue tracker, I don't remember).

Yes, treating it as infinity is just an arbitrary fallback that's likely to produce something obviously wrong, so the author will hopefully realize it. It's similar to invalid colors turning into transparent black.

I didn't go for IACVT because that's a big stick and only necessary if we have no idea what the value's type is. For a math function, like a color function, that's not the case, so we can emit a slightly more relevant error value. initial/inherit can mask the error more easily.

@LeaVerou, @atanassov and myself reviewed this issue during our Hybrid TAG f2f. We still have concerns about the current proposal that are best for the CSS WG to review, thus, we suggest another round of discussions there. In particular, we are concerned that imposing runtime errors through +infinity will break layouts in unpredictable ways. For the purposes of layout, calc expressions can be evaluated during used-value time which in turn can depend on user context. This can result in unpredictable and difficult to evaluate/debug problems. Further, given JS has handling of NaN different than +infinity, this proposal will introduce inconsitency in the overall web platform. We should try and avoid that.

Are one of y'all (Lea?) gonna open a follow-up issue, or am I supposed to?

Ah, I suppose the existing issue is still open and appropriate to use, disregard last message.

Closing, since the latest WG resolution satisfies our concerns. Thank you for flying TAG!