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

[hunboy]

referred spec: https://drafts.csswg.org/css-grid/#overlarge-grids

reference issues with testcases:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1336679
• https://bugs.chromium.org/p/chromium/issues/detail?id=688640
• [css-grid][css-flexbox] Pinterest/Masonry style layout support #945

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.

[hunboy]

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

Sample:

• 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.

[MatsPalmgren]

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.

[svillar]

I subscribe every single word @MatsPalmgren has written

[hunboy]

MatsPalmgren, before saying expressions: "wasteful", "junk", "ugly" just take a look at these links:

• http://getbootstrap.com/components/#thumbnails

and see, how the front-end devs trying to kill their websites with these scripts:

• http://masonry.desandro.com/
• http://isotope.metafizzy.co/
• http://salvattore.com/

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.

[tabatkins]

I just added a tracking issue for this to Grid 2

[yairopro]

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?