[csswg-drafts] [css-grid-3] Current track sizing algorithm can go exponential in complexity. (#10053)

bfgeek has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-grid-3] Current track sizing algorithm can go exponential in complexity. ==
https://drafts.csswg.org/css-grid-3/#track-sizing

Currently you need to place everything in every possible position. With subgrid this means that the complexity can go ~exponential (or sub-exponential).

```
<div style="grid-template: masonry / repeat(10, auto);">
  <div style="grid-template: subgrid / subgrid; grid-column: auto / span 6;"> <!-- 5 positions -->
    <div style="grid-template: subgrid / subgrid; grid-column: auto / span 3;"> <!-- 4 positions -->
      <div></div> <!-- 3 positions -->
    </div>
  </div>
</div>
```
In the above example there are 60 positions you need to test (each subgrid level might have different margin/border/padding which needs to be taken into account for the items contribution in a particular position along with many other factors).

In Blink we've spent most of our performance work in layout fixing exponential time bugs - developers really care about layout time performance. While these issues were quality of implementation bugs (and not a core problem with a particular spec), having exponential time complexity in a spec seems bad[1].

[1] - Exponential time complexity doesn't care how powerful your CPU is - it'll always win.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10053 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 8 March 2024 17:41:21 UTC