- From: beeps via GitHub <sysbot+gh@w3.org>
- Date: Sun, 27 Oct 2024 08:56:59 +0000
- To: public-css-archive@w3.org
Thoughts, with the caveat that I'm not deep in the weeds of how specifications or CSS works behind the scenes, I'm just a developer who uses it every day. (Though I guess that's exactly who you want to feed back on this!) I prefer the grid-integrated syntax for a number of reasons: 1. In my mind, there are only a few different layout modes in CSS. There's 'the flow' (the default), a few tools for fiddling or breaking out of the flow (`float`, `position`), one-dimensional layout (`flex`) and two-dimensional layout (`grid`). Masonry, in my mind, is another form of two-dimensional layout with a significant amount of overlap with grid, so **making masonry an extension of grid makes intuitive sense to me**. 2. Reducing the number of new properties being added to CSS seems sensible, especially as many of the properties proposed in the standalone masonry syntax do virtually the same thing as their grid counterparts. 3. Keeping things familiar reduces the amount of new stuff that has to be learned and taught. As an on-again-off-again tutor of frontend things, I've noticed that a lot of people find flex and grid layouts intimidating to learn and use. Being able to change a grid to a masonry with just one or two lines of CSS makes learning masonry and grid a two-in-one package. **In my mind, grid already having a 'complex' syntax is more reason to merge masonry into it.** 4. Whilst I appreciate (and kind of agree) with the argument that a separate syntax permits setting sensible defaults out-of-the-box, I don't see this as a showstopping difference. **As a developer I'm very used to overwriting CSS's 'sensible defaults'**, this would just be another instance of that. I'm not sure about other browsers, but Firefox's devtools are also very good at pointing out where incompatible properties are being used together and why, which makes the idea of having to debug 'illegal' layouts not feel particularly daunting. 5. The Chrome team's argument that masonry layout needs to be separate for performance reasons also doesn't hold much water for me. We shouldn't be making spec decisions on the basis of present-day engine limitations. **The developer experience should be the priority when it comes to syntax decisions.**[^1] 6. As noted by commenters above, having them integrated makes progressively enhancing a grid into a masonry layout (or dynamically switching between them) a lot simpler. 7. Having masonry integrated with grid doesn't preclude having `masonry-*` properties that modify masonry-specific features in future. Having masonry start as a completely separate syntax _does_ preclude it leveraging the existing features of grid in future, without also requiring vendors to provide the indefinite backwards compatibility for its unique properties. [^1]: Is there literally not some W3C mantra somewhere about favouring users over developers, favouring developers over browser vendors, etc.? -- GitHub Notification of comment by querkmachine Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11060#issuecomment-2439913971 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 27 October 2024 08:57:00 UTC