Skip to content
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.

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

[css-grid-1] Clarify the reason of limit the rows/cols at grid, and increase it #1009

hunboy opened this issue Feb 6, 2017 · 6 comments


None yet
7 participants
Copy link

commented Feb 6, 2017

referred spec:

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.

Now with grid it is possible with only 1 hardcoded value - which is the image height - and setting up grid-row-end: span ...px;. After this, it is a constant and doesn't change anymore mormally. Now we can set up with mediaqueries grid-template-columns: repeat(colnumber, 300px); and it reflows easily to a different columns without hardcoded recalculations during resize the window. This is a really pretty and elegant way for masonry with a minimum javascript, which one runs only once.

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:

  • use limit for row-span (if it is necessary) I say 9999 instead of the whole grid and keep the grid flowing as "unlimited".
  • add 1 new value for grid-row-end: span available; for those layouts, where someone wants 1 column crossflowing on the whole grid without limit.

For more details, please visit the referred issues above for testcases, discussions, etc.
I think, limiting the spans is the better way than limiting the whole grid.


This comment has been minimized.

Copy link

commented Feb 6, 2017

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


  • With this formula we can make 250000rows x 4 cols grid which is still inside the 1million cells limit.
  • Based on row-prority when we add 1 more row, the overlarge algorythm fires and truncates the cols to 3. and so on: at 333334 rows it truncates to 2 cols.

If this is acceptable by UAs it should be a usable and fast and responsive masonry with minimum javascript.

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.


This comment has been minimized.

Copy link

commented Feb 7, 2017

with grid we can make masonry/pinterest style layout simply and elegantly by 1px steps.

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.


This comment has been minimized.

Copy link

commented Feb 7, 2017

I subscribe every single word @MatsPalmgren has written


This comment has been minimized.

Copy link

commented Feb 7, 2017

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:

Note that, from Einstein everything is relative :) so we just want replace these scripts with some really simple code, which one is currently the grid itself. Based on these libraries, the grid way with one script-running mechanism, based on load event handler, it is reallly ELEGANT and responsive via css, no javascript for responsiveness is necessary.

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.


This comment has been minimized.

Copy link

commented Mar 30, 2017

I just added a tracking issue for this to Grid 2

@tabatkins tabatkins closed this Mar 30, 2017

@atanassov atanassov removed the Agenda+ label Apr 11, 2017


This comment has been minimized.

Copy link

commented Dec 17, 2017

Here's a JSBin that shows what @hunboy talked about. Once I made it, I realized that the grid was limited. Then I've found this issue.
Any news?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.