Re: [csswg-drafts] [css-grid-3] Designer/developer feedback on masonry layout (#10233)

This feedback might not align exactly with the original intent of this issue, but since the discussion is happening here, I’ll share it anyway:

> **TL;DR:** Masonry is a good grid to have, but the proposed implementation is too specific and opinionated. Instead of adding more and more "predefined" layouts, CSS should offer more general tools for developers to define their own layout logic.

I believe that while `flex` and `grid` introduced useful features, they represent a step in the wrong direction overall, and implementing Masonry via CSS Grid Level 3 would likely make things worse. My main issue with these technologies is that they implement highly opinionated constraint-solving algorithms, which can be opaque in terms of both the layouts they enable and how to achieve them. Both flexbox and grid allow for a wide range of layouts, but there are also many that _feel_ like they should be possible, yet aren’t. I expect the same will be true for Masonry — there will inevitably be certain layouts it won’t support, forcing developers to fall back on JavaScript for manual implementation. Worse still, it’s likely to be unclear where those limitations lie.

Moreover, Masonry is a very specific design that solves a narrow set of problems while creating a distinctive, but somewhat dated, visual style. It’s less of a general UX pattern and more of a late-2000s aesthetic. I’m not sure CSS properties should encourage such specific design choices; rather, they should function as general-purpose tools. Adding a feature like Masonry will only encourage more uniformity across websites. And if we add Masonry, why stop there? Should we also add other grid layouts tailored to different styles? While `flex` and `grid` are justifiable as general-purpose tools, Masonry feels like it crosses into being overly opinionated.

At this point, CSS is becoming more like a full programming language, but instead of moving toward making it more general-purpose, we’re adding new predefined functions (`display: grid`, `display: masonry`) with increasingly convoluted arguments (`grid-template`, `align-self`, etc.). I think we should acknowledge this trend and consider making CSS more flexible and general instead of more specific. Rather than adding more predefined layouts, we should provide developers with tools to define their own constraint-solving algorithms. Features like `calc()` and variables have already brought CSS closer to this ideal, and custom layout algorithms seem like the logical next step. Introducing Masonry feels like `add()` and `mult()` would have been added, instead of the general purpose `calc()` we luckily got.

In summary, while the ability to create a Masonry layout in CSS would be valuable, I don’t believe an overly specific specification is the right solution. Developers should rather get the tools to implement their own Masonry.


-- 
GitHub Notification of comment by essenmitsosse
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10233#issuecomment-2396776692 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 7 October 2024 12:21:08 UTC