Re: [csswg-drafts] [css-grid-3][masonry] Masonry Syntax Debate (#11243)

I am an outsider here, but wanted to give my grain of sand from an author's point of view. I don't want to get into which proposal will be easier to define in the spec or implement in browsers since that's something that most developers aren't aware of but rather boil it down to what syntax developers will find easier to learn and use, and if the future gives us more layouts like the [Webkit post](https://webkit.org/blog/16026/css-masonry-syntax/) suggests, which will make it easier for developers to learn to new layouts.

## Prefixes and extra properties

One of the main arguments for the Just Use Grid team is the enormous amount of similar properties that would need to be added to CSS.

![image](https://github.com/user-attachments/assets/3090a71c-e04c-4b02-8e25-f4e80a33c114)

By the WebKit Post:

> One of the guiding principles that drives decisions at the CSS Working Group is to always strive to reuse existing patterns and properties when creating new possibilities.

> When multicolumn was invented, a new `column-gap` property provided a way to define the space between columns. A decade later, when the CSSWG needed a way to define space between grid columns, the `column-gap` property was repurposed. It got a corresponding `row-gap` property and a new shorthand, `gap`, to be more universal, and eventually made its way to Flexbox as well. It took a couple of tries, but the CSSWG realized it would be a mistake to keep creating separate gap properties for different contexts — `column-gap` + `grid-gap` + `flex-gap`… It’s better to repurpose what already exists.

By the same logic, it isn't a problem of new properties with a `masonry-`  prefix, but of the prefixes altogether. If we are thinking about defining new layouts, then the `grid-` prefix is also a reusability antipattern. I keep thinking that, just from a syntax standpoint, it should be possible to use a new unprefixed `template-areas` property for masonry and grid, regardless of the formatting contexts.

If we look at another example given in the WebKit post:

![image](https://github.com/user-attachments/assets/a8cdd4cd-191d-4801-a056-d17d3eb7f492)

According to the Chrome proposal, this type of layout would have its own prefix, but I think everyone would agree it would be hellish to also have `pillar-` or `new-layout-`  prefixed properties, and so on if future layouts are added.

Onto the Webkit argument, they say that maybe in the future this layout could be achieved with a snippet like the following:

```css
article {
  display: block; /* default value, unnecessary to state */
  grid-template-columns: 1fr 1fr minmax(15ch, 30ch) minmax(15ch, 30ch) 1fr;
  grid-default-column: 3 / 5;
}
```

But to me, it feels unnatural to use `grid-` prefixed properties for things that aren't grid. That's why I think removing prefixing altogether is an option to consider. The `grid-`  prefixed properties would still work for backward compatibility, but you could also use the unprefixed version. Maybe properties that only work in their corresponding formatting context would remain prefixed, but overall, it would reduce the number of properties to add and the syntax to remember. 

If the conversation is focusing on unifying, then I just wanted to bring this to the table, but I must say that I am ignorant of the consequences and implications of this. Just a not-that-technical developer's point of view of what I would like to code in the future :)
 

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


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

Received on Friday, 6 December 2024 20:29:50 UTC