Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[css-sizing-3] compressible elements with aspect ratio #6341

Open
fantasai opened this issue Jun 2, 2021 · 7 comments
Open

[css-sizing-3] compressible elements with aspect ratio #6341

fantasai opened this issue Jun 2, 2021 · 7 comments
Labels
Commenter Response Pending css-sizing-3 Current Work

Comments

@fantasai
Copy link
Collaborator

fantasai commented Jun 2, 2021

@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?
@css-meeting-bot
Copy link
Member

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
Copy link

bfgeek commented Jun 16, 2021

Type length percentage everythingelse
min-inline-size length zero zero
min-block-size length resolves if definite zero

Example 1:

<!DOCTYPE html>
<div style="width: 0; line-height: 0;">
  <div style="float: left; background: green;">
    <canvas width=1 height=1 style="min-width: 50px; min-height: 100px; width: 100%;"></canvas>
  </div>
</div>

In the above case would result in 100x100 green square. The min-height transfers through the 1:1 aspect-ratio to be a transferred min-width of 100.

Example 2:

<!DOCTYPE html>
<div style="width: 0;">
  <div style="float: left; background: green; height: 100px">
    <canvas width=1 height=1 style="min-width: 50px; min-height: 100%; width: 100%;"></canvas>
  </div>
</div>

In the above case would result in a 100x100 green square. The min-height can resolve and transfers through the aspect-ratio. (The height here resolves if possible similar to a "height: 100%;" [1]).

Example 3:

<!DOCTYPE html>
<div style="width: 0;">
  <div style="float: left; background: green; height: auto;">
    <canvas width=1 height=1 style="min-width: 50px; min-height: 100%; width: 100%;"></canvas>
  </div>
</div>

The above example cannot resolve the %-min-block-size. Resulting in 50x50.

Example 4:

<!DOCTYPE html>
<div style="width: 0;">
  <div style="float: left; background: green; height: auto;">
    <canvas width=1 height=1 style="min-width: min-content; width: 100%;"></canvas>
  </div>
</div>

Similar to today min-content, max-content etc will resolve to "zero".

[1]

<!DOCTYPE html>
<div style="width: 0;">
  <div style="float: left; background: green; height: 100px">
    <canvas width=1 height=1 style="min-width: 50px; height: 100%;"></canvas>
  </div>
</div>

@tabatkins
Copy link
Member

Can we take this up again in two weeks, at the 6/30 call? I'm on vacation next week.

@fantasai
Copy link
Collaborator Author

fantasai commented Jul 22, 2021 •
edited

@bfgeek Some questions in my mind...

  • Why is the percentage column in your table asymmetrical?
  • Agree with example 1.
  • Examples 2 & 3, do we actually want to resolve percentages in these cases?
    • Gets weird with grid and flex (resolve in cyclic cases) vs. block (doesn't resolve).
    • Could cause web-compat problems? e.g. img { width: 100%; height: 100% } is likely very common, and would be expected to make the items' width compressible to zero, but if that height starts to resolve and transfer across to floor the width, would we have a problem?
    • If so, maybe only transfer absolute sizes (resolving percentages against zero for this purpose)?
  • Example 4, shouldn't min-content resolve to the natural size (1px)? (Compressibility doesn't compress the min-content size, but only the min-content contribution.)

@bfgeek
Copy link

bfgeek commented 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
Copy link
Member

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 size
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> 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

@mozilla-apprentice mozilla-apprentice mentioned this issue Aug 4, 2021
Open
@bfgeek bfgeek added the Agenda+ label Aug 9, 2021
@astearns astearns removed the Agenda+ label Aug 18, 2021
@tabatkins
Copy link
Member

@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?

tabatkins added a commit that referenced this issue Sep 7, 2021
@tabatkins
[css-sizing-3] #6341 Per WG resolution, fixed lengths transfer across…
2e3ba43 
… the aspect ratio when dealing with cyclic %s on replaced elements.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Commenter Response Pending css-sizing-3 Current Work
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@tabatkins @fantasai @bfgeek @astearns @css-meeting-bot