[css-sizing-3] Content contribution of min-inline-size:fit-content and max-inline-size:fit-content

bfgeek commented 3 months ago

We came across this from a bug report submitted to us, and basically it comes down to these cases:

<!DOCTYPE html>
<div style="width: fit-content; border: solid 10px;">
  <div style="max-width: fit-content; width: 100000px;">
    abc def ehg
  </div>
</div>

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

<!DOCTYPE html>
<div style="width: fit-content; border: solid 10px;">
  <div style="min-width: fit-content; width: 10px;">
    abc def ehg
  </div>
</div>

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

Basically:

For Blink - The available-size is indefinite (during the content contribution calculation) so we'll throw away the fit-content, and just treat the min-inline-size, and max-inline-size as 0, and Infinity respectively.
For Gecko - The available-size is indefinite; for the min-inline-size - fit-content becomes min-content, and for max-inline-size - fit-content becomes max-content.

Gecko's behaviour here is reasonable (at least to me), but isn't in the spec (from my reading). cc/ @tabatkins

dbaron commented 3 months ago

(See the bug report that Ian mentioned.)

dbaron commented 3 months ago

For what it's worth, the Gecko behavior dates back to the initial implementation of fit-content under the name -moz-shrink-wrap back in 2007.

dbaron commented 3 months ago

(And this behavior was in the early spec draft that I had for these values, going back to the May 2007 draft. I guess it never found its way into css-sizing, though.)

tabatkins commented 3 months ago

(I discussed this with Ian in person.)

Yeah, the Firefox behavior isn't in the spec; Chrome is more correct in ignoring the unresolvable size under the min/max size constraint.

But I think Firefox's behavior makes more sense. It's not perfect, but it seems closer to what the author would expect. I think it's safe too, in that it produces a min size that's smaller (or equal) to what the eventual "real" size is, and a max size that's larger (or equal), so you won't run into situations where the min size is larger than the eventual size or vice versa.

Loirooriol commented 1 month ago

I don't like this much, why should e.g. max-width: fit-content be like max-content instead of fitting into the container?

If we are not going to treat it as a cyclic percentage, I would rather say that fit-content:

Should behave as min-content for the purpose of computing the min-content contribution
Should behave as max-content for the purpose of computing the max-content contribution

So max-width: fit-content; width: 100000px should just behave like width: fit-content.

Servo with my patch	Gecko, Blink	WebKit

https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/13201

Source code

```html

      abc def ehg
    

      abc def ehg
    

      abc def ehg
    

```

Gecko and Blink forcing overflow when min-content wouldn't require it seems against the nature of fit-content.

Loirooriol commented 1 month ago

I guess treating max-width: fit-content as max-width: max-content follows from the fit-content formula

clamp(min-content, stretch, max-content)

if you treat an indefinite max-width: stretch as infinity. But see #11006, the spec says to treat an indefinite stretch as an automatic size.

w3c / csswg-drafts

[css-sizing-3] Content contribution of min-inline-size:fit-content and max-inline-size:fit-content #10721