Closed
Bug 1248374
Opened 10 years ago
Closed 9 years ago
[css-grid] Weird behavior with repeat(auto-fill,) and grid-auto-flow: column
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
DUPLICATE
of bug 1280798
People
(Reporter: svillar, Unassigned)
Details
(Keywords: testcase)
Attachments
(3 files, 2 obsolete files)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/602.1 (KHTML, like Gecko) Version/8.0 Safari/602.1 Debian/buildd-unstable (3.18.3-1) Epiphany/3.18.3
Steps to reproduce:
Load the attached file.
Actual results:
The two grids are different, the one with <auto-repeat> is wider than the one using a fixed number of repetitions despite both having the same number of rows.
Expected results:
The 2 grids should be equivalent.
Note: it works fine with grid-auto-flow:row;
|
||
Comment 1•10 years ago
|
||
> The two grids are different
There is only one grid in the attached testcase, and it has (default) 'grid-auto-flow' (row).
Can you attach a new testcase that actually demonstrates the problem? Thanks.
Flags: needinfo?(svillar)
|
Reporter | |
Comment 2•10 years ago
|
||
Attachment #8719462 -
Attachment is obsolete: true
Flags: needinfo?(svillar)
|
|
Reporter | |
Comment 3•10 years ago
|
||
(In reply to Mats Palmgren (:mats) from comment #1)
> > The two grids are different
>
> There is only one grid in the attached testcase, and it has (default)
> 'grid-auto-flow' (row).
> Can you attach a new testcase that actually demonstrates the problem?
> Thanks.
Beh, I attached another file with the same name than the one I really wanted to upload :/. I've just uploaded the good one.
|
|
||
Comment 4•10 years ago
|
||
Here's a slightly reduced testcase. This is what happens when we layout
this content. Given that the grid container has float:left, the first
thing that happens is that its parent (<body>) asks for its intrinsic
inline size. This is calculated to 22px, i.e. two columns. This is
because during intrinsic sizing the explicit height:100px is not taken
into account. I think this is correct per the css-sizing spec:
https://drafts.csswg.org/css-sizing/#inline-intrinsic
"The min-content size of a box is the size it would have as an
auto-sized float in a zero-sized containing block. (In other words,
the minimum size it has when sized as shrink-to-fit.)"
(Note the "auto-sized" there)
When the height is indefinite (auto) the Grid spec says that auto-fill
results in one track:
https://drafts.csswg.org/css-grid/#valdef-repeat-auto-fill
And with only one row, the placement results in two columns, hence
the intrinsic inline size (shrink-to-fit width) is 22px.
Now, when we flow this grid container the 'height:100px' affects
the auto-fill and results in a number of rows so the second item is
now placed in the second row. This doesn't affect the grid container's
width though which has already been determined.
AFAICT, we layout this testcase correctly per spec(s).
Attachment #8719687 -
Attachment is obsolete: true
|
|
||
Comment 5•10 years ago
|
||
For comparison, here's the same test with height:auto.
|
|
Reporter | |
Comment 6•10 years ago
|
||
(In reply to Mats Palmgren (:mats) from comment #4)
> Created attachment 8719820 [details]
> Reduced testcase
>
> Here's a slightly reduced testcase. This is what happens when we layout
> this content. Given that the grid container has float:left, the first
> thing that happens is that its parent (<body>) asks for its intrinsic
> inline size. This is calculated to 22px, i.e. two columns. This is
> because during intrinsic sizing the explicit height:100px is not taken
> into account. I think this is correct per the css-sizing spec:
> https://drafts.csswg.org/css-sizing/#inline-intrinsic
> "The min-content size of a box is the size it would have as an
> auto-sized float in a zero-sized containing block. (In other words,
> the minimum size it has when sized as shrink-to-fit.)"
> (Note the "auto-sized" there)
>
> When the height is indefinite (auto) the Grid spec says that auto-fill
> results in one track:
> https://drafts.csswg.org/css-grid/#valdef-repeat-auto-fill
>
> And with only one row, the placement results in two columns, hence
> the intrinsic inline size (shrink-to-fit width) is 22px.
>
> Now, when we flow this grid container the 'height:100px' affects
> the auto-fill and results in a number of rows so the second item is
> now placed in the second row. This doesn't affect the grid container's
> width though which has already been determined.
>
> AFAICT, we layout this testcase correctly per spec(s).
Mats your reasoning makes a lot of sense from the spec(s) POV, but I still believe that having different results for both cases is pretty weird. Also it is far from obvious for a web developer to understand that a shrink-to-fit grid is creating an extra column (I can understand it because I'm a web engine developer but I doubt a web author could understand it).
Perhaps a question for the CSSWG?
|
|
Reporter | |
Comment 7•10 years ago
|
||
(In reply to Mats Palmgren (:mats) from comment #4)
> Created attachment 8719820 [details]
> Reduced testcase
>
> Here's a slightly reduced testcase. This is what happens when we layout
> this content. Given that the grid container has float:left, the first
> thing that happens is that its parent (<body>) asks for its intrinsic
> inline size. This is calculated to 22px, i.e. two columns. This is
> because during intrinsic sizing the explicit height:100px is not taken
> into account. I think this is correct per the css-sizing spec:
> https://drafts.csswg.org/css-sizing/#inline-intrinsic
> "The min-content size of a box is the size it would have as an
> auto-sized float in a zero-sized containing block. (In other words,
> the minimum size it has when sized as shrink-to-fit.)"
> (Note the "auto-sized" there)
BTW the link you posted does not seem to contain that text. That spec points now to css-sizing-4 https://drafts.csswg.org/css-sizing-4/#block-intrinsic while the text you mention is from css-sizing-3 https://drafts.csswg.org/css-sizing-3/#inline-intrinsic. I guess we need to clarify all this mess.
|
|
Reporter | |
Comment 8•10 years ago
|
||
So I've talked about this with fantasai during the grid layout workshop in NYC and her answer is that basically WebKit/Blink is behaving correctly. The spec you mention was just a draft not really reviewed by anyone, so don't just trust it.
The idea is what I basically said, there should be no difference between repeat(auto-fill) and repeat with the same number of repetitions as the one computed for auto-fill.
This is very interesting. As a developer, I'm definitely more supportive of Chrome's performance.
I recently also worried about how to use CSS to achieve a similar layout[1], but it is horizontal.
What do you think? Or CSS Grid can support this layout[1]?
[1] https://github.com/w3c/csswg-drafts/issues/191
|
||
Comment 10•9 years ago
|
||
This is like a waterfall flow layout.
|
|
||
Comment 11•9 years ago
|
||
We recently changed grid container intrinsic sizing so that a specified
[min-|max-][width|height] are taken into account, but only for the purpose
of calculating the number of auto-repeat tracks. So think this should be
fixed in the latest Nightly, please reopen the bug if it's not.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•