Skip to content

[css-grid-2] Inconsistent min/max-content contribution for images that failed to load #11806

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
gitspeaks opened this issue Mar 2, 2025 · 9 comments
Closed

[css-grid-2] Inconsistent min/max-content contribution for images that failed to load #11806

gitspeaks opened this issue Mar 2, 2025 · 9 comments
Labels
Closed Rejected as OutOfScope

Comments

@gitspeaks
Copy link

gitspeaks commented Mar 2, 2025 •
edited
Loading

There is an inconsistency in how browsers handle min-content / max-content contribution of images that fail to load within a CSS Grid.

Test Case:

<!DOCTYPE html>
<div style="display: grid; grid-template-columns: min-content max-content auto; grid-template-rows: min-content max-content;">
  <div style="background: lightblue">unbreakable</div>
  <div style="background: lightgreen">this is a long sentence</div>
  <div style="background: lightcoral"><img src="image.jpg" style="min-width: 150px; width: 300px" /></div>
  <div style="background: lightyellow">short</div>
  <div style="background: lightpink">text content</div>
  <div style="background: lightgray"><img src="tall.jpg" style="min-height: 200px; height: 400px" /></div>
</div>

Firefox

Expected behavior based on CSS 2 Spec 10.6.2 and 10.3.2:

  1. Row 1 Height / (min-content row including failed image) / Image Height
    • Expected: 150px (default fallback size for failed images).
    • Actual: 300px (unexpected expansion).
  2. Image Width in Row 2 / Column 3
    • Expected: 300px (default fallback width for failed images).
    • Actual: 400px (unexpected increase).

Image

Chrome

  1. Row 1 Height (min-content row including failed image)
    • Expected: 150px.
    • Actual: 16px (unexpected collapse).
  2. Image Width in Row 1 / Column 3
    • Expected: 300px.
    • Actual: 16px (unexpected collapse).
  3. Row 2 Height (max-content row including failed image)
    • Expected: 400px.
    • Actual: 200px (unexpected collapse).
  4. Image Width in Row 2 / Column 3
    • Expected: 300px.
    • Actual: 16px (unexpected collapse).

Image
@Loirooriol
Copy link
Contributor

Not related to grid at all. In fact this seems rather under the scope of https://html.spec.whatwg.org/multipage/rendering.html#images-3 rather than CSS.

<!DOCTYPE html>
<img src="about:invalid" style="min-width: 150px; width: 300px; border: solid">
Gecko Blink WebKit

Since the element has no alt attribute, HTML says to treat it as replaced.

Therefore, Blink is wrong to ignore width just because it has display: inline. It doesn't ignore min-width, so it's quite weird.

Gecko and WebKit apply a natural aspect ratio of 1. HTML should probably clarify whether "treat the element as a replaced element" uses any natural sizes or ratio.

@gitspeaks
Copy link
Author

Gecko and WebKit apply a natural aspect ratio of 1. HTML should probably clarify whether "treat the element as a replaced element" uses any natural sizes or ratio.

Why? The spec already defines how to handle replaced inline elements with height: auto and no specified aspect ratio—the default is 2:1.

Therefore, Blink is wrong to ignore width just because it has display: inline. It doesn't ignore min-width, so it's quite weird.

But why does Chrome set the height of Row 2 to 200px instead of 400px?

@Loirooriol
Copy link
Contributor

Why?

Don't ask me, I'm just describing what I see. Again, CSS can handle replaced elements with and without a natural ratio. It's just a matter of what HTML wants to do.

But why does Chrome set the height of Row 2 to 200px instead of 400px?

As I said, it seems a clear bug: it ignores height because of display: inline, even though the element is replaced so it shouldn't be ignored. And ignoring height but not min-height isn't even self-consistent.

@gitspeaks
Copy link
Author

gitspeaks commented Mar 4, 2025 •
edited
Loading

CSS can handle replaced elements with and without a natural ratio. It's just a matter of what HTML wants to do.

Could you clarify what you mean by that? From what I understand, 10.6.2 clearly explains how to size the image in row 1, so I’d expect Firefox to follow that and set the height to 150px based on a 2:1 ratio. But it sounds like you’re saying HTML is the reason a 1:1 ratio is used. Why is that?

Why don’t you think this is a Firefox bug?

@Loirooriol
Copy link
Contributor

I never said that Firefox is right. HTML just says to treat as a replaced element. Replaced elements can have natural sizes and/or natural aspect ratio. HTML doesn't say whether the replaced element has them or not. Can we then infer that there is no natural aspect ratio? Not completely clear.

Also, you keep saying that the natural ratio defaults to 2/1. That's not true, you can have SVGs which have no natural ratio.

@gitspeaks
Copy link
Author

gitspeaks commented Mar 4, 2025 •
edited
Loading

Since we already have width: 300px on the img, doesn't that mean we're setting a specific width with height set to auto? That means, per the spec, if height is auto and none of the special conditions apply, the height is computed as the largest rectangle with a 2:1 ratio that doesn't go over 150px in height or exceed the device width.

So, why worry about what HTML says about an element’s natural sizes or aspect ratio when we’ve already got all the details: a) it's a replaced element, b) it has a preferred width, and c) there's a default behavior for height when the aspect ratio is missing (since there's no actual image)?

the spec states:

Otherwise, if height has a computed value of auto, but none of the conditions above are met, then the used value of height must be set to the height of the largest rectangle that has a 2:1 ratio, has a height not greater than 150px, and has a width not greater than the device width.

@Loirooriol
Copy link
Contributor

we’ve already got all the details

We do NOT have the details about "none of the conditions above are met".

There is no 2/1 ratio here:

<!DOCTYPE html>
<svg style="width: 100px; height: auto; border: solid"></svg>
<svg style="width: 200px; height: auto; border: solid"></svg>
<svg style="width: 300px; height: auto; border: solid"></svg>
<svg style="width: 400px; height: auto; border: solid"></svg>

@gitspeaks
Copy link
Author

I'm not disputing the results; I just don't understand why you say:

We do NOT have the details about 'none of the conditions above are met.'

As far as I can tell, browsers don’t follow the spec in this case for SVG either."

@gitspeaks
Copy link
Author

gitspeaks commented Mar 5, 2025 •
edited
Loading

Had there been any default aspect ratio for SVG, we would surely get different heights. In that case, the 'none of the conditions above are met' scenario would indeed not apply—but that's not what we're seeing here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed Rejected as OutOfScope
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Loirooriol @gitspeaks