Re: [csswg-drafts] [css-values-4] Ratio of `0/0`? (#4954)

The CSS Working Group just discussed ``[css-values-4] Ratio of `0/0`?``, and agreed to the following:

* `RESOLVED: Define aspect-ratio: 0/0 to be equal to aspect-ratio: calc(0/0)`

<details><summary>The full IRC log of that discussion</summary>
&lt;myles> Topic: [css-values-4] Ratio of `0/0`?<br>
&lt;myles> GitHub: https://github.com/w3c/csswg-drafts/issues/4954<br>
&lt;myles> TabAtkins: A bit ago there was a question of what an aspect ratio of 0/0 means. Auto? Invalid? Something else? I opened an issue, but then closed it because I thought there was an obvious answer. But fantasai re-opened it because it wasn't obvious. I'll give my explanation, but if there's no easy answer, we can keep the issue open.<br>
&lt;myles> TabAtkins: The behavior of 0/0 is [should be?] Identical to 1/0. They produce an element that produces an element that wants to be infinitely tall/wide, depending. We have text in the values spec about what to do when you say width: 154892798542. Should be clamped to largest value you support. Nothing wrong with infinite or 0 ratio.<br>
&lt;myles> TabAtkins: So 0/0 should preserve the concept of an earlier meeting: a/b should be the same as calc(a/b).<br>
&lt;myles> TabAtkins: If you do calc(0/0) you get NaN which turns into positive infinity, which is the same a 1/0. It's an easy answer.<br>
&lt;myles> TabAtkins: So calc(0/0) is already defined, so just writing 0/0 should act the same.<br>
&lt;TabAtkins> aspect-ratio: calc(0/0) i salready well-defined (and same as aspect-ratio: 1 / 0)<br>
&lt;myles> TabAtkins: OTOH, 0/0 is a clear error case, so we can make it fall back to the initial value. We can't reject it at syntax time because the 0s could be produced by calc. But we could fallback to auto. Not unreasonable. But because infinite ratios already have well-defined behavior, and the behavior of treating it like 1/0 falls out of the calc behavior already, it's easier to be consistent with that.<br>
&lt;fremy> honestly, why not<br>
&lt;tantek> technically 0/0 is an "indeterminate form" https://en.wikipedia.org/wiki/Indeterminate_form<br>
&lt;myles> leaverou: I don't have an objection, but it seems weird to treat 0/0 == 1/0. 0/0 is indefinite in maths. It seems more reasonable to treat as invalid than infinity. If we can't change calc(0/0), then internal consistency is more important.<br>
&lt;myles> TabAtkins: Yes, 0/0 is definitely indefinite, but we censure (sensure? sensor?) it to infinity<br>
&lt;tantek> did we consider animation implications here and is this the desired result? are aspect-ratio denominators animatable?<br>
&lt;fantasai> censor, I think<br>
&lt;myles> TabAtkins: Right now it always the case that calc() always produces a valid value. As long as you don't typecheck at parsing time, you can't produce a non-numeric value. That seems like a reasonable constraint to hold on to. Because you can approach 0 from different directions, there are multiple answers, but saying it's the same as 1/0 gives you *one* of the answers.<br>
&lt;myles> florian: Calc(0/0) can't turn into a keyword because it can be used in different properties<br>
&lt;myles> TabAtkins: When animation, we animate the division result, so the animation is consistent depending on whether you use calc(a/b) or use a / b, so animation behavior will be the same.<br>
&lt;myles> leaverou: If you animate 0/0 -> 0 / positive, you'll get disconuity.<br>
&lt;myles> TabAtkins: Don't do that.<br>
&lt;myles> TabAtkins: All the answers are arbitrary.<br>
&lt;myles> TabAtkins: We just pick one.<br>
&lt;dbaron> is it animated linearly or as the logarithm?  Using the logarithm seems like it would give more consistent behavior between dimensions...<br>
&lt;myles> heycam: Are there other properties other than aspect-ratio that takes a ratio? Aspect-ratio does discrete animation.<br>
&lt;myles> TabAtkins: I have an issue open about aspect-ratio animation. I propose that it works like division.<br>
&lt;myles> TabAtkins: The only other place where ratio type is used is the MQ about aspect ratio.<br>
&lt;myles> astearns: Do people feel the argument about keeping the current calc behavior and make aspect ratio match it, is that compelling enough? Or should we leave the issue open?<br>
&lt;florian> I buy into TabAtkins 's logic<br>
&lt;myles> fantasai: The people who raised concerns were AmeliaBR and cbiesinger<br>
&lt;tantek> I'm ok with TabAtkins logic though I'm going to s/indefinite/indeterminate per Wikipedia citation.<br>
&lt;myles> oriol: One argument about this, maybe we could say that saying the initial value is not possible, but we could resolve it to NaN and keep NaN into the outer calc, then bubble it up, and say if the number resolves to NaN it behaves as the initial value.<br>
&lt;myles> TabAtkins: If a top-level calculation ends up being NaN, the property would be invalid at computed value time. It's possible.<br>
&lt;myles> oriol: mhm.<br>
&lt;cbiesinger> q+<br>
&lt;myles> TabAtkins: I would prefer that aspect-ratio be consistent in both of its forms, but I don't have a strong opinion about which option we pick.<br>
&lt;myles> florian: For properties that take a single number or a single length, then sure. But if you're using calc() as one of many numbers in a property that takes many, like calc() in a shadow-spread, then maybe it's okay that you don't want to invalid the color just because the spread ended up being NaN.<br>
&lt;myles> cbiesinger: fantasai was poking me. I don't have an opinion. My suggestion is to treat 0/0 as the initial value. But I don't really have an opinion on how this should work with calc. But I don't really have an opinion<br>
&lt;myles> astearns: I'm inclined to resolve that we treat an aspect ratio of 0/0 as current calc(0/0). AmeliaBR isn't here, but we can always re-open the issue if she feels strongly about the resolution.<br>
&lt;myles> cbiesinger: calc(0/0) is a parse error in Chrome right now.<br>
&lt;myles> TabAtkins: We don't support dividing by zero yet (!!!)<br>
&lt;myles> RESOLVED: Define aspect-ratio: 0/0 to be equal to aspect-ratio: calc(0/0)<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4954#issuecomment-712470122 using your GitHub account


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

Received on Monday, 19 October 2020 22:10:30 UTC