You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-grid] Re "Clamping Overly Large Grids": Perhaps have a minimal required track count #2261
Some might use CSS Grid for eg spreadsheet-like web-aps, or for crazy layouts where each cell is like a dot in a dot matrix, and there probably are more use-cases for high track counts. These Grid users should be able to rely on some level of track count. Perhaps have a minimal required track count / column/row count?
I thought we had one, but apparently we don't. :) This email mentions a previous 1-million minimum, which got removed during some rewrites. A later CSSWG resolution states to add it back in, but doesn't seem to have happened...
I don’t know if it would be worth specifying or even where it would be specified, but it might also be useful for the page to be notified when a grid exceeds its maximum number of tracks, as the precise number depends on the UA and on memory pressure. Some DOM event perhaps.
Yep, one million columns times one million rows equals one trillion cells. Even if just one byte would be used in memory for each cell that would mean one Terabyte in memory.
I guess that the minimal required track count needs to be lower.
Also, I think that the total amount of cells needs to get specd, instead of the total amount of tracks, because the result of columns × rows is what taxes memory. So if the spec would say "the limit should allow for at least one billion cells" the largest grids that don't violate the lowest limit could be eg 10 × 100000000, or eg 10000 x 100000, or eg 1 x 1000000000, but for example 1000000000 x 1000000000 would be over that limit.
As for keeping eg one byte per cell in memory: For example "grid-column: 1000000; grid-row: 1000000" shouldn't cause the browser to create much data in memory - not 1000000 × 1000000 × N bytes. But I still guess the spec should specify a minimal limit for cells (instead of tracks), and the limit probably still should get lowered (based on the implementer feedback by Igalia).
Edge does not have a limit as far as I can see, so we should be totally fine with a limit of 10k in each directions. Edge would have a limit on the total pixel area the grid could occupy, but I don't expect this to be a concern for reasonable use cases.
Is there a known ETA when a increase of the limit will be there?
Currently working on a drag and drop grid and using repeat(auto-fill, 0.1px) for my rows and cols but currently Mozilla Firefox limits it to 1887 cols and 883 rows so I can't get the high level precision I need with the rows and columns.
Currently looking into WebGL, maybe that can offer a solution but would love to just be able to do it with CSS-Grid
@dvdbot it has been updated in the spec already as you can see from the commit above, when browsers update to match this recommendation is a separate issue so you could go find and star any relevant browser bug that deals with this, for example.
Activity
fantasai commentedon Feb 6, 2018
I thought we had one, but apparently we don't. :) This email mentions a previous 1-million minimum, which got removed during some rewrites. A later CSSWG resolution states to add it back in, but doesn't seem to have happened...
Add back the 'at least one million tracks' requirement, which we reso…
tobireif commentedon Feb 7, 2018
I'm assuming this gets merged -
Thanks all!
tobireif commentedon Feb 7, 2018
BTW, that's one trillion cells 😀That's plenty. Thanks again!
js-choi commentedon Feb 7, 2018
I don’t know if it would be worth specifying or even where it would be specified, but it might also be useful for the page to be notified when a grid exceeds its maximum number of tracks, as the precise number depends on the UA and on memory pressure. Some DOM event perhaps.
svillar commentedon Feb 7, 2018
We had 1M in Chromium a while ago and we had to roll it back because it was causing a lot of crashes due to out of memory issues.
tobireif commentedon Feb 7, 2018
Yep, one million columns times one million rows equals one trillion cells. Even if just one byte would be used in memory for each cell that would mean one Terabyte in memory.
I guess that the minimal required track count needs to be lower.
Also, I think that the total amount of cells needs to get specd, instead of the total amount of tracks, because the result of columns × rows is what taxes memory. So if the spec would say "the limit should allow for at least one billion cells" the largest grids that don't violate the lowest limit could be eg 10 × 100000000, or eg 10000 x 100000, or eg 1 x 1000000000, but for example 1000000000 x 1000000000 would be over that limit.
tobireif commentedon Feb 8, 2018
As for keeping eg one byte per cell in memory: For example "grid-column: 1000000; grid-row: 1000000" shouldn't cause the browser to create much data in memory - not 1000000 × 1000000 × N bytes. But I still guess the spec should specify a minimal limit for cells (instead of tracks), and the limit probably still should get lowered (based on the implementer feedback by Igalia).
fantasai commentedon Feb 12, 2018
@svillar What would you recommend as a safe “minimum”? (A UA can go higher, this is just an “UA should support at lease this many” number.)
astearns commentedon Feb 13, 2018
(removing agenda label in favor of implementer feedback here)
fantasai commentedon Feb 13, 2018
Mats reports that Gecko uses +/- 10,000 as a cap for Gecko, fwiw.
tobireif commentedon Feb 14, 2018
As a limit for tracks, or as a limit for cells?
8 remaining items
fantasai commentedon Feb 21, 2018
@svillar I think your logic makes sense, so capping the tracks seems reasonable to me.
FremyCompany commentedon Feb 21, 2018
Edge does not have a limit as far as I can see, so we should be totally fine with a limit of 10k in each directions. Edge would have a limit on the total pixel area the grid could occupy, but I don't expect this to be a concern for reasonable use cases.
svillar commentedon Feb 22, 2018
So it turns out that in Chromium we actually have [-999,999]. It was changed because 10k was still causing OOM situations.
In any case, we're likely replacing our implementation soon to allow larger grids.
BTW @fantasai does 10k include implicit tracks before the explicit grid or not? In other words is the minimum 10k or 10k*2
tabatkins commentedon Mar 26, 2018
Yes, it's total, including both explicit and implicit tracks, and stretching in each direction (from lines -10k to +10k).
[css-grid] Re #2261, clarify that the limit includes implicit lines.
[css-grid] Per WG resolution, recommend 10k tracks in each direction …
[css-grid] Re w3c#2261, clarify that the limit includes implicit lines.
ThaDaVos commentedon Jun 14, 2018
Is there a known ETA when a increase of the limit will be there?
Currently working on a drag and drop grid and using repeat(auto-fill, 0.1px) for my rows and cols but currently Mozilla Firefox limits it to 1887 cols and 883 rows so I can't get the high level precision I need with the rows and columns.
Currently looking into WebGL, maybe that can offer a solution but would love to just be able to do it with CSS-Grid
rachelandrew commentedon Jun 14, 2018
@dvdbot it has been updated in the spec already as you can see from the commit above, when browsers update to match this recommendation is a separate issue so you could go find and star any relevant browser bug that deals with this, for example.
tobireif commentedon Jun 14, 2018
Oh I forgot - thanks all!
[css-grid-1] Fix off-by-one in favor of Firefox's impl. #2261