[css-grid] Note implies losing an aspect-ratio when it shouldn't?

[bfgeek]

https://drafts.csswg.org/css-grid-1/#grid-item-sizing

There is a note which says "Note: This can distort the aspect ratio of the item, if it has one."

This implies that if there is 'stretch' in one dimension, it should distort the image. This note should probably say something along the lines of "Note: This can distort the aspect ratio of the item, if it has stretch in both axes." or something.

Testcase: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=8675

[bfgeek]

cc/ @fantasai @tabatkins

[Loirooriol]

Not sure if I'm missing something, but your testcase only has stretch in a single axis, and the aspect ratio is distorted in all Chromium, WebKit and Firefox. So the current spec matches implementations.

[bfgeek]

@Loirooriol - I think what's happened is that folks took the note too literally (and normatively). FWIW this now doesn't match what happens with flex:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=8676
(requires Chrome Canary, and recent version of Firefox).

[Loirooriol]

It's not just the note, though. The spec text says

Use the inline size calculation rules for non-replaced boxes (defined in CSS 2 §10.3.3 Block-level, non-replaced elements in normal flow).

where CSS 2 §10.3.3 basically ignores aspect ratios. So it's not clear to me that the spec had a different intention.

Also see #5615

[Loirooriol]

Regarding consistency with flex, I don't think your testcase is testing the proper thing. The flex item is effectively stretched in the cross axis, it's just that it's not stretched in the main axis because justify-self doesn't apply, so the aspect ratio is preserved.

The interesting testcase would be https://software.hixie.ch/utilities/js/live-dom-viewer/saved/8677

In latest Chromium with experimental flags, the grid item and the flex item are identical (aspect-ratio has no effect). But if I apply https://chromium-review.googlesource.com/c/chromium/src/+/2526928, they are different:

vs

[fantasai]

@Loirooriol “Use the inline size calculation rules for non-replaced boxes” is supposed to apply to the sizing in the relevant axis, not in both axes, though.

I agree with @bfgeek, the behavior here seems quite wrong.

[bfgeek]

Implementations also seem to have bugs when determining track contributions, e.g.
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=8681
(currently an unstable layout in chrome).

I'm planning on doing some implementation work in this area - and will add some .tentative tests referring to this issue.

[Loirooriol]

OK, so I think

• If both axes have stretch alignment with auto sizes, both should be stretched, likely distorting the aspect ratio.
• If one axis has stretch with auto size and the other has a definite size, the former should be stretched and the latter should use the definite size, likely distorting the aspect ratio. This matches flexbox and implementations.
• If one axis has stretch with auto size and the other has non-stretch alignment with auto size, the former should be stretched. I'm fine with making the latter resolve to the stretched size converted through the aspect ratio, matching flexbox. But note it's not what implementations currently do.

[bfgeek]

The only concern I have is for the following case:

<div style="display: block; width: 200px; border: solid;">
  <div style="height: 100px; aspect-ratio: 1/1;"></div>
</div>

<div style="display: grid; width: 200px; border: solid;">
  <div style="height: 100px; aspect-ratio: 1/1;"></div>
</div>

Conceptually these cases are the same, both make 'auto' "stretch" in the inline-axis, and definite height in the block-axis, and an aspect-ratio.

[Loirooriol]

@bfgeek In that case the elements have justify-self: normal, so I think

• For the grid item, the width is "as for a block-level box" [1] and "as for a replaced element" [2]. That is, CSS 2 §10.3.4, which will respect the aspect ratio and the width will be 100px.
• For the block box, justify-self: normal theoretically behaves as stretch [3], but I think CSS Align is wrong here, since replaced block elements are not stretched. I think that due to aspect ratio it should be sized as a replaced element, resulting in CSS 2 §10.3.4 again.

But if they had justify-self: stretch, then

• Per [4], the grid item would explicitly use CSS 2 §10.3.3, resulting in a width of 200px, ignoring the aspect ratio.
• Per [5], the block box would be sized "to the length necessary to make its outer size as close to filling the alignment container as possible", which I guess maps to CSS 2 §10.3.3 too.

[bfgeek]

For the block box, justify-self: normal theoretically behaves as stretch [3], but I think CSS Align is wrong here, since replaced block elements are not stretched.

It's correct for non-replaced elements. Which stretch be default. That line should probably read:

normal Behavior | Behaves as stretch except for replaced elements, tables, and some form controls which are start.
(or something).

But if they had justify-self: stretch

I'm not sure we should make a distinction between justify-self: stretch , and justify-self: normal.

[Loirooriol]

I'm not sure we should make a distinction between justify-self: stretch, and justify-self: normal.

What's the point of having them as different values, then?

[Loirooriol]

cc/ @BorisChiou

[bfgeek]

What's the point of having them as different values, then?

My answer would be - for the default behaviour switch between replaced and non-replaced elements.

So there are two clear options here.

1. Define a "strong" stretch, and a "weak" stretch. E.g. if you have justify-self: stretch this is a "strong" stretch, justify-self: normal is a "weak" stretch. The priority list for this would be something like:

• "weak" stretch alignment.
• aspect-ratio transferred size.
• "strong" stretch alignment.
• definite size.

2. Define an aspect-ratio transferred size as have higher priority than stretch alignment, e.g.

• stretch alignment.
• aspect-ratio transferred size.
• definite size.

I prefer (2) as I somewhat view a aspect-ratio with a definite size in the opposite axis the same as, a definite size in the original axis.

@fantasai any thoughts?

[Loirooriol]

But with (2), how would you treat an element with aspect-ratio but stretch alignment in both axes?

CSS Grid makes it clear that then the aspect ratio will probably be distorted, we have interoperability, and being able to opt out the ratio seems useful for authors. So if stretch has precedence over the aspect ratio when specified in both axis, it seems more consistent to me if it also takes precedence when specified in a single axis. That's why I prefer (1).

[bfgeek]

But with (2), how would you treat an element with aspect-ratio but stretch alignment in both axes?

Both "win" it gets distorted.

Here both the inline-axis, and block-axis are stretched. So the default axis "wins" resulting in the image being distorted. The "full" priority list for (2) would be:

• intrinsic size.
• transferred (by aspect-ratio) stretch alignment.
• stretch alignment.
• transferred (by aspect-ratio) definite size.
• definite size.

[Loirooriol]

IMO option (1) looks simpler this way:

1. alignment:
   • if stretch, or normal behaving as stretch: stretch.
   • otherwise:
     1. intrinsic size.
     2. transferred (by aspect-ratio) stretch alignment.
     3. transferred (by aspect-ratio) definite size.
2. definite size.

[bfgeek]

I don't think your definition of (1) satisfies this case:

<div style="display: block; width: 200px; border: solid;">
  <div style="height: 100px; aspect-ratio: 1/1;"></div>
</div>

As here justify-self: normal is stretch per implementations (and https://drafts.csswg.org/css-align/#justify-block). Although as discussed this definition is incomplete due to not saying that tables, replaced, and some form controls should be start

[Loirooriol]

But in that case justify-self: normal shouldn't behave as stretch. https://drafts.csswg.org/css-align/#justify-block is wrong, as you say it should exclude replaced elements (and others), and elements with aspect-ratio are sized as replaced, so they should be excluded too. Then the width would be 100px, not stretched, matching Nightly and Canary with aspect-ratio enabled.

[bfgeek]

For more clarity, when a width/height is 'auto' there are (at the moment) only two options, either:
a) stretch
b) fit-content aka. shrink-to-fit

Currently replaced, and non-replaced elements in grid, and block layout behave the same way by default.

[bfgeek]

But in that case justify-self: normal shouldn't behave as stretch.

How does target end up at 200px wide if it isn't stretching?

<div style="display: block; width: 200px; border: solid;">
  <div id="target" style=""></div>
</div>

[bfgeek]

and elements with aspect-ratio are sized as replaced, so they should be excluded too.

Ok so this is where we disagree and is an interesting point, I believe that we've been working under the assumption that applying an aspect-ratio to a non-replaced element, doesn't make it replaced. As this has a different set of sizing constraints that would be bad for most things.

[bfgeek]

E.g. from: https://drafts.csswg.org/css-sizing-4/#aspect-ratio

"Note: Having a preferred aspect ratio does not make a box into a replaced element; layout rules specific to replaced elements do not generally apply to non-replaced boxes with a preferred aspect ratio. "

[Loirooriol]

Yes, in that other case it doesn't have a preferred aspect ratio, it's not replaced, it's not a table, etc. Then normal behaves as stretch indeed.

applying an aspect-ratio to a non-replaced element, doesn't make it replaced

Doesn't make it completely replaced, but https://drafts.csswg.org/css-sizing-4/#aspect-ratio-automatic says

When a box has a preferred aspect ratio, its automatic sizes are calculated the same as for a replaced element with an intrinsic aspect ratio and no intrinsic dimension in that axis

[bfgeek]

So if we change how we interpret the justify-self: normal rule to not stretch if things have an aspect-ratio, this will mean that:

<div style="width: 100px; border: solid;">
  <div style="aspect-ratio: 1/1; background: green;">

...will result in a 0x0 div which I don't think is desired.

[Loirooriol]

I think in that case the stretching is not because of justify-self: normal. It's just that the fit-content size, according to https://drafts.csswg.org/css-sizing/#intrinsic-sizes,

For boxes with a preferred aspect ratio, but no intrinsic size:
If the available space is definite in the inline axis, use the stretch fit into that size for the inline size and calculate the block size using the aspect ratio.

Browsers already do this for

<div style="display: grid; width: 100px; border: solid;">
  <svg viewBox="0 0 1 1" style="background: green; justify-self: start; align-self: start">

which has start alignment instead of normal, this shows the stretching is not due to normal behaving as stretch.

[bfgeek]

My example has an intrinsic size, it's just [0, 0]. SVGs are special as they can have no intrinsic size as you describe.