- From: Ian Kilpatrick via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Dec 2022 20:29:24 +0000
- To: public-css-archive@w3.org
We quickly reviewed the current state of the specification. There are a few concerns we 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 we've seen in particular there is a desire to have repeaters which are intrinsically sized (which isn't currently possible with regular grid repeaters). We suspect that re-using the grid algorithm as described isn't the best approach here. As-is its unclear if attempting to re-use the grid placement & sizing logic results in the best feature for web developers. 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 we've seen - there doesn't seem to be much desire for aligning indivudal tracks, rather the primary desire is switching the direction for the "start" mansonry 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). We 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. We'd like to see these class of issues thought about before moving to FPWD. Ian -- GitHub Notification of comment by bfgeek Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8195#issuecomment-1347260607 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 12 December 2022 20:29:26 UTC