- From: Shaw Jia via GitHub <sysbot+gh@w3.org>
- Date: Fri, 25 Oct 2024 05:03:13 +0000
- To: public-css-archive@w3.org
Initially I leaned toward “just use grid” simply due to it requiring fewer new CSS properties which feels more efficient at first glance.
However after thinking about it some more I am coming around to ` display:masonry`.
1. Simplicity should not be defined as lines of code or number of characters, but rather conceptual simplicity and clarity of intent. If all we care about is character count then everyone would be writing minified CSS.
In that respect “just use grid” is in the former camp, while `display:masonry` is in the latter, and I believe clarity of intent is what we should be optimizing for.
How does `display:masonry` achieve clarity of intent with extra properties?
First, by reducing the cognitive load due to not having to think about the masonry axis; second, by having a simpler syntax for `masonry-template-areas` in the row direction compared to `grid-template-areas`, which makes switching direction a breeze.
2. Requiring developer to switch mental models in the case of `display:masonry` is actually a good thing, as it simplifies mental model for both grid and masonry.
The argument that having a separate display mode is more burdensome than stuffing it into an already complicate grid layout does not make sense to me, as it’s much easier to learn two simpler system than one really complex system. And grid is complex enough already.
3. WebKit teams’ argument for extensibility of “just use grid” vs `display:masonry` did not focus on the fact that “just use grid” forces masonry to accept grid limitations for future feature extensions, but rather hinges on a “slippery slope” argument regarding potential display models in the future.
I feel technical limitation is much more important in the browser environment where we have to live with our decisions forever. There is nothing forcing us to not extend grid when it makes sense “aka. Pillars layout” even if `display:masonry` exists. It might not feel ideologically pure, but CSS to me was never particularly concerned with that.
However if we do discover a use case for a potential masonry feature that is impossible to implement when integrated into the grid, that would be a much bigger problem to deal with.
4. WebKit’s teams’ argument that the default value of `repeat(auto-fill, auto)` is not actually desirable hinges on the fact that images could lose sharpness when stretched too much.
This does not consider the potential of responsive images, and future format such as JPEG XL where the browser can intelligently request for the appropriate image resolutions.
In addition, this can be solved simply by applying a `max-width` on the masonry container itself, or `justify-content:start` to turn off track stretching.
In fact, this might not even be a concern for certain use cases such as digital signages and kiosks where the display size is known.
Finally, you may simply accept the fact that your images could lose sharpness at larger viewport sizes. Perfect is the enemy of the good.
5. I see some commenters putting forth the argument that masonry is “too exotic” to deserve its own display type which I feel is a bit silly, as there is nothing special about `display` values, aren’t we assigning undue importance to it?
6. As for graceful degradation from masonry to grid, we already have the `@supports` at-rule, so it’s a non-issue.
--
GitHub Notification of comment by miragecraft
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11060#issuecomment-2436841776 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 25 October 2024 05:03:14 UTC