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