[css-grid][masonry] repeat(auto-areas)

[fantasai]

Tab's Alternate Masonry Proposal introduced a new auto-areas keyword for the repeat() function, which repeats the given track listing as many times as necessary to accommodate the named template areas.

Opening this issue to discuss whether we want to add it to Grid/Masonry.

Note that the effective grid/masonry-auto-[tracks] property applies to this case already.

[tabatkins]

Elika pointed out privately a feature of Grid 1 that I'd completely forgotten about (described in the section they link) - the explicit grid is sized by the larger of grid-template-areas and grid-template-rows/columns. If grid-template-areas gives a longer list in an axis than you've provided via grid-template-rows/columns, then the remaining tracks are sized by grid-auto-rows/columns, but are still considered part of the explicit grid.

So, auto-areas isn't actually needed for the purpose of filling in tracks to match the areas list; the existing initial values of the relevant properties work just fine.

However, auto-areas does one additional important thing, which is fall back to auto-fill if there are no named areas; this is not done by the default Grid values. This means that, by default, a masonry will fill with as many auto columns as it can fit (and it can tell how large auto is since its placement and sizing are intertwined). This isn't done in Grid - by default, a Grid will end up with an empty explicit grid, and an implicit grid sized to either the largest span or the largest definition position.

I think this remains an ideal default behavior for Masonry containers.

[fantasai]

@tabatkins I think deciding the initial value of the tracks for masonry is a separate issue, please file it separately. ^_^

[tabatkins]

Regardless of whether it's the initial value or not, my comment still stands here - it provides a useful behavior for Masonry that is not reproducible without the value.

[mirisuzanne]

It does seem to me like this value might be useful in both masonry and non-masonry tracks. But I would expect it to fall back to auto-fit rather than auto-fill. I find it's very uncommon for authors to want extra empty tracks, when there's no content to put in those tracks.