Repository navigation
[css-sizing-3] compressible elements with aspect ratio #6341
Description
@bfgeek noted that when we allow compressible elements to compress down due to a percentage width or max-width, we limit that compression by their minimum size. He suggested that for elements with an aspect ratio, we might consider any explicit minimum size in the other dimension, transferring that through the aspect ratio. Do we want to spec this?
Activity
css-meeting-bot commentedon Jun 9, 2021
The CSS Working Group just discussed
[css-sizing-3] compressible elements with aspect ratio.The full IRC log of that discussion
<dael> Topic: [css-sizing-3] compressible elements with aspect ratio<dael> github: https://github.com//issues/6341
<dael> fantasai: iank_ noted we allow compressable to compress when have % width or max width. WE floor with explicit min size.
<Rossen_> q?
<dael> fantasai: Suggested things with a-r might want to consider min in other dimension. a-r and a min height might wantt to floor compression of width
<dael> fantasai: Wanted to ask WG if we want to spec that in Sizing 3. No one impl but iank_ wants to try
<dael> iank_: I think FF may impl it
<dael> iank_: in some cases.
<dael> Rossen_: What is % resolved in this case?
<dael> fantasai: Case where they don't resolve. Want min content contribution of the item.
<dael> fantasai: Usually we use natural size. When have % width we allow compress to close to 0. Exists for compat
<dael> Rossen_: Want to resolve the min width calc base on min-height b/c we have a-r
<dael> Rossen_: And if min height is also %?
<dael> fantasai: Wouldn't transfer anything, I think
<dael> Rossen_: And we would fav or over min-width that's spec
<dael> fantasai: I think we would honor spec min-width
<dael> fantasai: iank_ thoughts on that
<iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9399
<dael> iank_: It would take the maximum if min width and height are spec and don't agree
<dael> iank_: % would resolve if they can, similar to today. Can get cases where %height will resolve. Link to case^
<dael> iank_: You can see image is distorted. Doesn't have to be
<dael> Rossen_: My take is in general this make sense. Too many details. I think it would benefit if we tried to capture a short table of interaction and expected resolution
<dael> Rossen_: And expected values as to if % or spec and which wins
<dael> Rossen_: Would this be something iank_ you want to take on?
<dael> iank_: I can create a simple table. Should be straight forward. Order already resolves % if we can so straight forward
<dael> Rossen_: Cool. We can bring it next week and resolve
bfgeek commentedon Jun 16, 2021
Example 1:
In the above case would result in 100x100 green square. The
min-heighttransfers through the 1:1 aspect-ratio to be a transferred min-width of 100.Example 2:
In the above case would result in a 100x100 green square. The
min-heightcan resolve and transfers through the aspect-ratio. (The height here resolves if possible similar to a "height: 100%;" [1]).Example 3:
The above example cannot resolve the %-min-block-size. Resulting in 50x50.
Example 4:
Similar to today
min-content,max-contentetc will resolve to "zero".[1]
tabatkins commentedon Jun 16, 2021
Can we take this up again in two weeks, at the 6/30 call? I'm on vacation next week.
fantasai commentedon Jul 22, 2021
@bfgeek Some questions in my mind...
bfgeek commentedon Aug 4, 2021
So I think so.
Basically without resolving percentages if possible, example 2 will render the same as today which is a strange behaviour.
I don't that that there would be web compat concerns, specifically the "img { width: 100%; height: 100% }" case, we'd only consider min-height, not height. The compat concern would be something like "img { width: 100%; min-height: 100%; }" would change (I think thing setting asymetrically like this is relatively rare).
For grid/flex i think this is also fine. For grid specifically the "min-height: 100%" wouldn't resolve initially, unless we have a definite row height. Under the grid 2nd pass with an auto row (when they would resolve), it'll almost always match the row height.
Not sure what I was trying to say with example 4 - potentially was trying to say that we'd ignore the height, only consider the min-height.
css-meeting-bot commentedon Aug 4, 2021
The CSS Working Group just discussed
[css-sizing-3] compressible elements with aspect ratio, and agreed to the following:RESOLVED: When we have a compressible elements also transfer a fixed min block size through the aspect-ratio to become a min inline sizeThe full IRC log of that discussion
<dael> Topic: [css-sizing-3] compressible elements with aspect ratio<dael> github: https://github.com//issues/6341
<dael> iank_: The context for this is that when we've got compressible element. example min size we look at min width. If you've got min width 50px that's the min size. What nobody does with a-r is transfer min-height
<dael> iank_: Can get weird min width 50x and min height 100 px and a-r of 1:1 you end up with a rectangle. Proposal is allow the transfer
<dael> iank_: Interesting is what to do when can resolve min-height of 100%. That's what fantasai and I have been talking about
<dael> iank_: I'm on side of resolving % since that matches what we do with height and I think leads to better behavior. I think fantasai has concerns with that
<dael> fantasai: I read your reply, but haven't thought through it
<jensimmons> q+
<dael> fantasai: My concern is we have weird stuff with grid and flex with cyclic aspect of grid in particular. Don't want to resolve % in a way that causes issues
<dael> fantasai: Pretty sure we should transfer fixed sizes. Less sure on %
<dael> fantasai: I didn't notice you responding to is your table is assymetric between 2 axis and block size resolves and definite. Why not both definite or both 0?
<fantasai> s/didn't/did
<dael> iank_: That's what happens in the min/max size contributions. Resolve if it's definite and that transfers but inline axis is cyclic.
<dael> fantasai: I think symmetric is better
<dael> iank_: I don't think so. by def it's not symmertirc
<dael> fantasai: If height is resolved but not width it's weird
<dael> iank_: That's what happens, though
<dael> fantasai: % usually resolves in width
<dael> iank_: Explicitly for min/max. For inline axis they're cyclic. For block we do resolve when poss. That's how min/max works in all browsers today
<dael> astearns: Sounds like on that concern we should have test cases
<dael> iank_: Most of the test cases I've written. I can give example of how asymmetric today
<dael> fantasai: I think we can agree if it's fixed size it should transfer. Resolve on that and keep discussing %?
<astearns> ack jensimmons
<iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9536
<dael> jensimmons: Question is about use cases and not %. I have a system where an image is placed and I don't know a-r. I put on it max-wdith 100%. So that would be usually 100% but blow up if it's big.
<dael> jensimmons: I also do max height of 100dvh
<dael> jensimmons: So they I want it to be no bigger than 100vh if it's quite tall and it could shrink down a bunch becase of it's a-r.
<dael> jensimmons: Is that the intention of this?
<dael> fantasai: or that case nothing changes. Case is what happens if you have that code and a min-height or a min-width. How does that interact with your max if you put it in a shrink to fix box. What size will it end up being. In a min-content grid column current code allows the image to shrink to 0 even though has an intrinsic size
<dael> fantasai: If you set a min-width we won't shrink to 0. If we have a min-height instead do we transfer the min-height across the a-r to prevent collapsing to 0. That's the question here
<iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9537
<dael> fantasai: If you give it a min-height of 50px in a shrink to fix does it transfer across and have a min-width. The question iank_ has is if i set min-height 10% what do we do there
<dael> iank_: jensimmons I just put in a link to a case
<dael> iank_: fantasai I put in case 9536 to show the asymmetry we have today
<dael> astearns: We could resolve for the definite case. Or resolve for both definite and % and leave to fantasai to determine if % is incorrect?
<dael> fantasai: I'm not sure I understand the asymm issue. happy to resolve on fixed
<dael> astearns: Resolve on just the fixed today, then I'd want to come back next week for %
<dael> fantasai: Sure
<dael> iank_: Prop: When we have a compressible elements also transfer a fixed min block size through the aspect-ratio to become a min inline size
<dael> astearns: Any further discussion?
<dael> astearns: Objections?
<dael> RESOLVED: When we have a compressible elements also transfer a fixed min block size through the aspect-ratio to become a min inline size
<dael> astearns: We'll come back next week for % case
tabatkins commentedon Sep 7, 2021
@bfgeek Okay, so the resolution settled us transferring fixed sizes, leaving open the % sizes question (your examples 2 and 3).
@fantasai and I agree that Example 2 makes sense to resolve+transfer; the % is trivially resolveable, and it would be weird if it didn't act the same as a fixed min-height.
We're concerned about Example 3; not only would the behavior be inconsistent between grid/flex and block (tho only because percentages are already inconsistent between the two groups in some cyclic cases), but we're also afraid that it could result in cases like that one grid canvas issue where the element ends up larger than it should be because of a % resolved against an early automatic size.
Currently, we generically say that %s can resolve against "definite" sizes, and have a laundry list of exceptions to make some content-based sizes be considered definite in flex/grid. Is it possible to limit this just to resolving against the "traditional" fixed-lengths, and exclude the content-based sizes? Is that a distinction that the layout engines can make?
[css-sizing-3] #6341 Per WG resolution, fixed lengths transfer across…