- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Aug 2020 16:15:09 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-sizing-3] Ratio-constrained elements in definite-sized Grid/Flexbox containers`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-sizing-3] Ratio-constrained elements in definite-sized Grid/Flexbox containers<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5317<br> <dael> TabAtkins: Little complicated<br> <dael> TabAtkins: Currently if you have a ratio-constrained element like and image, we put in grid of flexbox which are def. sized. Rule for ratio end up basing element sizing on inline axis<br> <bkardell_> prsent+<br> <dael> TabAtkins: In the example in the issue elements are [missed] and element is 1:1 ratio. Sizes to container and maxes it 220px high<br> <dael> TabAtkins: In example container is 220px wide 100 tall. Default is base on inline axis. 200px wide and transfers across ratio and overflows. We believe more expected is in case where both sizes are definite contain into them. Base on the smaller one. Becomes 100x100 which makes the smaller row<br> <Guest60> present-<br> <dael> TabAtkins: Current behavior in this case is inconsistent. No one does what we suggest. Chrome doesn't do what spec says either, though.<br> <dael> TabAtkins: Call for impl to check this out and see if they think it's reasonable. We think better in general but not certain<br> <dael> TabAtkins: Don't need resolve, but need impl to look.<br> <dael> ??: Why would this size to full available since elements usually shrink to fit<br> <astearns> s/??/cbiesinger/<br> <dael> AmeliaBR: svg in general if you have inline with no other constraints it fits available width. Just block layout behavior<br> <Rossen_> q?<br> <dael> AmeliaBR: Also comes from original svg spec which is svg w/o sizing fills 100% in each direction. If it's inside css layout we put constraints on that so it doesn't take page. only fills width if it has a-r<br> <dael> AmeliaBR: Brings quesiton if it has clearly defined available height should that factor in. I think probably reasonable and useful behavior that it does. Whichever dimension is the clearly defined one, that's what it fills. Than a0r is opposite dimension<br> <dael> AmeliaBR: Question becomes can we define consistent w/o special cases<br> <dael> iank_: What happens today with similar svgs?<br> <dael> AmeliaBR: Last I checked not consistent<br> <dael> fantasai: IN spec if length for min we use that, if not 300x150. Maybe just 300<br> <dael> dholbert: How to determine flex base size?<br> <dael> fantasai: Yes<br> <dael> TabAtkins: And similarly for grid<br> <dael> cbiesinger: Seems specific to svg unlike generic summary<br> <dael> TabAtkins: Any image that can have ratio but not width and height which is only svg<br> <dael> AmeliaBR: svg or svg linked from image element<br> <dael> fantasai: with a-r same behavior will end up being relevent<br> <dael> AmeliaBR: Good point<br> <dael> cbiesinger: a-r has inline style based on contents, right?<br> <dael> fantasai: true<br> <dael> Rossen_: Sounds like a number of cases to consider<br> <cbiesinger> s/style/size/<br> <dael> Rossen_: Do we comfortable with an approach or do we take for more details in the issue? Was intent to just introduce, TabAtkins , or get resolution?<br> <dael> TabAtkins: I got what I wanted<br> <dael> Rossen_: Then I suggest we move on and continue in issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5317#issuecomment-676522553 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 August 2020 16:15:11 UTC