Re: [csswg-drafts] [css-values] Make top-level NaN be IACVT instead of ∞ (#7067)

The TAG just rereviewed, [with this comment](https://github.com/w3ctag/design-reviews/issues/708#issuecomment-1075383206):

> @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](https://w3ctag.github.io/design-principles/#consistency). We should try and avoid that.

I still believe there is no alternative that is better than the current behavior.

Addressing these bits of feedback directly:

* "we are concerned that imposing runtime errors through +infinity will break layouts in unpredictable ways."

 Any and all solutions share this property. There is literally no way to divine authorial intent in this situation; that's why it resolves to NaN in the first place rather than a number or an infinity.  In particular, the other solution presented here (making the property "invalid at used-value time") will be just as divergent from the author's intent as anything else. Thus, I don't believe this is a reasonable critique. There's no way to "predictably" break the layout in cases like this.

* "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."

 Again, I'm not sure how this is specific to the current spec text, rather than being a generic problem that will apply to any and all possible solutions. The timing of the NaN's appearance is the same regardless of what arbitrary action we take in response to it. Seeing a length go to infinity, as opposed to resetting the property to its initial value, seems equally easy (or difficult) to notice and debug. If anything, an infinity showing up might be easier to debug, as it more readily points to a math issue, as opposed to the initial value which can look like the property simply isn't being applied for some reason, which is a situation with *many* possible causes.

 (None of the options have any differences wrt dev tools, so this is purely a judgement call over how the behavior presents itself in the page.)

* "Further, given JS has handling of NaN different than +infinity, this proposal will introduce [inconsitency in the overall web platform](https://w3ctag.github.io/design-principles/#consistency). We should try and avoid that."

 Yet again, no solution we have available to us is different in this regard. JS "deals with NaN" by making it infectious across math operations, and eventually causing an API to throw, stringifying it (to confusing results, possibly also resulting in an API throwing), or doing some other arbitrary action as a response to the unexpected input. There is no consistency in any regard here; throwing a NaN into your JS code is very likely to cause *something* to break *somewhere*, but exactly when and where that happens is completely unpredictable.

 CSS NaN is also infectious to the same degree - across math operations.  CSS can't perform the equivalent of "throwing" upon receiving a NaN, as it has to keep laying out the page, but it can do something at the value level to censor it, which all proposed solutions do (just with different censoring results).

--------

On review, I find the feedback to be unactionable. There is no option that does not run equally afoul of every complaint listed, and to my judgement, every discussed option is equally bad or worse. CSS already has several precedents for handling unrecoverable logic errors with no discernable author intent by making them broken in a way that's hopefully obvious to the author, and I believe the current spec comports itself handily among those precedents. Introducing a new type of IACVT (but at used-value time) would not make the situation materially better in any way, and I believe would make it slightly worse in some ways (importantly, in ease of deducing where the problem lies, imo).

Agenda+ to suggest resolving to close this issue as no change.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7067#issuecomment-1075720260 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 22 March 2022 22:37:02 UTC