On this testcase clearly visible, if grid doesn't allow more than 10000 lines: https://jsfiddle.net/utasir/0jcrxm45/2/ This is problematic when we use it for masonry layout, it is cut off at the end: https://jsfiddle.net/utasir/0yp0o80z/9/
This is by design and not really a bug. The behavior is described in 5.3: https://drafts.csswg.org/css-grid/#overlarge-grids I guess we can consider increasing the limit if this becomes a problem on real web sites.
Severity: normal → enhancement
Priority: -- → P5
Summary: [css-grid] Increase the number of grid-rows → [css-grid] Increase the maximum line number limit
Created attachment 8833796 [details] Testcase - lazy load masonry/pinterest gallery Mats, I've prepared a "real" website, with real picturesizes. The picture-width is 300px, compatible to a mobile deviceWidth, and we have 3 columns to keep the layout inside the magic 960px wide. This is real. This is a pinterest/masonry style picture gallery, on 1 etap it loads 50pics. When scroll down, as a scroll hyjack, it loads 50pics again (normally this is an ajaxCall). We reach the limit after 2 lazy loads. So I think this is a real problem. Note: this is the suggested way by w3c as a masonry layout currently.
Well, it's a fairly wasteful design. It's using 1px rows and each image stretch the number of rows it needs for its height. If you look at the first page it's easy to realize that you only need a new row at each vertical gap between the images. So, in a 3-column design, if the first 3 images have heights 50px 100px 150px, the first row can be 50px. Then you need to fill up images so that all columns get past the 100px mark before you can decide the size of the next row. For example, if the next three images happen to be 25px 25px 25px, then you need a new row at 75px (tentatively) and need to wait for all columns to get past that mark, etc. There are probably several ways to solve this problem. The simplest might be to do what you do now and wait for all images to load and then calculate globally the minimum set of rows and their sizes and set 'grid-template-rows' accordingly. It seems like it would be fairly easy to do it incrementally too. For your example, it would cut the number of rows by two orders of magnitude.
FYI, someone solved this problem about two decades ago for Tinderbox, using tables and cells with rowspan, IIRC. Quite neat :-) http://archive.oreilly.com/mozilla/2000/09/29/graphics/tinderbox.gif
> then you need a new row at 75px (tentatively) and need to wait for all columns to get past that mark Actually, for that example, the 2nd/3rd column are already past that mark (100px/150px) so you *know* the 2nd row can be 25px. Anyway, I think you get my point...
> Note: this is the suggested way by w3c as a masonry layout currently. BTW, do you have an URL?
Mats, well yes, that is what we do at chatzilla. using tables. But this is obsolete you know well. :) Tabatkins comment is the relevant at: https://github.com/w3c/csswg-drafts/issues/945 comment3 This problem is for picture galleries. I already tested with 5px steps with that clausura the pictureHeight must be zero by modulo 5. But currently that step is only enough for 7-8 lazyloads. What is the processotime-cost for this algorythm? ordo(n^2) ? I suggest 256 000 lines as maximum, if not too expensive, that is enough for 58-60 layloads of this testcase. I think the masonry/pinterest fans would be satisfied with 60 loads, I dont't think If I will lazyload 100 etaps on a page in the future :P So summary I suggest 256 000 lines. That is enough for the real life.
Mats, you probably should suggest limit for row-spanning, that can be 5000-10000 if that causes stacking problems. But not for the flowing. BTW we are just started to work around the table layout at chatzilla under the Bug 1128353. This is what I've uploaded yesterday: https://bugzilla.mozilla.org/attachment.cgi?id=8833773 If you interested, chatzilla currently (and for the last 20 years) uses table with rowspan attribute to collapse the messages, in a same way as you suggested. Anyway I'm always available at moznet under the nickname :hunboy That is better way to chat with me instead of chatting on a bug. So I keep suggesting 256 000 rows for the grid.
@Mats Palmgren WebKit and Blink is 1000000? https://bugs.webkit.org/attachment.cgi?id=298042&action=prettypatch
No it's not 100000 anymore, it's 1000x1000 right now due to memory issues.
Manuel, Mats, can you comment the github with the issues? https://github.com/w3c/csswg-drafts/issues/1009 I have an idea. 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
Due to Agenda at W3C - the reference bug was closed by moving to css-grid-2 as masonry/pinterest layout. So this bug is obsolete now. In other way 10 000 x 10 000 cells are absolutely enough for both axis, so I (as reporter) close this bug for css-grid-1 as WONTFIX. End users can make now "1 screen masonry" for 4000x1440px wide screens as well with 10000cols/rows, and we will see how it will work in grid-2.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.