- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Jun 2019 19:03:15 +0000
- To: public-css-archive@w3.org
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>` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Aspect Ratios<br> <fremy> ScribeNick: fremy<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/3757<br> <fremy> AmeliaBR: currently for the aspect-ratio media query we define a ratio type (integer slash integer)<br> <fremy> AmeliaBR: we are thinking about using the same type for the aspect-ratio property<br> <fremy> AmeliaBR: I think we should support decimal in addition to the fraction<br> <fremy> AmeliaBR: so <int>/<int> or <number><br> <heycam> q+<br> <fremy> jensimmons: I can see how this looks like a fraction, but I don't think of it this way<br> <chris> its a rational number, not a fraction<br> <fremy> jensimmons: interested people can look at the history of aspect ratio in the film industry<br> <fremy> jensimmons: there is both 16/9 or 16:9 or 1.77<br> <fremy> jensimmons: I don't see us wanting to have 1.77:1<br> <fremy> jensimmons: that is confusing<br> <fremy> myles_: is it bad that when you actually divide these numbers you get non-round numbers?<br> <TabAtkins> q+<br> <chris> https://www.mathsisfun.com/rational-numbers.html<br> <fremy> AmeliaBR: yes, this is why we prefer the "fraction-looking" expression<br> <fremy> myles_: so we don't want to convert to a number, right?<br> <fremy> jensimmons: no, we would keep the other representation<br> <chris> q+<br> <fantasai> myles: I don't want to have a 1px gap because of people's mental rounding errors<br> <astearns> ack heycam<br> <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<br> <fremy> heycam: so, if you want to use css variables, you would want to use calc() right?<br> <fremy> myles_: native api often expose numerator and denominator as distinct in those cases<br> <fremy> chris: come on folks, are we really discussing this?<br> <astearns> q?<br> <fremy> chris: this is a rational number, we can allow that and other forms of numbers, this is very common outside of css<br> <astearns> ack TabAtkins<br> <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.<br> <chris> q-<br> <fremy> TabAtkins: I think I agree that accepting all numbers is reasonable, for the calc() cases<br> <leaverou> q+<br> <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<br> <fremy> TabAtkins: but I don't think we need to add just plain <number> because it's ambiguous<br> <AmeliaBR> q?<br> <jensimmons> q+<br> <dbaron> Tab's proposal (do just change <integer>/<integer> to <number>/<number>) sounds good to me<br> <astearns> ack leaverou<br> <florian> q?<br> <fremy> leaverou: I don't understand why there is an ambiguity?<br> <fremy> leaverou: can't we do both? why do we want to pick one?<br> <fremy> TabAtkins: ok, there is no ambiguity, but it makes the syntax more complex, I appreciate consistent things<br> <TabAtkins> s/it's ambiguous/it's nice to have a single consistent syntax pattern/<br> <fremy> TabAtkins: but you are are, it's not ambiguous<br> <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<br> <astearns> ack jensimmons<br> <fremy> jensimmons: calc() and variables, can someone explain how that would work now and with the proposals?<br> <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./<br> <fremy> TabAtkins: today, if you use calc, it would get weird results, because we only allow integers, so they would be rounded<br> <fremy> TabAtkins: so it works in theory, but it's not very practical<br> <fremy> TabAtkins: the proposal would allow to have any number, so you can compute using a ratio of two variables<br> <AmeliaBR> s/well we will/we can wait until we have more authors using this, and then see if/<br> <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<br> <fremy> astearns: and that seems common, so I'd plus on that<br> <florian> q?<br> <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<br> <fremy> astearns: so, can we resolve to change <int> to <number> for aspect ratio values?<br> <fremy> RESOLVED: change <integer> to <number> in the aspect-ratio<br> <fremy> TabAtkins: for the second part, what do implementers think?<br> <fremy> dbaron: I think that I cross-multiplied to avoid rounding, but I'm not sure<br> <fremy> dbaron: I considered it because otherwise it's a bit scary if people might try an equality and rounding is risky then<br> <chris> people comparing two floats for equality need to learn why that is never a good idea<br> <fremy> dbaron: but code has been rewritten since then anyway<br> <fremy> dbaron: so I don't know<br> <fremy> myles_: is that relevant though?<br> <fremy> TabAtkins: maybe not, but I was curious<br> <myles_> s/is that relevant though?//<br> <fremy> astearns: I think we should try to keep the syntax simple, and revisit if we get requests<br> <emilio> https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/servo/components/style/media_queries/media_feature_expression.rs#31<br> <fremy> hober: but priority of consituency indicates that we should favor allowing to drop the slash one<br> <fremy> astearns: also, looking at the example emilio pasted in irc, the slash one looks dumb, so I changed my mind a bit<br> <fremy> jensimmons: also, I don't buy the complexity of having two syntaxes<br> <emilio> s/emilio/AmeliaBR :)<br> <myles_> <number> | <number> / <number><br> <fremy> astearns: ok, so let's try to resolve to allow <number> and <number>/<number> both<br> <AmeliaBR> s/AmeliaBR/flackr/<br> <fremy> dbaron: well, that constraints syntax a bit, but I'm fine with it<br> <dbaron> s/constraints/constrains/<br> <jensimmons> this is really good. And it’s good to do it now.<br> <fremy> RESOLVED: allow <number> and <number>/<number> both for <aspect-ratio><br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3757#issuecomment-499625710 using your GitHub account
Received on Thursday, 6 June 2019 19:03:20 UTC