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] Re "Clamping Overly Large Grids": Perhaps have a minimal required track count #2261

Closed
tobireif opened this Issue Feb 2, 2018 · 25 comments

Comments

Projects
None yet
@tobireif

tobireif commented Feb 2, 2018

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?

@tabatkins tabatkins added the css-grid-1 label Feb 6, 2018

@fantasai

This comment has been minimized.

Contributor

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

@fantasai fantasai added the Agenda+ label Feb 6, 2018

tabatkins added a commit that referenced this issue Feb 6, 2018

Add back the 'at least one million tracks' requirement, which we reso…
…lved on back in Jan 2015 and forgot to add back in. Related to #2261.
@tobireif

This comment has been minimized.

tobireif commented Feb 7, 2018

I'm assuming this gets merged -

Thanks all!

@tobireif

This comment has been minimized.

tobireif commented Feb 7, 2018

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

@js-choi

This comment has been minimized.

js-choi commented 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

This comment has been minimized.

svillar commented 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

This comment has been minimized.

tobireif commented 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

This comment has been minimized.

tobireif commented 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

This comment has been minimized.

Contributor

fantasai commented 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 astearns removed the Agenda+ label Feb 13, 2018

@astearns

This comment has been minimized.

Member

astearns commented Feb 13, 2018

(removing agenda label in favor of implementer feedback here)

@fantasai

This comment has been minimized.

Contributor

fantasai commented Feb 13, 2018

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

@tobireif

This comment has been minimized.

tobireif commented Feb 14, 2018

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

This comment has been minimized.

MatsPalmgren commented Feb 14, 2018

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 tabatkins added the Agenda+ label Feb 14, 2018

@tabatkins

This comment has been minimized.

Member

tabatkins commented Feb 14, 2018

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

This comment has been minimized.

tobireif commented Feb 14, 2018

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

@tobireif

This comment has been minimized.

tobireif commented Feb 14, 2018

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

@svillar

This comment has been minimized.

svillar commented Feb 15, 2018

In chrome we support [-9999, 9999]

@svillar

This comment has been minimized.

svillar commented Feb 15, 2018

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

This comment has been minimized.

Member

css-meeting-bot commented Feb 21, 2018

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

This comment has been minimized.

Contributor

fantasai commented Feb 21, 2018

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

@FremyCompany

This comment has been minimized.

Contributor

FremyCompany commented 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

This comment has been minimized.

svillar commented 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

This comment has been minimized.

Member

tabatkins commented Mar 26, 2018

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

@dvdbot

This comment has been minimized.

dvdbot commented 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

This comment has been minimized.

Contributor

rachelandrew commented 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

This comment has been minimized.

tobireif commented Jun 14, 2018

Oh I forgot - thanks all!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment