[media-queries][css-sizing] Support <number> (and therefore calc) as a <ratio>

[AmeliaBR]

The new aspect-ratio property in css-sizing-4 re-uses the <ratio> data type defined for the aspect-ratio media query, which currently only excepts rational fractions defined as <integer> / <integer>.

For flexibility, I propose extending the <ratio> type to support:

• a single <number> value (so that you could specify aspect-ratio: 1.5 instead of aspect-ratio: 3/2)

• maybe, an arbitrary numerical fraction (aspect-ratio: 3.3/2.2)

• maybe, a fraction of lengths (aspect-ratio: 1ch/1em)

The "maybes" are because — for the property, if not the media query — they could be replaced with calc() functions if (a) a single number value (the result of the math expression) is accepted as a ratio, and (b) for length fractions, calc division of values with units is actually implemented.

[jonjohnjohnson]

@AmeliaBR Quick question, maybe you can infer from the spec text better than I, before I open up a separate ticket... I see mention of inline-size and block-size and writing modes in relation to Example 3 specifically. But should I assume aspect-ratio will simply be physical mapping x/y, then hopefully receives the eventual Flow-Relative Keyword for logical mapping?

[AmeliaBR]

@jonjohnjohnson That's actually a really good question — mind opening a separate issue?

[jensimmons]

Before we decide anything, please read this page about aspect ratios: https://en.wikipedia.org/wiki/Aspect_ratio_(image)

It's common to express an aspect ratio as a ratio — for example 16/9 is expressed as 1.77:1. Or shortened to 1.77. I'd rather we don't invent new web-only ways to express something.

[AmeliaBR]

@jensimmons So, you're saying that a single number with decimals is sensible, in addition to the ratio of integers, but everything else is just complicating things without benefit? (and, as I noted in the first comment, can be replaced with calc, anyway)

[tabatkins]

I agree that we should widen the grammar to <number> / <number>; restricting it to <integer> doesn't match common practice and doesn't actually help us with anything.

Given that, I don't think we need to provide a single-number pattern; 1.77 / 1 seems fine?

[css-meeting-bot]

The CSS Working Group just discussed Aspect Ratios, and agreed to the following:

• RESOLVED: change <integer> to <number> in the aspect-ratio
• RESOLVED: allow <number> and <number>/<number> both for <aspect-ratio>

The full IRC log of that discussion

<fantasai> Topic: Aspect Ratios
<fremy> ScribeNick: fremy
<astearns> github: https://github.com//issues/3757
<fremy> AmeliaBR: currently for the aspect-ratio media query we define a ratio type (integer slash integer)
<fremy> AmeliaBR: we are thinking about using the same type for the aspect-ratio property
<fremy> AmeliaBR: I think we should support decimal in addition to the fraction
<fremy> AmeliaBR: so <int>/<int> or <number>
<heycam> q+
<fremy> jensimmons: I can see how this looks like a fraction, but I don't think of it this way
<chris> its a rational number, not a fraction
<fremy> jensimmons: interested people can look at the history of aspect ratio in the film industry
<fremy> jensimmons: there is both 16/9 or 16:9 or 1.77
<fremy> jensimmons: I don't see us wanting to have 1.77:1
<fremy> jensimmons: that is confusing
<fremy> myles_: is it bad that when you actually divide these numbers you get non-round numbers?
<TabAtkins> q+
<chris> https://www.mathsisfun.com/rational-numbers.html
<fremy> AmeliaBR: yes, this is why we prefer the "fraction-looking" expression
<fremy> myles_: so we don't want to convert to a number, right?
<fremy> jensimmons: no, we would keep the other representation
<chris> q+
<fantasai> myles: I don't want to have a 1px gap because of people's mental rounding errors
<astearns> ack heycam
<fremy> AmeliaBR: but when authors have numbers they computed themselves in some other way, we don't want to force them to use a fraction
<fremy> heycam: so, if you want to use css variables, you would want to use calc() right?
<fremy> myles_: native api often expose numerator and denominator as distinct in those cases
<fremy> chris: come on folks, are we really discussing this?
<astearns> q?
<fremy> chris: this is a rational number, we can allow that and other forms of numbers, this is very common outside of css
<astearns> ack TabAtkins
<chris> The ancient greek mathematician Pythagoras believed that all numbers were rational, but one of his students Hippasus proved (using geometry, it is thought) that you could not write the square root of 2 as a fraction, and so it was irrational.
<chris> q-
<fremy> TabAtkins: I think I agree that accepting all numbers is reasonable, for the calc() cases
<leaverou> q+
<chris> But followers of Pythagoras could not accept the existence of irrational numbers, and it is said that Hippasus was drowned at sea as a punishment from the gods
<fremy> TabAtkins: but I don't think we need to add just plain <number> because it's ambiguous
<AmeliaBR> q?
<jensimmons> q+
<dbaron> Tab's proposal (do just change <integer>/<integer> to <number>/<number>) sounds good to me
<astearns> ack leaverou
<florian> q?
<fremy> leaverou: I don't understand why there is an ambiguity?
<fremy> leaverou: can't we do both? why do we want to pick one?
<fremy> TabAtkins: ok, there is no ambiguity, but it makes the syntax more complex, I appreciate consistent things
<TabAtkins> s/it's ambiguous/it's nice to have a single consistent syntax pattern/
<fremy> TabAtkins: but you are are, it's not ambiguous
<fremy> AmeliaBR: well we will get questions anyway, some will wonder why you have to write 1.5/1 instead of just 1.5 but ok that's doable
<astearns> ack jensimmons
<fremy> jensimmons: calc() and variables, can someone explain how that would work now and with the proposals?
<leaverou> s/I don't understand why there is an ambiguity?/I don't understand why we can't do both. There is no syntactical ambiguity./
<fremy> TabAtkins: today, if you use calc, it would get weird results, because we only allow integers, so they would be rounded
<fremy> TabAtkins: so it works in theory, but it's not very practical
<fremy> TabAtkins: the proposal would allow to have any number, so you can compute using a ratio of two variables
<AmeliaBR> s/well we will/we can wait until we have more authors using this, and then see if/
<fremy> jensimmons: that sounds reasonable, but there is a very common case with just a number, I don't see why not adding that as well
<fremy> astearns: and that seems common, so I'd plus on that
<florian> q?
<fremy> TabAtkins: I would prefer not to add syntax when it doesn't add much, but if there is strong demand for this, I could get convinced
<fremy> astearns: so, can we resolve to change <int> to <number> for aspect ratio values?
<fremy> RESOLVED: change <integer> to <number> in the aspect-ratio
<fremy> TabAtkins: for the second part, what do implementers think?
<fremy> dbaron: I think that I cross-multiplied to avoid rounding, but I'm not sure
<fremy> dbaron: I considered it because otherwise it's a bit scary if people might try an equality and rounding is risky then
<chris> people comparing two floats for equality need to learn why that is never a good idea
<fremy> dbaron: but code has been rewritten since then anyway
<fremy> dbaron: so I don't know
<fremy> myles_: is that relevant though?
<fremy> TabAtkins: maybe not, but I was curious
<myles_> s/is that relevant though?//
<fremy> astearns: I think we should try to keep the syntax simple, and revisit if we get requests
<emilio> https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/servo/components/style/media_queries/media_feature_expression.rs#31
<fremy> hober: but priority of consituency indicates that we should favor allowing to drop the slash one
<fremy> astearns: also, looking at the example emilio pasted in irc, the slash one looks dumb, so I changed my mind a bit
<fremy> jensimmons: also, I don't buy the complexity of having two syntaxes
<emilio> s/emilio/AmeliaBR :)
<myles_> <number> | <number> / <number>
<fremy> astearns: ok, so let's try to resolve to allow <number> and <number>/<number> both
<AmeliaBR> s/AmeliaBR/flackr/
<fremy> dbaron: well, that constraints syntax a bit, but I'm fine with it
<dbaron> s/constraints/constrains/
<jensimmons> this is really good. And it’s good to do it now.
<fremy> RESOLVED: allow <number> and <number>/<number> both for <aspect-ratio>

[jonjohnjohnson]

I'd be remiss to not bring up @jensimmons comment about calc'n on top of aspect ratio behavior on the grid related issue...

Fluid video (that has an aspect ratio, like 16x9), with fixed-height controls running along the length of the video directly underneath.

.video {
 width: 100%;
 height: calc(.5625tr + 25px);
}

#333 (comment)

Could it be possible to support this somehow with calc() in the aspect-ratio property? The only way I imagine this behavior would be covered, albeit using extra elements, is if box-sizing being set to content-box, then offset the ratio size by using padding/border with a descendant was positioned accordingly?

[tabatkins]

Yes, using a-r on the content box, then using padding/border to get the extra space, is the only way (currently) to do that. We should probably track that case tho (an aspect ratio, plus/minus some extra space in either or both axises) as another issue.