Re: [csswg-drafts] [css-flexbox] Change content-size suggestion to min-intrinsic instead of min-content? (#6794)

Before we dig into the non-replaced case, let's review what happens with replaced elements. Consider an SVG flex item with an aspect ratio and no natural size (the model for our non-replaced aspect-ratio boxes):

```
<div style="border: solid; display: flex; width: 200px; height: 100px">
  <img src="https://xanthir.com/circle" style="flex-grow: 1">
</div>
```

In this case, browsers agree: because the cross-size is definite, the hypothetical size of the flex item is 100x100; and being flexible, its final size is 200x100.


```
<div style="border: solid; display: flex; width: 10px; height: 100px">
  <img src="https://xanthir.com/circle" style="flex-grow: 1">
</div>
```

In this case, browsers agree that because the cross-size is definite, the hypothetical size of the flex item is 100x100.

However, browsers disagree on its automatic minimum size:
- In Firefox, the content size suggestion is the natural size of the image (zero), yielding a final size of 10x100. In other words, it uses min-intrinsic for the content size suggestion.
- In Chrome, the content size suggestion applies the transferred size (100px), yielding a final size of 100x100. In other words, it uses min-content for the content size suggestion.

You can see this more precisely in the following testcase, where we give the SVG a natural size of 20px:

```
<div style="border: solid; display: flex; width: 10px; height: 100px">
  <img src="https://xanthir.com/circle20" style="flex-grow: 1">
</div>
```

- In Firefox, the content size suggestion is the natural size of the image (20px), yielding a final size of 20x100.
- In Chrome, the content size suggestion applies the transferred size (100px), again yielding a final size of 100x100.

As outlined in https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-1063323692 @tabatkins and I believe Firefox's interpretation is the one originally intended, and is the correct behavior.

<hr>

Now let's consider non-replaced elements...

For non-replaced elements, we consider the intrinsic size of their contents to be more significant than the natural sizes of a replaced elements, and give them the power to break the aspect ratio. (For example, in Block layout, the min-intrinsic size of a non-replaced box can influence the automatic minimum size to exceed the transferred size.) For this reason, we excluded non-replaced elements from the clause that gives transferred sizes the power to clamp a content size suggestion, i.e. the clause that applies automin = min(transferred, content): because in Block layout, the content size suggestion is stronger.

We then considered what influence the transferred size should have on the automatic minimum size. If it's not clamping the content size suggestion (min-intrinsic size), then the other two possibilities are:
- ignore the transferred size, and rely on preferred sizing to effect the aspect ratio
- set the automatic minimum to the max of the transferred size and the intrinsic size

We decided to take the first option, because the goal of the automatic minimum size is to be an unobtrusive safety net, not to effect a preferred size.

Consider the following testcase, where the content is larger than the transferred size:

```
<div style="border: solid; display: flex; width: 10px; height: 100px">
  <div style="flex-grow: 1; font-size: 150px">XXX</div>
</div>
```

In this case, browsers agree that because the cross-size is definite, the hypothetical size of the flex item is 100x100.

However, browsers disagree on its automatic minimum size:
- In Firefox, the content size suggestion is the intrinsic size of the content (150px) and the transferred size suggestion is not used, yielding a final size of 150x100.
- In Chrome, the content size suggestion applies the transferred size (100px), yielding a final size of 100x100.

We believe Firefox's behavior is what was originally intended, matching our rationale above.

We can also consider the following testcase, where the content is smaller than the transferred size:

```
<div style="border: solid; display: flex; width: 10px; height: 100px">
  <div style="flex-grow: 1"></div>
</div>
```

In this case, browsers agree on a final size of 10x100. If we went with the “non-replaced items use max(transferred size, content size)” for the automatic minimum size, this example would instead yield 100x100.

<hr>

> Will `content size suggestion` still transfer definite min/max cross sizes through the aspect ratio? I.e. are the bold parts in the below definition to be removed or kept?
> 
> > The content size suggestion is the [min-content size](https://drafts.csswg.org/css-sizing-3/#min-content) in the [main axis](https://drafts.csswg.org/css-flexbox/#main-axis), **clamped, if it has a [preferred aspect ratio](https://drafts.csswg.org/css-sizing-4/#preferred-aspect-ratio), by any [definite](https://drafts.csswg.org/css-flexbox/#definite) [minimum](https://drafts.csswg.org/css-sizing-3/#min-width) and [maximum](https://drafts.csswg.org/css-sizing-3/#max-width) [cross sizes](https://drafts.csswg.org/css-flexbox/#cross-size) converted through the aspect ratio.**

That clause exists to ensure that, for example, a 100x100 image with an auto width but a max-height of 10px is given an automatic minimum size of 10px, not 100px; and conversely, a 10x10 image with an auto width but a min-height of 100px is given a automatic minimum size of 100px, not 10px.

For non-replaced elements, we should probably transfer the minimum, but not the maximum--not transferring the maximum because, as we've established, we intend for the automatic minimum size of a non-replaced element with an aspect ratio to break the aspect ratio if that's necessary to fit the content. If the author wants the aspect ratio to take precedence over the min-content size, then they can set `min-width` to zero.



-- 
GitHub Notification of comment by fantasai
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-1218597495 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 17 August 2022 23:04:39 UTC