[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

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