[css-grid-1][css-sizing-3] aspect-ratio-only boxes should be able to size to grid container

[fantasai]

If we put an image which has only an aspect ratio into an auto-row/auto-column grid cell in a fixed-size grid...

• We try to find the range of size for the auto tracks by finding the min/max contributions of its items.
• The grid item, being an image with no size, has a min-content contribution of zero. According to css-sizing-3, it takes its max-content size from the available space (if that is definite) or else falls back to 300px.
• The available space to a grid item when finding its max-content contribution is undefined. :(

(We don't run into this problem for non-replaced elements, because their min/max-content contributions don't refer to the available space in the inline dimension, and for orthogonal flows we do define the available space.)

The available logical width we provide to an item with an aspect ratio and no size should either be the “available grid space” (the size of the grid container if definite), or it should be infinity. (Infinity in this case will resolve to an image width of 300px/ICB size depending on issue #4218.) In the case where the grid container's size is definite, do we want to use it instead?

[jensimmons]

If I understand this correctly, I believe it should resolve to the Grid container size / “available grid space”. As an Author, I would have no idea why it resolved to 300px.

[css-meeting-bot]

The CSS Working Group just discussed aspect-ratio-only boxes should be able to size to grid container.

The full IRC log of that discussion

<dael> Topic: aspect-ratio-only boxes should be able to size to grid container
<dael> github: https://github.com/w3c/csswg-drafts/issues/4228
<dael> fantasai: I think case where we found as we audited sizing rules. When we don't have definite available space, could provide grid-container size. Currently undefined or infinity. You have an item and an auto-sized grid track. Tries for max-content. Row doesn't have size so when we try and size we say infinite. Maybe we should provide grid size
<dael> fantasai: This would be change to way grid works
<dael> fantasai: How it finds the max-content size of an item in a row that is not fixed
<dael> jensimmons: When fantasai talked this through I liked what she proposed. Image should fill what's available. I was +1 to it
<florian> s/You have white-space: pre/You have white-space: pre-wrap/
<dael> fantasai: When trying to find max-content width and item needs to know height to resolve it then we need ot take into account height to find width. If we don't have one we try and shift to container size. IN grid container case the contaier is the grid area and if it's auto it doesn't have a size we can pass to algo
<AmeliaBR> q+
<dael> fantasai: So it ends up as inifintiy or undef and not a number.
<dael> fantasai: Proposa: in case of grid if row doesn't have a size you can use then you look up to grid container and use that
<astearns> zakim, open queue
<Zakim> ok, astearns, the speaker queue is open
<fantasai> https://drafts.csswg.org/css-sizing-3/#intrinsic-sizes
<myles> s/cripple them/use them only in a UI context/
<dael> fantasai: Applies in sizing of image with aspect ratios ^
<AmeliaBR> q+
<dael> Rossen_: Every time we try and make a dependency all layout algo become difficult. All layouts are def to operate on a single container item relationship basis. BReaking that rule and defining this layout type you will be defining a size based on an ancestor things become difficult
<myles> s/person spoofing/person "spoofing" system UI design/
<dael> Rossen_: We have made that exception before like orthogonal flows, but it is implemented as an exception to find the ancestor with a defined size. This is an exception and usually ugly at cost of artifacts.
<dael> Rossen_: You can always create cases where this becomes inefficient
<myles> s/would expose as/would probably expose as/
<dael> fantasai: Not looking at ancestor, grid row looks to grid container
<dael> Rossen_: But you have a grid inside a grid insiade a grid. Always a case where these exceptions fall and people think it's just a few above. Already one ancestor, why not more?
<dael> fantasai: It's not an ancestor. It's grid container
<dael> Rossen_: Layout PoV we're going through area that's used for layout considerations for resolving positioning. We are proposing to escape layout area and go to container which is next level ancestor of grid item
<dael> fantasai: Containing block corrisponds to actual box in other layout cases. Grid has abstract containing block as a sub part of grid. When using that to calc max content when itself isn't fixed we look at grid container sizing property. I think this is reasonable to do
<dael> Rossen_: In case where grid container has undefined size?
<dael> fantasai: No change to that case
<dael> Rossen_: But the point I was trying to make is grid container could be a grid item. It needs to go to its container grid
<dael> fantasai: Not doing that for writing modes so not doing for aspect ratio. If the grid container was height 100% and 400px it's fixed and would pass down to its children. It's child to parent but in grid there's a structure which is the grid. Grid is containing block of grid child but doesn't look at containing block to get a size
<dael> fantasai: Proposal is to say that even though parent is not containing block it takes a size from it when it needs a size
<dael> Rossen_: That's my point
<dael> fantasai: You're arguing we'd walk up chain, but we're doing child to parent directly
<dael> Rossen_: Once we add thigns like subgrid we'll have to keep that use case in mind and continue thinking bout this exception case where we defer to a different level. You will face that case all the time if we make an exception now
<dael> Rossen_: Would prefer if we're using the grid item's type contribution. I think it was second proposal? max-content size from available space
<dael> fantasai: That's what we're trying to define here
<dael> AmeliaBR: Might be helpful to look at breaking this algo to more detail. It's true that there are very simple cases wher eyou gave explicit grid-row height and you want grid items with aspect ratios to fill explicit dimension and auto-size in other and that should happen automatically
<dael> AmeliaBR: Rossen_ concern about what if you have rows dependent on parents and other children and how to define non-circular I think there will be using the existing grid text and text with flexbox and aspect ratio where we redefined...
<dael> AmeliaBR: I suspect we have necessary sub algo defined
<dael> fantasai: We do this for the orthogonal dimension. If the avialable space when sizing a grid item is taken from row with constraint it looks to grid container. Just not with aspect ratio
<dael> fantasai: For aspect ratio we need to take from inline dimension and that's not designed
<fantasai> https://drafts.csswg.org/css-grid-1/#algo-overview
<fantasai> "If calculating the layout of a grid item in this step depends on the available space in the block axis, assume the available space that it would have if any row with a definite max track sizing function had that size and all other rows were infinite. If both the grid container and all tracks have definite sizes, also apply align-content to find the final effective size of any gaps spanned by such items;
<fantasai> otherwise ignore the effects of track alignment in this estimation."
<fantasai> We need to do this in the inline dimension
<dael> AmeliaBR: Are you able to break down where i all existing layout algo there would need to be new rule? THat would make it less scary
<dael> fantasai: Yes, right now depends on available space in block axis. We would address it in this section (link above) if you don't have definite row we can provide by grid container
<dael> fantasai: If people want to look more we can come back
<dael> Rossen_: Own this more thinking, it's a fundemental thing and careful what to select
<dael> Rossen_: My pushback is based on working on a lot of it and making such an exception requires adding a lot more information that needs to be kept track of and that complicates layout algo tremendiously
<dael> Rossen_: Need to see if this manifests as super common use case with adverse effects or if this is something most people won't hit.
<AmeliaBR> s/redefined.../redefined how aspect ratio boxes worked because initial behavior wasn't useful./
<dael> Rossen_: I'd prefer to let others comment, esp other people impl layout
<dael> Rossen_: That work for you fantasai ?
<AmeliaBR> ack me
<fantasai> wfm

[jensimmons]

@dholbert

[dholbert]

I need to page back in the grid layout algorithm before I can comment usefully here. CC @MatsPalmgren in case he can get to thinking through this before I do.

[MatsPalmgren]

@fantasai

The available space to a grid item when finding its max-content contribution is undefined. :(

The available space isn't a parameter when finding out the min/max-content size at all. It seems like a flawed assumption that it should be. I really don't want to introduce "available space" as a parameter to those functions.

I disagree with this edit that made it so: https://github.com/w3c/csswg-drafts/commit/c42c80f64a0fe6b1ea05678a16862eb0880b4b76

Is there a spec issue/resolution for that change?

[MatsPalmgren]

This issue could benefit from a better description of the problem it's trying to solve. It sounds like what you really want is ratio-preserving stretching, so that for example:

<div style="display:grid; grid-template-rows:200px">
  <img src="https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/reftests/w3c-css/submitted/images3/support/colors-16x8-noSize.svg">
</div>

would result in an 400x200 sized image?

Issue #523 has a useful discussion of this problem. (Note that the example above works as expected in Firefox 51 (and older), but then we changed it as a result of that issue...)

That problem can be solved with align-self:stretch-with-ratio or height:contain or something. I don't think we need to mess with intrinsic sizes to solve this.

[fantasai]

@MatsPalmgren The calculation of the size for images with an aspect ratio and no intrinsic size is noted in https://www.w3.org/TR/CSS2/visudet.html#inline-replaced-width so we just followed that rule when drafting css-sizing-3.

This issue could benefit from a better description of the problem it's trying to solve.

I think the summary is pretty clear: we've got a case where the result is undefined, so we have to define the behavior.

[tabatkins]

Comment for future Tab and fantasai: There's some interop here, but not fully, and we have a mix of the behaviors described here, with more interop on what's described in this issue than not. We need to write up the relevant test cases and figure out spec text to describe this behavior.