Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[css-grid-1] Clarify the reason of limit the rows/cols at grid, and increase it #1009
referred spec: https://drafts.csswg.org/css-grid/#overlarge-grids
reference issues with testcases:
I file this issue for css-grid-1 whilst it is almost ready.
The situation shortly: with grid we can make masonry/pinterest style layout simply and elegantly by 1px steps.
During my user-support on several channels for front-end developers there is no day when I don't meet this question, "how to make masonry?"
The current scripts for it are brutally hardcoded, mostly use absolute positioning and recalculating everything during window-resize including the relative parent's height which is hardcoded and recalculated also.
The current issue is: UAs have limit for the maximum rows as very overlimited. (At this report day, the chromium limit is 999 and mozilla limit is 9999 for the whole grid.) Normally there is no reason for limiting except the row-spanning should cause some type of stacking problems.
My suggestion is:
For more details, please visit the referred issues above for testcases, discussions, etc.
I got partial answer for the reason which is: memory issues. This is the reason why chromium has 1000x1000 limit for rows/cols.
Suggestion: To set priority for the rows based on webusage we can use this formula:
rows = 10^X -> cols = 10^(6-X) this is correct and keeps 1million cells.
1million comes from 1000x1000 cells
On "webusage" I mean: usually we are scrolling vertically but this should work as vice-versa: if we have 4 rows only, 250000columns are allowed without truncate. That is also still in the 1million limit.
Using a many thousands of grid rows of 1px size to do this layout isn't elegant, it's an ugly hack.
The Grid spec already motivates why a limit is needed: "Since memory is limited", and I'd like to add "and since CPU resources are limited". Using millions of grid cells requires large amounts of memory and processing which creates unacceptable latency on slow devices.
I agree that the masonry use case is important though, but let's fix that in #945 in a sane way instead.
MatsPalmgren, before saying expressions: "wasteful", "junk", "ugly" just take a look at these links:
and see, how the front-end devs trying to kill their websites with these scripts:
Anyway I suggested at #945 using float: top left; instead of grid. That can be the final answer for masonry, until that grid is the simplest and fastest way to do it.
Just compare the scripts with mine. I know the answer, masonry libraries causes intristic processor-usage which is catastrophic on slow devices. Mine with grid id better. However the lazy-load always overlarge the pages, so it is always a memory issue.
In other way, on phone, for 1 column, no necessary the grid, we can disable the grid by display: block; and with it the slow decives are supported well with a mediaquery. This is elegant also. Not as these scripts do currently with full loaded absolute positioning.
That is not a question, who likes masonry and who not. We just need to handle this somehow.