- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 17 Feb 2022 22:14:19 +0000
- To: public-css-archive@w3.org
(For further history, the call that originally discussed this issue is minuted at <https://lists.w3.org/Archives/Public/www-style/2014Apr/0373.html>.) > This seems very random to me, why ∞ instead of e.g. -∞, 0, 1, or 3.14159? Because the most likely cause of a NaN is division by 0, and the limit as you approach division by zero is either +Infinity or -Infinity, and +Infinity is more likely to be correct (CSS is usually doing math on positive values). NaN can be produced via other mistakes, which can have a variety of limits, but since a NaN indicates a math error, preserving the authors precise intent wasn't considered too important; in these cases where the limit of the author's code is *not* Infinity, returning Infinity is the most likely value to produce a noticeably incorrect result. > This is why we introduced [the none keyword](https://drafts.csswg.org/css-color-4/#missing) and the [powerless component concept](https://drafts.csswg.org/css-color-4/#powerless) in CSS Color 4 to represent things like indeterminate hue angle, because NaN had the wrong behavior. No, this is a false summary of that discussion. We introduced `none` because `NaN` was completely inappropriate for the use-case. Conflating a missing component and a component that has a division by zero or other invalid math operation is completely wrong. NaN is used for missing channels in some JS color libraries because because its infectious behavior is slightly better/more recognizable if you forget to handle the case and naively do math on the channel (aka the "make it fuck up as badly as possible so authors notice the error" behavior, which Lea appears to be arguing is bad); using JS's `null` is more semantically appropriate (and more closely matches common JS practice in general), but less good in practice, since it coerces to `0` in many math operations and thus could hide the error. CSS works differently in these regards, so the JS-based reasoning was irrelevant, and we could stick with common CSS design principles and use a keyword for the non-numeric value. > We don't want to break people's websites on purpose to alert them that they made a mistake, this is not XML! We do this all the time, in many CSS features. For a relatively recent example that comes to mind, setting the grid positioning properties to a line name that doesn't exist will collapse them all to the first implicit line, which is almost certainly a bad position that will look wrong to the author. And as I mentioned in the preceding paragraph, breaking people's websites on purpose was *the precise reason provided for JS color APIs to use NaN for missing channels*. (Heck, CSS's forward-compatible parsing, which drops the entire property when there's a mistake, is also an example of this.) > And I highly doubt that using Infinity will make the author think "oh, I think I have a NaN!". It will likely just baffle them to no end, and make them conclude that they can't understand CSS. Do you think that using IACVT makes it more noticeable, understandable, or teachable? If so, can you elaborate on this reasoning? -------- FWIW I'm not necessarily opposed to changing the behavior here, but I am opposed to some of the arguments being deployed in service of this proposed change; they're wrong and don't reflect our general design philosophy elsewhere in CSS. There is a reason for the current behavior, and it's consistent with CSS's established design philosophy. I don't recall if this was a specific reason for avoiding IACVT, but I'll note that you might not know the value is invalid at computed-value time; if a percentage is involved in producing a 0 division, it might not be apparent until used-value time when the % is finally resolved. So this would actually need to be a brand-new concept, and I'm not sure of the implications of that right now. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7067#issuecomment-1043529918 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 17 February 2022 22:14:21 UTC