Open jensimmons opened 1 year ago
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).
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).
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
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.
The CSS Working Group just discussed [css-grid-3] FPWD for Masonry Layout
.
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.
APA wants clarify or caveat a couple of concerns (see my modified codepen):
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?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.
Removing Agenda+ since we can't discuss this issue until there is more discussion on #9041. We should discuss that first.
@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:
masonry-slack
proposal to specify tie thresholds as resolved in #9328.auto-fit
rules for collapsing “empty” tracks per #10274.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
.)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.
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.