Can anyone explain why the following website displays differently on latest Chrome vs Firefox (and how to avoid it)?
The issue is with the image overflowing it’s container on Chrome but not on Firefox.
Try to resize the output in the following JSBin on both browsers to see the symptom.
JSBin: https://jsbin.com/wimozijije/edit?html,css,output
Thanks for your help in advance.
Hi @haykerman, and welcome to the community!
There is a difference in between how the two browsers are interpreting the max-block-size property on that container image. Firefox seems to be respecting it, but Chrome is not.
But, the thing is is that max-block-size is based off of the current writing-mode property. It doesn’t make sense to use a property that is tied in with text for an image. I would suggest refactoring how that image is displayed with different properties such that it isn’t using something that is depending on text modes for it to render correctly.
Thanks for your answer, @marcusparsons! Could you, please, elaborate more on the following:
It doesn’t make sense to use a property that is tied in with text for an image
And what do you think about this paragraph from the MDN web docs.
Overall, I think of properties that have block/inline in their name as a more responsive/accessible replacement for height/width and in some cases padding/margin. Am I wrong in that assumption?
Also, changing logical properties to regular ones (e.g. max-block-size to max-height) doesn’t seem to fix the issue.
For the most part, you’re right. But specifically, that max-block-size property is tied in to the writing mode on the page.
I don’t use CSS grid myself, so my assumption is that it also has to do with you declaring the container as grid. But, I put the padding into the container, where it should be, and I swapped it to use a Flexbox display and changed those max-block-size and max-inline-size and it now scales up and down properly on both Chrome and Firefox.
I made a CodePen for what I came up with. I only changed the bottom two selectors.
I apologize, perhaps I should’ve been more explicit with my question. I sure CAN make it work using flexbox and various methods (that said, thanks for writing a working clone). But I wan’t to solve this exact particular case (with grid and logical properties). I’ll update the question.
Nothing (to my knowledge) seems to point out the way I’ve written my CSS would turn
out being laid out incorrectly in Chrome, while it works perfectly in Firefox. And also I don’t see why being tied to writing mode for images is problematic? I want the writing-mode selection to be reflected on all elements (both block and inline).
Can I Use says that both browsers support those logical properties. I’ve gone as far as copying both browsers user-agent stylesheets and inspecting differences (though I haven’t found anything that would result in this mismatch yet, but I’m still looking).
I’m guessing it is a bug or inconsistency with replacement elements (or just images) as grid items. It doesn’t seem related to the logical properties as it doesn’t even work with just height/width.
Setting grid-template-rows: 100% on the grid container seems to fix it (I think).
There is nothing wrong with using the logical properties for this, it should compute to the same as max/min width/height.
What I’ve found so far is Chrome sets “overflow-x” to “clip” on that image element. If I change “overflow-x” to “auto” (or even “hidden”) the img starts to scale with container and doesn’t overflow, as originally expected.
Yes, did not think the logical properties were affecting the result in any way.
I’ve reported this behavior as a Chrome bug. Waiting to see what happens next.
Adding the min sizes also seems to fix it.
section.container img {
display: block;
object-fit: contain;
padding: 4rem;
max-block-size: 100%;
max-inline-size: 100%;
min-block-size: 100%;
min-inline-size: 100%;
}
I found this issue but I haven’t read it. There might be some information or it might be completely unrelated.
It often comes down to how the vendors interpret the specs or if the specs are vague they implement their own interpretation of it. For all we know it is Firefox that is not spec-compliant, although its behavior is more like what you would expect.
Yeah, there are of course multiple potential fixes e.g. setting min h and w, setting overflow: hidden;, using flex instead of grid. It’s just strange that grid’s output is not like one would expect it to be.
By the way, I’ve reported a Chrome bug. You can find it by the following id: 1503924. Someone said they were able to reproduce it.
@lasjorg @marcusparsons They’ve marked the bug I’ve opened as wontfix and gave an unhelpful/dissatisfying explanation:
Thanks for the bug report - this is unfortunately two separate bugs in Webkit & Gecko which results in this difference. A mitigation you might be able to apply is add:
min-width: 0; min-height: 0
to the image element.
Thanks,
Ian
Find more details by searching by the following chromium issue number: 1503924
I guess this means we’re stuck using flexbox for this kind of layout if we want our code to be reflective of reality.
The alternative is applying the suggested and other hacks which makes it hard to understand why it was mandatory to specify those properties when later you (or teammates) read the code.
I don’t know what part of the specs to look at.
6.6. Automatic Minimum Size of Grid Items
But I find it odd the way the child is calculating its dimensions based on the parent size. If I set the parent to be 400px in height and the child to be height 50% the child is 200px. But If I set the child to height 100% it doesn’t work and overflow the parent container.
Hmm, I think (and most probably) the spec is fine. I’ve skimmed through it, didn’t find anything that could cause the bug.
It’s more likely that browsers are not fully spec-compliant. Hence the layout issue.
I’m saying I don’t know what part of the specs the two engines referred to in the issue are not compliant with.
I’m still not sure why, in Chrome, the child can compute 50% height of the parent dimensions but not 100%. If that is spec-compliant, I find it odd.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.