grid-row-end CSS property does not behave correctly when set to -1
Categories
(Core :: Layout: Grid, defect, P3)
Tracking
()
People
(Reporter: cybeatb, Unassigned)
References
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:129.0) Gecko/20100101 Firefox/129.0
Steps to reproduce:
I am testing a work-in-progress website, which contains a grid layout.
I set the grid-row-end property of a grid cell to -1.
A minimal demonstrative example is attached.
Actual results:
The grid cell did not correctly span the rest of the column.
Expected results:
The grid cell should have spanned the entire column.
|
||
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout: Grid' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•1 year ago
|
||
I think the main issue is that the grid-template-rows: repeat(auto-fit, minmax(0, max-content)); doesn't specify a fixed number of rows... this is the relevant code, do you know whether we get the explicit grid end correct here?
I'm not entirely sure what that means.
I noticed this behaviour when I tried to transpose a similar setup, where the large grid cell spans an undefined number of small columns.
(Example attached.)
|
||
Comment 4•1 year ago
|
||
I haven't looked into the code or spec yet. However, for the testcase in comment 0, first "This Is Incorrect Behaviour" grid container looks the same on Firefox, Google Chrome and Safari.
For the testcase in comment 3, Firefox and Safari have similar rendering, where Google Chrome behaves differently.
|
||
Comment 5•1 year ago
•
|
||
Hi cybeatb -- so it's a bit hard to reason about this-as-a-bug because it's not clear if any browser matches your expected results (do they?)
But, if I understand you correctly: I think you're wondering why cell a is so large in the top half of the testcase in comment 0 -- you're wondering why that cell looks different from the bottom half of testcase 0, and why it doesn't match the (inverted) version in comment 3 where Firefox and Safari size it to itself. Is that right?
If I'm understanding you correctly: this is a version of the same question that someone else recently filed as bug 1917142. Basically, the sizing of that cell is reliant on how many tracks your auto-fit expression expands to; and auto-fill and auto-fit don't do much of anything in grid-template-rows unless you have a defined size in that axis (a defined height or min-height in this case). In the top half of your comment 0 testcase, your repeat(auto-fit...) expression just expands to a single iteration, without any actual repeats. (And that is correct, per the spec, even if it's not what you expect.)
This is indeed an asymmetry where things work differently in the row axis vs. the column axis -- this is due to the order in which sizes are resolved in web layout (inline sizes [typically widths] get resolved first, before the content is fully laid out; block-sizes [typically heights] get resolved last, after the layout finishes). This means that things like percentages and auto-fit can be resolved in the inline axis (for width & columns) in more cases than they can be resolved in the block axis (for height and rows). Here's a simple analogous example with a 50% width and height on a div inside of a content-sized parent; the inner div's width resolves "correctly" but its height falls back to auto because we can't resolve it.
data:text/html,<!DOCTYPE html><div style="float:left; border: 1px solid black"><div style="width: 50%; height: 50%; background: orange">Does the 50-percent resolve in both axes here?
In the same way that this testcase can resolve a percent in one axis but not the other (because we can pre-compute the constraint size that it resolves against in only one axis): in your testcases, we can resolve auto-fit in one axis but not the other (because we can pre-compute the constraint size that it repeats-to-fill in only one axis).
See bug 1917142 comment 5 through bug 1917142 comment 7 for more on the details here. In the meantime, unless some other browser is doing this in-the-way-that-you-expect (please let us know if so!), I think this is invalid since we [and others] are matching the spec.
Description
•