Skip to content

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

Closed

Description

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

Activity

  1. fantasai commented on Feb 6, 2018

    @fantasai
    Collaborator

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

  2. tobireif commented on Feb 7, 2018

    @tobireif
    Author

    I'm assuming this gets merged -

    Thanks all!

  3. tobireif commented on Feb 7, 2018

    @tobireif
    Author

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

  4. js-choi commented on Feb 7, 2018

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

  5. svillar commented on Feb 7, 2018

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

  6. tobireif commented on Feb 7, 2018

    @tobireif
    Author

    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.

  7. tobireif commented on Feb 8, 2018

    @tobireif
    Author

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

  8. fantasai commented on Feb 12, 2018

    @fantasai
    Collaborator

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

  9. astearns commented on Feb 13, 2018

    @astearns
    Member

    (removing agenda label in favor of implementer feedback here)

  10. fantasai commented on Feb 13, 2018

    @fantasai
    Collaborator

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

  11. tobireif commented on Feb 14, 2018

    @tobireif
    Author

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

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

  12. 8 remaining items

  13. fantasai commented on Feb 21, 2018

    @fantasai
    Collaborator

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

  14. FremyCompany commented on Feb 21, 2018

    @FremyCompany
    Contributor

    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.

  15. svillar commented on Feb 22, 2018

    @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

  16. tabatkins commented on Mar 26, 2018

    @tabatkins
    Member

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

  17. added a commit that references this issue on Mar 26, 2018
  18. added 2 commits that reference this issue on May 7, 2018
    4b4080b
    e49db6c
  19. ThaDaVos commented on Jun 14, 2018

    @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

  20. rachelandrew commented on Jun 14, 2018

    @rachelandrew
    Contributor

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

  21. tobireif commented on Jun 14, 2018

    @tobireif
    Author

    Oh I forgot - thanks all!

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions