W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2020

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

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Wed, 15 Apr 2020 22:25:56 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-600624541-1586989554-sysbot+gh@w3.org>
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-values-4] Ratio of `0/0`? ==
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.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4954 using your GitHub account
Received on Wednesday, 15 April 2020 22:25:58 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:04 UTC