| Summary: | [css-grid] Masonry implicit grid | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Sammy Gill <sgill26> | ||||||
| Component: | CSS | Assignee: | Sammy Gill <sgill26> | ||||||
| Status: | NEW --- | ||||||||
| Severity: | Normal | CC: | simon, webkit-bug-importer | ||||||
| Priority: | P2 | Keywords: | InRadar | ||||||
| Version: | WebKit Nightly Build | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Attachments: |
|
||||||||
Created attachment 464913 [details]
Test case: aspect-ratio
I've seen this behaviour with aspect-ratio being used to calculate the width of an item too. If using masonry rows or setting the width on the item and using aspect-ratio to calculate height, the layout is as expected.
Resizing the window does trigger the correct layout to occur, just not on initial load.
|
Created attachment 463324 [details] Testcase If grid-auto-flow != masonry axis, then there may be an issue fitting certain items into the grid. The standard grid placement algorithm will increase the size of the grid in the axis opposite of grid-auto-flow direction to accommodate any items that have a large span. The same logic needs to be applied when grid-auto-flow does not match the masonry axis. For example: grid-auto-flow: row masonry: column In the above scenario if an item's row span is larger than the grid, the item will overflow and trigger the debug assert in GridMasonryLayout::updateRunningPositions (note release builds will clamp the size of the span so that it will fit into the grid). We should increase the size of the implicit grid in these types of scenarios. Interestingly, the expected behavior occurs if you change style="grid-row: 1 / span 8" to style="grid-row: 2 / span 8", so we probably just need to match that.