- From: Christopher Kirk-Nielsen via GitHub <sysbot+gh@w3.org>
- Date: Sat, 20 Apr 2024 16:06:14 +0000
- To: public-css-archive@w3.org
While I already agree with everything mentioned, just adding my own thoughts below: I've recently shipped a project that could have made great use of masonry layout for a "mega menu". We ended up using standard multicol to get a similar behaviour, but each group has to be manually placed to optimise how much space they take (some have 2 sub-items, other have 8), so it ends up being tedious to place all the pieces. Masonry would make that very easy and solve common layout problems on many projects. As far as the `display` debate, I'd be in favour of keeping everything as `grid`. This allows me to remember a single set of properties that work consistently, simply expanding what I know instead of learning new rules, and to easily switch between the behaviours should I need to revert — or more likely, progressively enhance an existing grid. Regarding the naming, the obvious alternative is `columnar` but holy heck would that be confusing: `grid-template-rows: columnar` (and if you read further ahead in my comment, would `grid-template-columns` also be `columnar`…?). I like the `off` idea, short and sweet, though I could also see something like: - `stagger`, maybe there's a better, similar term? - `loose`, authors can have trouble with this word vs `lose` and it might induce typos… alt: `free`? - `unbound`, as in, not bound to any track (which feels only half-true), alt: `detach`/`detached`? - `float`, okay now this is worse… but the "floaty" idea seems right, or like how oil and water have different buoyancy values, they "float" at different levels… though this is also a metaphor, and not a better one that masonry - (would have loved `auto` but like `none` that is already a valid value) Finally to piggyback on @DanielHeath's comments: > It's unclear whether `grid-template-columns` would be equally supported - IMO not doing so would be a serious mistake, because everything else in grid works equally on either axis I am wondering about this too. While I wouldn't need it as much, I'd definitely like that flexibility. And a nitpick of my own: > There's heaps of CLS on a slow connection because the `img` tags lack an aspect-ratio Not only the lack of width/height (which, ironically, I now consistently do because of Jen's push on that some years ago 😄) but also the 1MB+ PNGs in the article can easily be optimised. **TL;DR:** Overall, feeling very positive about all of this! -- GitHub Notification of comment by chriskirknielsen Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10233#issuecomment-2067717159 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 20 April 2024 16:06:15 UTC