[css-grid] Re "Clamping Overly Large Grids": Perhaps have a minimal required track count

[tobireif]

Re https://www.w3.org/TR/css-grid-1/#overlarge-grids
"Clamping Overly Large Grids"
"For example, if a UA only supported grids with at most 1000 tracks in each dimension"

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?

[fantasai]

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

[tobireif]

I'm assuming this gets merged -

Thanks all!

[tobireif]

BTW, that's one trillion cells 😀That's plenty. Thanks again!

[js-choi]

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]

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]

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]

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]

@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]

(removing agenda label in favor of implementer feedback here)

[fantasai]

Mats reports that Gecko uses +/- 10,000 as a cap for Gecko, fwiw.

[tobireif]

Mats reports that Gecko uses +/- 10,000 as a cap for Gecko, fwiw.

As a limit for tracks, or as a limit for cells?

[MatsPalmgren]

It's a limit on line numbers actually. Gecko has no limit on cells.
The negative range is for implicit tracks before line 1, which are rarely used.
So the theoretical limit is 19999 x 19999 tracks if you use the full implicit range,
but the limit is 9999 x 9999 tracks if you just use line 1 and above.

[tabatkins]

So some obvious possibilities:

• 10k in each direction (plus and minus), like Firefox
• 1k in each direction, like the spec's example says?
• something else???

Let's see what everyone does and just pick the smallest one.

[tobireif]

I think that 10K as minimal required track count (one hundred million cells) would be sufficient even for pretty extreme use cases.

[tobireif]

(And Firefox shows that 10K is feasible, while 1M tracks was too much in Chrome.)

[svillar]

In chrome we support [-9999, 9999]

[svillar]

BTW we have explored the possibility of capping the number of cells instead the number of tracks, for example to allow very "tall" grids with just a few columns. However we finally discarded that because we thought that it'd be far more confusing for authors than having an explicit max for the number of tracks. We can reconsider that if you think it's a better approach, @fantasai @tabatkins @MatsPalmgren wdyt?

[css-meeting-bot]

The Working Group just discussed Re "Clamping Overly Large Grids": Perhaps have a minimal required track count, and agreed to the following resolutions:

• RESOLVED: have a minimum of 10k tracks in each direction as a recommendation.

The full IRC log of that discussion

<dael> Topic: Re "Clamping Overly Large Grids": Perhaps have a minimal required track count
<dael> github: https://github.com//issues/2261
<dael> TabAtkins: Earlier in the draft we had a minimum required grid size and it was fairly large. We removed that b/c it was too much. Impl can't actually support a million cells. Still good to have a min. FF has 10,000 in positive and negative direction. Seems reasonable. WG like that? Different number? Don't like having a min?
<dael> fantasai: Min should be the lowest possible number that we think is reasonable to consider. THis should be that the author can count on there being at least this many tracks.
<dael> fremy: Can we verify what browsers accept?
<dael> fantasai: Report from impl. Gecko is 10k. Chrome is 9,999
<dael> fantasai: If Edge is lower we can go with that. We don't prefer the number, jsut that it's there. And it's a should.
<dael> astearns: fremy do you know if Edge has a limit?
<dael> fremy: I don't know but we should be fine with 10k in each direction.
<dael> astearns: Anyone not okay with the idea of a minumum?
<dael> astearns: Prop: have a minimum of 10k tracks in each direction as a recommendation. Obj?
<dael> RESOLVED: have a minimum of 10k tracks in each direction as a recommendation.

[fantasai]

@svillar I think your logic makes sense, so capping the tracks seems reasonable to me.

[FremyCompany]

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]

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]

does 10k include implicit tracks before the explicit grid or not? In other words is the minimum 10k or 10k*2

Yes, it's total, including both explicit and implicit tracks, and stretching in each direction (from lines -10k to +10k).

[ThaDaVos]

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]

@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]

Oh I forgot - thanks all!