[css-grid-3] FPWD for Masonry Layout

[jensimmons]

There is an Editor's Draft for Masonry layout at https://drafts.csswg.org/css-grid-3/

We would like to see this go to First Public Working Draft.

[bfgeek]

I quickly reviewed the current state of the specification. There are a few concerns I have with the general direction (to be clear - not the use-cases, and desire for the feature in general - just the current direction of the specification).

1. Issues with intrinsic sizing of masonry grids. https://github.com/w3c/csswg-drafts/issues/8206

Grid works by placing everything in the grid ahead of time, then sizing the rows/columns to fit the items. Masonry fundamentally doesn't work this way as you need to size the rows/columns ahead of time - then place items within those rows/columns.

As a result the way the current specification re-uses the grid sizing logic leads to poor results when intrinsically sizing tracks, and if the grid is intrinsically-sized itself (e.g. if its within a grid/flex/table, etc).

Here is a simple example demonstrating one aspect of this issue within Firefox Nightly. https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=11094

How to solve this particular issue is a relatively fundamental issue for this specification. There are many different potential avenues for solving this. From masonry examples I've seen in particular there is a desire to have repeaters which are intrinsically sized (which isn't currently possible with regular grid repeaters). I suspect that re-using the grid algorithm as described isn't the best approach here for web developers. (The linked issue has some very early ideas which might match web developer expectations better than the current placement+sizing logic).

2. Issues with align-tracks/justify-tracks. https://github.com/w3c/csswg-drafts/issues/8207 and https://github.com/w3c/csswg-drafts/issues/8208

As-is this sub-feature has a few issues. The primary concern is with accessibility. This feature allows authors to create order with unclear visual ordering (e.g. even with the new visual-order feature we'd still have issues). From examples of masonry layouts I've seen - there doesn't seem to be much desire for aligning individual tracks, rather the primary desire is switching the direction for the "start" masonry edge which the current specification doesn't address.

There is a similar accessibility concern with masonry-auto-flow: next.

Additionally this sub-feature doesn't have any logic for dealing with items spanning tracks (in almost every non-start case leading to undesirable overlapping content in our testing within Firefox Nightly).

I suspect there is an alternate solution space here which doesn't involve aligning individual tracks. E.g. masonry.js has flags to flip the "origin" https://masonry.desandro.com/options.html#origintop There is likely a algorithm that could be used for stretching all the tracks, in such a way that it keeps the visual order consistent.

I'd like to see these class of issues thought about before moving to FPWD.

Ian

[jensimmons]

From examples of masonry layouts I've seen - there doesn't seem to be much desire for aligning individual tracks, rather the primary desire is switching the direction for the "start" masonry edge which the current specification doesn't address.

I suspect there is an alternate solution space here which doesn't involve aligning individual tracks.

I agree. At first glance, I'm not sure what the compelling use case is for aligning individual tracks. It seems far more common designers/developers would want to change the alignment of all the tracks from start to end, etc. Not each separately.

[css-meeting-bot]

The CSS Working Group just discussed [css-grid-3] FPWD for Masonry Layout.

The full IRC log of that discussion

<bramus> jensimmons: we are interested in moving spec forward
<bramus> jensimmons: issue to revive conversation. Thanks iank with thoughts
<bramus> astearns: my assumption is that we should start engaging on the brought up issues
<chrishtr> +1 to resolving those issue before fpwd
<bramus> astearns: after that we can come back to publishing FPWD or not
<bramus> astearns: open to suggestions
<bramus> jensimmons: don’t htink we have suggestions, but there was lots of talk going on when firefox was working on it.
<bramus> astearns: i assume you will also find new issues a your engineering team is working it. great to see engagement on this as its a highly requested feature
<bramus> jensimmons: work is happening now, not in Safari TP yet but that is the next step
<bramus> astearns: call to all to take a look at the issues

[henke37]

I think that it would be a good addition to have a non-normative section that compares the feature against the dense mode of grid-auto-flow.

[AutoSponge]

APA wants clarify or caveat a couple of concerns (see my modified codepen):

1. Sighted keyboard users could have a disorienting experience trying to predict focus order and track focus (especially with poor focus visibility). This could also be frustrating or distracting for people with cognitive/learning disabilities. Where order matters, this technique should be avoided. Do we have sufficient warning to authors?
2. If authors attempt to preserve visual focus order with tabindex or by placing elements in an illogical DOM order, the experience is worse for AT users who can't see the screen. Do we have sufficient emphasis for authors to start with logical DOM order and build their layout on top of that?

[svgeesus]

It seems there is some support for the concerns raised by @bfgeek and thus, unless the editors now think otherwise, I feel that calling for FPWD is premature.

@tabatkins @fantasai @MatsPalmgren @jensimmons @stwrt

(I'm normally all for early-enough FPWD, but in this specific case where the overall direction is in question it seems premature).

I suggest removing the Agenda+ and, once there is rough consensus on the overall direction, re-applying it.

Linking other relevant masonry threads to this one would also probably help, including (especially) once they are closed ie there is agreement.

[chrishtr]

Removing Agenda+ since we can't discuss this issue until there is more discussion on #9041. We should discuss that first.

[fantasai]

@tabatkins and I worked through their Alternate Masonry Draft (#9041) as well as the Needs Edits issues against masonry and merged everything into the current CSS Grid Layout Level 3 Editor's Draft.

The changes include:

• Outlining both syntax proposals in parallel, while factoring out everything that remains common. Sections that are different are called out with colored bars on the right edge.
• Sketching out the optimized version of the track sizing algorithm, including special handling of submasonry items.
• Incorporating the masonry-slack proposal to specify tie thresholds as resolved in #9328.
• Giving auto-fit rules for collapsing “empty” tracks per #10274.
• Adding row-reverse, column-reverse, and wrap-reverse keywords to grid-auto-flow per #3622 and applying them to masonry placement in the grid-integrated model. (The grid-independent model uses masonry-flow.)
• Introducing an auto-areas repeat keyword that generates a size listing to match the number of tracks created by template areas, for both grid and masonry containers. (This was a new feature in Tab's draft.)

We'd like to request FPWD of this combined draft to encourage review and discussion by the broader community.