- From: Shauna Gordon via GitHub <sysbot+gh@w3.org>
- Date: Fri, 25 Oct 2024 16:40:59 +0000
- To: public-css-archive@w3.org
This table, and the argument based off of it...kind of confuses me:
Grid | Masonry | Pillar | Another future feature
-- | -- | -- | --
display: grid | display: masonry | display: pillar | display: foobar
grid-template-columns | masonry-template-tracks | pillar-template-columns | foobar-template-baz
grid-column | masonry-track | pillar-column | foobar-qux
grid-template-areas | masonry-template-areas | pillar-template-areas | foobar-template-areas
… etc … | … etc … | … etc … | … etc …
...why do we keep adding a display type prefix to what is essentially the same property.
The author keeps talking about cognitive overhead and confusing syntax, but then gives the example of using grid properties in a flow layout:
```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;
}
```
How is this not equally confusing as the New Masonry Display option?
Why don't we just...drop the prefix? `grid-template-columns` simply becomes `template-columns`, then it doesn't matter whether it's `display: grid`, `display: block`, or `display: masonry`, and we don't keep adding prefixed versions of what are essentially the same properties. Any property that doesn't work in a given context is, like all other unsupported CSS properties, simply ignored.
Then we have:
```css
article {
display: block; /* default value, unnecessary to state */
template-columns: 1fr 1fr minmax(15ch, 30ch) minmax(15ch, 30ch) 1fr;
default-column: 3 / 5;
}
```
And if we want to change `display: block` to masonry or grid, the other properties don't *have* to change, and the layout simply reflows per the context's other defaults.
--
GitHub Notification of comment by ShaunaGordon
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11060#issuecomment-2438294466 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 16:41:00 UTC