Tab Atkins Jr.

Hm, I think our intent was just that definite-placed items affected the size of the tracks they could theoretically have gone into. So, like, say you have masonry with 5...

I really don't like using the `activation`/`active` distinction like this. Differing just in tense isn't usually a good idea, as we don't usually communicate tense in our property names in...

It also interacts badly if you want to allow "auto-spanning", where an element will get a span based on its width. This might be a good mode to allow, possibly...

Nah, it's part of this issue - *if* we do auto-spanning (and I think Masonry libraries do sometimes have this feature), then variable-size tracks are even more problematic. (And it...

Would have to be the same size to actually work; a larger track size *usually* would make the item shorter (and thus more likely to fit), but not *always* -...

For @ethanjv's (1): yes, your displayed position options are exactly right. For (2), we'd pick the higher area in the first picture.

I agree that moving it to its own module makes the most sense now.

(tldr: complaints up top, counter-proposal near the bottom) I don't think this proposal works. If we were just talking about Flexbox and Grid, this seems pretty reasonable, to the point...

Ah, I'm not misreading, we're just thinking of the condition in opposite ways. My objection is partly semantic (this is using slack as a negative condition, while the other usages...

Ah, here's the positive-condition version of your dense proposal (I rewrote the above comment three times, and of course didn't think of this until after I hit Comment): `dense` forces...