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

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

== Alternate masonry path forward ==
TL;DR

```css
display: masonry;
masonry-template: repeat(auto-fill, auto);
masonry-direction: column-reverse;
masonry-span: 2;
masonry-threashold: 2px;
```

The primary issue with building masonry layout on top of grid is related to intrinsic-sizing (of the container itself, and intrinsic tracks).

Grid layout works by placing everything in the 2D grid, that is assigning each child a column(s), and row(s), then sizing the grid with all the children fixed within the grid (they can't jump to another grid position).

Masonry layout however works in reverse - by sizing the rows/columns first, then placing children in the "shortest" row/column. This means that we can't correctly size the rows/columns (as we don't know the content), and also can't size the container itself correctly (if sizing using min/max content sizes).

This is detailed in issue: https://github.com/w3c/csswg-drafts/issues/8206

There are potential workarounds to deal with this issue, e.g. assume that all children are in every row/column for the purposes of sizing, but this prevents some potentially desirable use cases.

One thing that seems desirable is to allow a wider/different syntax for rows/columns than is currently allowed for grid, e.g. `masonry-template: repeat(auto-fill, auto)`. 
(Above would measure all the masonry items, and select the best number of tracks to fit the content).
(Arguably above might be a better default than masonry-template: auto for example). 
This isn't possible for grid-template for good reasons - but we could accept it for masonry.
One open question is if we need different track sizes or just one would suffice. All the designs I have personally seen have just one track repeated N times. Accepting just one track template would allow easier intrinsic sizing of spanners for example.

One addition which is currently missing with grid repeaters is the ability to clamp to a minimum / maximum number. This is more relevant with masonry. E.g. `masonry-template: repeat(auto-fill, /* min */ 1, /* max */ 5, auto)` would allow clamping to a maximum of 5 tracks which seems desirable from designs I've seen.
(this is probably a bad syntax but you get the idea).

Another missing in the current proposal is controlling the direction of the masonry flow. E.g. there are cases where you'd want the masonry axis to start from the block-end / inline-end.
This could be covered by a property similar to flex-direction , a simple (and likely understandable property) might be:
`masonry-direction: row | row-reverse | column | column-reverse`
(this would be similar to the originTop/originLeft controls in masonry.js https://masonry.desandro.com/options.html#originleft )

One issue with masonry style layouts is that things can easily be visually out of order, e.g. if the current tracks are [100px, 99px] the next masonry item would be placed in the 2nd track, when the first would be more natural. A potentially solution to this is some user defined "threshold" to "place within the first track within Xpx of the smallest track"
`masonry-threshold: <length>`

Things that aren't in this proposal vs. the current draft are:
 - No ability to place a masonry item in an explicit row/column. I personally haven't seen people do this. Personally I don't think it's needed, and somewhat harmful accessibility wise.
 - No ability to align individual tracks. As discussed: https://github.com/w3c/csswg-drafts/issues/8208 https://github.com/w3c/csswg-drafts/issues/8207 I personally haven't seen people do this in designs, current spec text leads to undesirable rendering. Personally I don't think it's needed - and bad for accessibility by default.
 - The masonry-auto-flow:next feature. Personally I haven't seen any designs use this type of flow - and bad for accessibility.
 - No masonry-template:subgrid we could add this. But it'd be a "simple" inheritance, the masonry element wouldn't get to participate in the sizing of the parent grid structure.

Ian


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


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

Received on Thursday, 6 July 2023 22:49:55 UTC