Re: [csswg-drafts] Alternate masonry path forward (#9041)

The Microsoft Edge team has spent time investigating the current Masonry proposal as outlined in the Grid specification, and we have compared this with the proposal Ian has laid out in this issue. In summary, moving Masonry to its own display type would be our recommended path forward for the reasons outlined below. 
 
The first reason is that we believe there are core aspects of Masonry that are philosophically distinct from Grid: 

1. As defined in the Grid spec, placement _must_ come before sizing. Masonry breaks this principle by requiring the auto placement algorithm to have the resolved contribution size of a grid item before placing it. 

     - This has been discussed in [[css-grid-3] Masonry - Intrinsic sizing of tracks & masonry-grid doesn't produce to good/desirable results. · Issue #8206 · w3c/csswg-drafts · GitHub,](https://github.com/w3c/csswg-drafts/issues/8206#issuecomment-1710169743) but we believe there are scenarios that are still overlooked and will be difficult to reason about, e.g., subgrid extra margins, baseline shims, spanning of definite max track sizing functions. 

2. In Grid, the grid areas are defined by the intersection between grid lines in the columns and row axis. However, in Masonry the grid lines are only honored in the grid axis. In the masonry axis, there are no grid lines; these are instead determined by the “running position” of each track in the grid axis. 

     - This is significant implementation-wise because determining alignment in the masonry axis will require a separate set of data structures to compute the running positions and perform layout than is needed in Grid today. 

3. Given points 1 and 2 above, the implementation of Masonry within the Grid Module will require large chunks of divergences in code, which helps indicate to us that Masonry makes more sense as its own display type. 

4. Subgrid is overkill for Masonry layout. 

     - A very tricky scenario to nail in Subgrid is having mixed subgridded and standalone axes (i.e. having a subgrid with subgridded columns/standalone row, with a nested standalone columns/subgridded rows, etc). This scenario is very tricky because figuring out which subgridded items are considered for sizing in each axis involves complex logic. 
     - As the css-grid-2 spec states, the grid sizing algorithm requires drilling down per axis into subgrids, rather than completing both axes as it recurses. 
     - These two points can be severely simplified in Masonry, since we can only utilize subgrid (or its equivalent in `display: masonry`) in the grid axis. 

5. There is at least one feature in Grid that doesn't make sense in Masonry (`grid-template-areas`) and one feature in Masonry that doesn't make sense in Grid (`masonry-auto-flow`). 

The next major category that we find to be a drawback to keeping Masonry as part of the Grid spec is the performance implication. The proposal outlined to address the placement/sizing mismatch in https://github.com/w3c/csswg-drafts/issues/8206#issuecomment-1710169743 could result in approximately quadratic performance, even in very simple cases. 

Webkit’s initial attempt to implement this proposal ([Masonry isn't performing intrinsic sizing correctly. by stwrt · Pull Request #27048 · WebKit/WebKit (github.com))](https://github.com/WebKit/WebKit/pull/27048) doesn’t, from our reading of the code, implement this in a way that showcases the full performance implication. For example, items that span multiple tracks don’t seem to be considered in Webkit’s implementation. 

More specifically, consider `grid-template-columns: 100px auto auto auto 50px`, an item with `width: 100px` spanning 3 columns has 3 different possible contributions to the 3rd track. If it's placed at the beginning of the 1st track, it will contribute `0px` to the 3rd column; if it's placed at the beginning of the 2nd column it will contribute `33.33px`; finally, if placed at the beginning of the 3rd track, it will contribute `25px`. 

Beyond the complexity of implementation, we also feel that Ian’s proposal would be much simpler from an authoring perspective, likely will be easier for authors to understand, while also considering what we believe will be top authoring use cases. 

As such, we would like to +1 the proposal to move Masonry to its own display type.

@ethanjv

-- 
GitHub Notification of comment by alisonmaher
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9041#issuecomment-2073950737 using your GitHub account


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

Received on Wednesday, 24 April 2024 03:32:10 UTC