[css-values-4] Ratio of 0/0?

[tabatkins]

So, the old <ratio>, since it only allowed integers, could meaningfully restrict its values to "greater than zero", so all ratios you could write were meaningful.

Now that we've relaxed it to <number>, we can't do that - can't do open ranges. So 0 is allowed.

And mostly that's fine! A ratio of 0/1 is just infinitely tall; a ratio of 1/0 is infinitely wide; CSS is okay with infinities. The "division results" are well-defined too - 0 and infinity, respectively.

But what about 0/0? We can't reject this at parse-time, since a calc() might be hiding a 0. But it definitely doesn't have a meaning; the division result is NaN.

Two possibilities I see:

1. Define that it produces an "invalid ratio", and places that take <ratio> have to define what that means. The 'aspect-ratio' property would define that it doesn't give an aspect ratio (same as "none"); the (aspect-ratio) MQs would define that it always fails to match.

2. Make it act the same as calc(0/0): it produces a NaN, which is censored into an infinity, so it's the same as saying 1/0 for the ratio.

I'm mildly leaning toward option 2. It's more consistent with 0/0 in general, and it means we don't need to ensure that every place that uses <ratio> defines what an "invalid ratio" does.

[tabatkins]

Never mind, I'm strongly in favor of option 2 actually; it ensures that aspect-ratio: calc(X/Y); and aspect-ratio: X/Y; have identical behavior in all cases.

[AmeliaBR]

Zero/infinite values were discussed #3757 (comment). My comment there mostly agrees with you above, although I seem to have skipped over the aspect-ratio: 0/0 issue. I'd personally prefer to treat that as invalid = no aspect ratio defined.

See also #4572, which came up when I was searching for the other discussion & is probably worth another look — when taking the aspect ratio from width/height attributes, do you ignore a zero value? Unlike the aspect-ratio property, here we have actual browser behavior to compare (though I doubt it would be a strong web compat issue to change, since it is kind of an extreme edge case).

[vwkd]

Might want to delete the reference in css-values-4#ratio since this issue is closed?

[fantasai]

Not sure Tab agreeing with himself but disagreeing with Amelia qualifies as an obvious bugfix. :) Also related is #5557 which was raised by @cbiesinger so flagging for WG discussion.

[LeaVerou]

First, I agree it should be the same as calc(0/0). Anything else would cause confusion.
I don't understand the sentence "it produces a NaN, which is censored into an infinity". Mathematically, 0/0 does not tend to infinity and is an indeterminate form.
It seems more reasonable that it would be invalid at computed value time, or something along these lines.

[css-meeting-bot]

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)

The full IRC log of that discussion

<myles> Topic: [css-values-4] Ratio of `0/0`?
<myles> GitHub: https://github.com//issues/4954
<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.
<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.
<myles> TabAtkins: So 0/0 should preserve the concept of an earlier meeting: a/b should be the same as calc(a/b).
<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.
<myles> TabAtkins: So calc(0/0) is already defined, so just writing 0/0 should act the same.
<TabAtkins> aspect-ratio: calc(0/0) i salready well-defined (and same as aspect-ratio: 1 / 0)
<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.
<fremy> honestly, why not
<tantek> technically 0/0 is an "indeterminate form" https://en.wikipedia.org/wiki/Indeterminate_form
<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.
<myles> TabAtkins: Yes, 0/0 is definitely indefinite, but we censure (sensure? sensor?) it to infinity
<tantek> did we consider animation implications here and is this the desired result? are aspect-ratio denominators animatable?
<fantasai> censor, I think
<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.
<myles> florian: Calc(0/0) can't turn into a keyword because it can be used in different properties
<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.
<myles> leaverou: If you animate 0/0 -> 0 / positive, you'll get disconuity.
<myles> TabAtkins: Don't do that.
<myles> TabAtkins: All the answers are arbitrary.
<myles> TabAtkins: We just pick one.
<dbaron> is it animated linearly or as the logarithm? Using the logarithm seems like it would give more consistent behavior between dimensions...
<myles> heycam: Are there other properties other than aspect-ratio that takes a ratio? Aspect-ratio does discrete animation.
<myles> TabAtkins: I have an issue open about aspect-ratio animation. I propose that it works like division.
<myles> TabAtkins: The only other place where ratio type is used is the MQ about aspect ratio.
<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?
<florian> I buy into TabAtkins 's logic
<myles> fantasai: The people who raised concerns were AmeliaBR and cbiesinger
<tantek> I'm ok with TabAtkins logic though I'm going to s/indefinite/indeterminate per Wikipedia citation.
<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.
<myles> TabAtkins: If a top-level calculation ends up being NaN, the property would be invalid at computed value time. It's possible.
<myles> oriol: mhm.
<cbiesinger> q+
<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.
<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.
<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
<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.
<myles> cbiesinger: calc(0/0) is a parse error in Chrome right now.
<myles> TabAtkins: We don't support dividing by zero yet (!!!)
<myles> RESOLVED: Define aspect-ratio: 0/0 to be equal to aspect-ratio: calc(0/0)

[tabatkins]

Fixed in 84a573d