[css-grid-3][masonry] Initial value of track listing for masonry grid axis

[fantasai]

The initial value of grid-template-columns is none, which ends up creating as many tracks as there are template areas, sizing them per grid-auto-columns.

Tab's Alternate Masonry Proposal instead uses an initial value of repeat(auto-areas, auto) which repeats auto to match the template areas (ignoring masonry-auto-tracks), and falls back to repeat(auto-fill, auto)... which is technically not defined atm, since auto depends on explicit placement.

What should the initial track listing be for masonry layout?

[tabatkins]

Yeah, we lost the definition of how to handle intrinsic track sizes during repetition when we figured out the compromise layout algorithm. I've set down what I think is a reasonable definition (basically just restoring the old behavior from my draft) in https://drafts.csswg.org/css-grid-3/#masonry-intrinsic-repeat, along with an explanation of why the definition is the way it is.

This has been spot-reviewed by @bfgeek, but not yet by the MS engineers actually doing the experimental implementation.

[fantasai]

OK, split out the question of whether/how to define auto-repeats into #10915 ; leaving this issue to just the question of what the initial value should be (assuming both are possible).

[css-meeting-bot]

The CSS Working Group just discussed [css-grid-3][masonry] Initial value of track listing for masonry grid axis.

The full IRC log of that discussion

fantasai: we just talked a bunch about this
... 2 options we have contemplated for masonry layout
... a: be consistent with grid and leave as none which yields single track
... b: do auto sizing auto fill thing that we were just talking about
... jensimmons and I suggest current initial value
... which we see use cases for auto fill auto behavior
... we don't think it would make a good initial value
q+
astearns: for my clarification, initial value of grid-tempalte-columns is none
... whatever we decide masontry trigger to be, computed value for g-t-c could become this new value?
q+
TabAtkins: there's back compat constraints we need to worry about but nothing we can't do
ack miriam
miriam: currently the default in grid, initial value is none
... which falls back to grid-auto-columns and areas
... assuming those aren't set
...we end up with similar issues
... where default for g-a-c is auto
... and we end up 1 column
... not an ideal default
...wish again we had some smarter auto in grid
... probably too late to change that
... but that makes me base my answer on how good this other option is
astearns: your answer is?
miriam: we've been talking about variants on this alternative
... I need to know details of it to know if it can be better than what I consider current broken behavior of grid
ack jensimmons
jensimmons: feel storngly that chanigng default for masonry use cases would be a mistake
... not going to be an incredibly great default that will give people good looking stuff right away
... will often be chaos already and people need to figure out why
... also think people get started, write some code, switch to masonry, now code you wrote is doing something and you don't know hwy
... eg. meaning of g-t-c changed
... though that might be less strong an argument if default auto is great, it just isn't now
q+
... while what miriam is true that if you set auto your layout is half done, that'd be great
... but reality is you have to write more
(or at least not broken in the single column)
yeah definitely agree that Grid was right to not try and guess
as much as it kinda sucks in practice sometimes
... with masonry it would be very confusing... one thing to say, you don't have a layout because you haven't made one
... vs why do I have this layout that looks chaotic, now what do I do with it
... I have to size all my items?
... not a route people should have to go down
... I think what fantasai said is true, better to leave people with no layout
I wasn't asking for grid to guess at tracks, I just want an auto that doesn't blow things out
... rather than make them get rid of bad layout they have to get to layout they want
... if it's not hard to implement repeat auto I don't have a problem with it
... meanwhile I don't know about making it the default
ack astearns
astearns: one of the things jensimmons said made me think about ...
s/I don't know about/no on
... I've set up a 3 column grid
... and it looks sort of what I want but what I really want is masonry
... if the auto is the default, does it override my 3 columns?
fantasai: no
astearns: ok then never mind
jensimmons: the only way people would get this auto default is if they enter right formatting context and *do not* create columns or rows, and trigger masonry and then go to tackle columns
... which some people will do, but I think authors will do what astearns said, start by defning columns, then trigger masonry, then continue
astearns: I think there might be some value in having as little change as possible on that grid to masonry switch
note: that depends on the not-yet-decided "masonry switch". if it's `display:masonry`, then it's trivial to get this situation
.. switch to masonry thing might change, but if you set columns ... being able to switch back and forth without having it do something for you would be more intuitive
(i also continue to push back on the idea that Grid is a meaningful/useful *fallback* for Masonry.)
(it requires a somewaht careful hand to make that work well, actually)
iank_: push back a little on that specific point, the switch between grid and masonryu in my mind is big
... changing how things pack, size, etc
... so still a big switch between modes
(so it *can* be used, in an @supports kinda way, but it's not really suitable as a general "automatic" fallback)
... so this is still a sueful default for a lot of people
... degenerate case you still get columns
... we can work on how useful this will be for web developers
fantasai: 2 things we can do here are
... straw poll or leave it until we close other issue
astearns: c) leave until we decide on other issue and masonry switch
TabAtkins: leave for now is fine
+1