[css-grid-3][Masonry] Auto repeat and other intrinsic track sizes

[alisonmaher]

In css-grid-3 is a tentative definition for sizing auto tracks within an auto repeat.

This means that repeat(auto-fill, auto) would be valid, but would auto repeat(auto-fill, auto) auto also be valid? If this should be valid, what about auto min-content repeat(auto-fill, auto) auto max-content or auto repeat(auto-fill, 100px) auto?

Currently, per css-grid-2, we force all tracks outside of an auto-repeat to be fixed. This potentially doesn't need to be the case, but I'm inclined to believe we should maintain this rule, even if we resolve to allow intrinsic repeaters, since that would incur quite a bit more complexity to the algorithm, and I'm not sure there is a good use case for this.

[fantasai]

We can always relax restrictions, so this seems OK.

[css-meeting-bot]

The CSS Working Group just discussed [css-grid-3][Masonry] Auto repeat and other intrinsic track sizes, and agreed to the following:

• RESOLVED: allow this syntax expansion for both masonry and grid, and come back with implementation experience

The full IRC log of that discussion

<andreubotella> alisonmaher: today we don't allow intrinsic track size next to an autorepeat
<andreubotella> .. now we're considering intrinsic autorepeats, now we want ...
<andreubotella> .. do we want to allow intrinsically sized tracks next to autorepeats?
<andreubotella> .. at first i thought it seemed reasonable, but if you start mixing intrinsicly sized tracks, it gets more complex
<andreubotella> astearns: are you saying masonry and grid should be consistent in this case?
<andreubotella> alisonmaher: yes
<TabAtkins> q+
<astearns> zakim, open queue
<Zakim> ok, astearns, the speaker queue is open
<andreubotella> TabAtkins: the implication of the speak is, we should be able to mix different intrinsic keywords in autorepeat
<andreubotella> .. we resolve by expanding all autorepeats once, do one quick layout that way, and we use that to determine how many repeats
<andreubotella> alisonmaher: maybe that wouldn't be bad
<andreubotella> TabAtkins: the old model, you only had one autorepeat, but with multiple it wouldn't be more complex
<andreubotella> .. the grid ones, trying to come up with a definition for what intrinsics do in repeat in grid is hard
<andreubotella> .. i don't know what to do with that
<astearns> ack fantasai
<andreubotella> fantasai: the masonry heuristics you have only makes sense if you repeat an auto track listing
<andreubotella> .. cause you had your spanning heuristic
<TabAtkins> s/an auto track/a single intrinsic track/
<andreubotella> fantasai: I don't feel very strongly about this, it's fine if we want to start with something more restrictive and expand later
<andreubotella> TabAtkins: I think for masonry there's no reason to have a syntax restriction
<andreubotella> .. whatever we had to do for grid to allow intrinsic sizes in autorepeat, we need to make sure it is consistent considering how we handle intrinsic sizes outside of autorepeat in grid
<andreubotella> fantasai: A typical case, you have a container with 200px, maybe you have intrinsic tracks, and you subtract that space, and figure out the numbre of intrinsic tracks
<andreubotella> .. if you have auto track outside of that range, how do you calculate the size of that track?
<andreubotella> .. if we have a count, we're making an assumption
<andreubotella> .. if you were creating a layout with one auto size track, and a repeat with auto sized tracks, this auto sized track in the end might not necesarily influence the others
<andreubotella> .. it seems a bit complicated
<andreubotella> TabAtkins: since this is for determining how many repetitions, and eventual layout doesn't pay attention to this
<andreubotella> .. and this whole thing is invalid in grid right now, so we're not compat constrained
<andreubotella> .. i'm fine with using the same behavior for intrinsic keywords inside or outside the autorepeat
<andreubotella> fantasai: I think in general, autorepeat with auto will give weird repeats if you have tracks outside of the repeater
<andreubotella> .. because the items in those tracks will influence the size but will not participate
<andreubotella> TabAtkins: in masonry there's no guarantee the items will cross between the specified and autorepeat tracks
<andreubotella> .. if you want to guarantee you have at least 3, you spell it auto auto, or autorepeat auto
<andreubotella> fantasai: we could also restrict the placement of items in some tracks but not others
<andreubotella> .. those items would not necessarily need to contribute to the stack of this range of columns
<andreubotella> .. assuming we had that feature, would we want it to work that way?
<andreubotella> TabAtkins: right now we force them into pretending to be autoplaced
<andreubotella> .. but that doesn't have to be the case forever
<andreubotella> fantasai: happy to defer to alison
<andreubotella> alisonmaher: convinced it's fairly doable
<andreubotella> .. and would be weird not autorepeat autofill auto
<TabAtkins> (use-case, if you want at least three auto tracks, could spell that `grid-template-columns: auto auto repeat(auto-fill, auto);`
<TabAtkins> )
<andreubotella> astearns: are we considering allowing this for both masonry and grid?
<fantasai> Didn't we take a resolution to have min/max repetition values? I vaguely remember discussing that... we should fish around and check
<andreubotella> TabAtkins: under the proposed behavior change for grid where we do allow intrinsic track sizing, yes
<andreubotella> .. everything we're adding now is invalid for grid right now
<andreubotella> fantasai: I'm somewhat inclined to not increase that syntax space right now
<andreubotella> .. to reduce the work needed for an initial implementation
<andreubotella> .. I don't have an objection, just worried about increasing the amount of work
<andreubotella> PROPOSED RESOLUTION: allow this syntax expansion for both masonry and grid, and come back with implementation experience
<andreubotella> fantasai: we could mark it at risk
<andreubotella> astearns: I prefer not marking it at risk until implementation experience says we should
<andreubotella> fantasai: marking things at risk means this is an area we might not get to
<andreubotella> .. if we have impl experience that says no, we remove it from the spec
<andreubotella> astearns: fair enough
<andreubotella> PROPOSED RESOLUTION: allow this syntax expansion for both masonry and grid with an at risk marker
<andreubotella> astearns: any objections?
<andreubotella> RESOLVED: allow this syntax expansion for both masonry and grid, and come back with implementation experience