Re: [csswg-drafts] [media-queries][css-sizing] Support <number> (and therefore calc) as a <ratio> (#3757)

The CSS Working Group just discussed `Support <number> (and therefore calc) as a <ratio>`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Support &lt;number> (and therefore calc) as a &lt;ratio><br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/3757<br>
&lt;dael> emilio: A contributed impl this in FF. Couple issues related to thing we didn't resolve on. Resolved ot allow syntax as &lt;number> but not on serialize, if you can do two negative numbers. Regular aspect ratio we only allow positive int<br>
&lt;dael> [audio problems with emilio ]<br>
&lt;dael> Rossen_: While we wait on emilio to reconnect...<br>
&lt;dael> AmeliaBR: I can fill in<br>
&lt;emilio> thanks AmeliaBR!<br>
&lt;dael> AmeliaBR: Resolution we had previously was to loosely allow any number over a number or a single number as valid syntax<br>
&lt;dael> AmeliaBR: Simple q of serialization we've got backwords compat on people expecting int/int Anything spec that was should continue to serialize that way<br>
&lt;dael> AmeliaBR: Options from there are remember if it is spec with a / and keep that or always serialize with a / and add /1 if it's single number<br>
&lt;dael> AmeliaBR: As emilio points out there are other questions about how much do we simplify, if you've got -int/-int does it simplify or clamp. /0 is valid according to syntax, how to deal<br>
&lt;dael> AmeliaBR: One option is treat like calc but in serialization we add in the /1. Can lose numeric precesion in some fractions<br>
&lt;dael> AmeliaBR: If you 1/3 to get 0.6667/1 that would be a problem.<br>
&lt;dael> AmeliaBR: If we're not simplifying int fractions what to do with arbitrary numbers. Keep as two separate? Lean to keep 2 as separate and if isn't spec insert a 1. Simpliest approach and least likely to surprise<br>
&lt;AmeliaBR> s/If you 1/If you specify 2/<br>
&lt;dael> fantasai: SHouldn't reduce everything to over 1. HAve principle we serialize to most backwards compat and shortest, not just shortest. The older form serialization will need both numbers. Shouldn't simplify fractions down.<br>
&lt;dael> fantasai: Could do 9/3 to 3/1 but don't see a benefit to doing that<br>
&lt;dael> jensimmons: For clarity, is this visible to authors or is this in the caluclation when you get to computed<br>
&lt;dael> fantasai: For gCS<br>
&lt;dael> AmeliaBR: Effects both reading back value from dom, simple serialization,a nd serialization from gCS<br>
&lt;dael> fantasai: Important to notevalues from gCS need to roundtrip without loss. Simplifying 1/3 to 0.667 isn't in keeping with those principles. Not appropriate to do here.<br>
&lt;dael> AmeliaBR: We do it with calc, though<br>
&lt;dael> AmeliaBR: Worth mentioning for backwards compat the syntax is currently only in MQ. Not sure how much people are reading back values, but I'm sure someone is somewhere.<br>
&lt;dael> Rossen_: Couple minutes overtime. I don't believe we can resolve on this. Again, I invite folks to engage on GH and we'll pick up next week<br>
&lt;dael> Rossen_: Sorry we couldn't make any resolutions today, let's hope it's different next week. Thank you all for calling and we'll chat next week. It's APAC time zone.<br>
&lt;emilio> *:(<br>
&lt;emilio> Sounds good, thanks Rossen_ for all the chairing work :)<br>
&lt;Rossen_> trackbot, end meeting<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-525835114 using your GitHub account

Received on Wednesday, 28 August 2019 17:06:08 UTC