[css-grid-3] intrinsic track sizing algorithm for masonry can go exponential in complexity. #10053
Description
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.