- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Apr 2022 17:01:44 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-values] Make top-level NaN be invalid at computed value time instead of ∞`. <details><summary>The full IRC log of that discussion</summary> <fantasai> topic: [css-values] Make top-level NaN be invalid at computed value time instead of ∞<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7067<br> <fantasai> TabAtkins: When we added the ability to do arbitrary unit math to calc(), we introduced the ability to divide by zero<br> <fantasai> TabAtkins: these turn into infinities, fine, handle as large number<br> <fantasai> TabAtkins: We also introduced Nans, though<br> <fantasai> TabAtkins: We don't now how to make those behave<br> <fantasai> TabAtkins: We can't know what author intended without inspecting code<br> <fantasai> TabAtkins: so need to do something arbitrary to Nan<br> <fantasai> TabAtkins: Current spec turns NaN into infinity if it escapes a calc() function<br> <fantasai> TabAtkins: I chose this because a) Nan is definite an authoring error, always a mistake<br> <fantasai> TabAtkins: b) infinite is the most likely value to look wrong if you're doing something with this<br> <fantasai> TabAtkins: We have an unofficial policy throughout CSS, whenever we have a situation that can't detect at parse time, but is obviously a mistake<br> <lea> q?<br> <lea> q+<br> <fantasai> TabAtkins: we make it break in an obvious way, so that author is more likely to notice the mistake<br> <emilio> q+<br> <fantasai> TabAtkins: rather than doing something more sublte, that might be missed<br> <fantasai> TabAtkins: This came up during TAG review, and Lea suggested that it's better handled as "invalid at computed value time" behavior<br> <fantasai> TabAtkins: I don't have a strong opinion on this<br> <fantasai> TabAtkins: my only objection to changing behaving time is that it won't be invalid at computed value time, might not know it's invalid until *used* value time<br> <Rossen_> q<br> <fantasai> TabAtkins: so similar to IVACT, but distinct<br> <fantasai> TabAtkins: And whatever effect it has would behave differently wrt inheritance, for example<br> <fantasai> TabAtkins: The other reason is that I think IVACT behavior is less likely to be noticeable<br> <fantasai> TabAtkins: It's less likely to be obviously wrong, compared to treating as infinity<br> <fantasai> TabAtkins: I think Nan should break things as much as we possibly can<br> <fantasai> TabAtkins: and would be useful for authors to give them the more broken rendering<br> <fantasai> TabAtkins: but open for discussion<br> <emilio> ack fantasai<br> <Rossen_> ack fantasai<br> <Rossen_> ack lea<br> <fantasai> lea: I don't remember most of the arguments from TAG review, but think there's a more fundamental principle here<br> <fantasai> lea: errors don't always arise from authoring, sometimes from user-generated or other variable input<br> <fantasai> lea: and user will be first to see this<br> <fantasai> lea: I want to avoid making the website undreadable<br> <fantasai> lea: For things like layout, can be very bad<br> <lea> q?<br> <fantasai> lea: I'm not opposed, but problem with infinity because it would introduce really bad breakage, would be seen by users first<br> <Rossen_> q?<br> <oriol> q+<br> <fantasai> TabAtkins: I don't agree that invalid at computed value time is less likely to break<br> <Rossen_> q+<br> <fantasai> TabAtkins: if you're specifying a width as a calc(), that's going to be some specific value. If at some point, because using variables, results in a Nan and becomes invalid at computed time, that'll switch to 'auto'<br> <fantasai> TabAtkins: which is just as completely different from author's intent as infinity is<br> <fantasai> TabAtkins: we cannot divine an intent from a Nan<br> <miriam> q+<br> <fantasai> lea: Width: auto might produce a layout that's not intended, but not the same level as breakage as infinity<br> <fantasai> lea: which can stretch out of the viewport and make content unreadable<br> <fantasai> emilio: I was going to point out what Tab pointed out, that we still have an issue of what happens if NaN happens at used value time<br> <fantasai> emilio: I'm not a fan of introducing behavior that depends on cascade before/after<br> <fantasai> emilio: if we detect NaN at computed value or used value time...<br> <fantasai> emilio: As for what specific behavior, I don't have a super strong opinion<br> <fantasai> emilio: When we define NaNs in ..., we normalize to zero.<br> <fantasai> emilio: Usually just happens in testcases<br> <Rossen_> ack emilio<br> <iank_> we can only really determine this stuff at used value time.<br> <fantasai> emilio: I don't think it will matter in practice<br> <fantasai> emilio: I think zero is a bit more reasonable, doesn't create infinite scrollbars<br> <fantasai> emilio: I think I'm not a fan of the 2 different behaviors based on when you find the NaN<br> <miriam> q-<br> <fantasai> oriol: I'm not a big fan of the currently-specified behavior of treating NaN as positive infinity, which seems arbitrary to me<br> <fantasai> oriol: That's why I filed this issue to try to choose something closer to invalid at computed value time<br> <fantasai> oriol: During discusison realized this would be a problem for properties that have multiple components<br> <fantasai> oriol: Maybe only one of these is NaN<br> <fantasai> oriol: And sometimes we turn these properties into shorthands,<br> <TabAtkins> If it's infinity specifically that bugs people, I can go with "treat as 0".<br> <Rossen_> ack oriol<br> <fantasai> oriol: If we invalidate the entire property now, and later turn it into a shorthand, then we would only invalidate specific longhands<br> <TabAtkins> Just as likely to be wrong, but less likely to pop scrollbars.<br> <fantasai> oriol: To prevent this creating a change in behavior<br> <fantasai> oriol: we would need some kind of ???<br> <lea> I think "treat as 0" is more reasonable. width: 0; overflow: hidden would be problematic, but hopefully that'd be rare<br> <fantasai> oriol: So now I'm more aligned with choosing a specific number for NaN instead of an approach similar to IVACT<br> <fantasai> oriol: I'm not sure infinity is the best, maybe zero or minus infinity<br> <fantasai> Rossen_: I think that during our discusison, and reason to revisit, the compounding effect of infinity can have very unpredictable results based on current user settings, viewport size, fonts available, etc.<br> <fantasai> Rossen_: that will make detectability of such errors difficult for authors, since spurious at best<br> <fantasai> Rossen_: Given we're out of time, don't want to force a resolution<br> <fantasai> Rossen_: but want to really go back and continue and see if we can agree on something more platform friendly<br> <fantasai> TabAtkins: in IRC, discussiong changing to zero<br> <fantasai> TabAtkins: I'm fine with that, Lea's fine with it<br> <chris> zero looks better to me<br> <fantasai> Rossen_: Ok, let's return to that next week<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7067#issuecomment-1104187025 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 April 2022 17:01:45 UTC