- From: Mats Palmgren via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Jan 2020 22:32:20 +0000
- To: public-css-archive@w3.org
> Just to be clear, the masonry axis has no explicit tracks, right? Everything's effectively placed into implicit tracks?
Right, the line name resolution + "hypothetical grid-placement" steps are done as if `masonry` were `none`. Note that this grid is an illusion though, there are no tracks in the masonry axis. The purpose of the grid-placement step is to resolve (some) auto-positioned items into definite tracks in the grid-axis for the intrinsic track sizing step. Only items placed into the hypothetical first implicit track keep their resolved auto-position, other auto-placed items don't. The subset of items with a definite position in the grid-axis goes into the track sizing step and contributes to the intrinsic sizing. So for example:
```html
<style>
.grid {
display: inline-grid;
grid: masonry / auto;
}
x { background: silver; }
y { background: lime; width:100px; grid-row: 1; }
</style>
<div class="grid">
<x>x</x>
<y>y</y>
</div>
```
This makes the column size 100px. Removing `grid-row: 1` makes is the size of "x" and the y element overflows.
Currently, I'm also handling the items that are were placed at first implicit line specially in the masonry layout step. They are sorted before other items and they all start at position zero. This has two effects, a) you can make these items in this first hypothetical track intentionally overlap. E.g., using `grid-area: 1/1` above and adding more `<y>` items would make them all overlap. This may not seem very useful at first glance, but it's actually quite useful in creating a stacked tab-panel type of layout where you want the size to be the maximum of the children. (`<x>` would then follow after the largest `<y>`). And b) it moves the `<y>` element to the start, which seems like the least surprising layout.
> I'm not sure I understand from this description how auto-placed items interact with definite-placement items.
Items with an auto-placement in the grid-axis gain a definite placement only if they end up in the first hypothetical track in the masonry axis. Otherwise, they are still considered auto-placed and will not contribute to track sizing. There's a sorting step before masonry layout starts. The `masonry-auto-flow: [ definite-first | ordered ]` controls if items with a non-auto grid-axis placement should be placed first or not (the actual line number isn't considered just if it's auto or non-auto, the set is already sorted in _order-modifed document order_ to begin with and this is a stable sort).
> In your first example, what would happen if item 4 said "grid-column: 2;"? What about item 2 or 6?
No change. No change. With `grid-column: 2` on item 6:
In the above: items 1,2,3 are attached the first implicit line in the masonry axis, so they are placed first. Then item 6, because it has a definite placement in the grid-axis. Then 4 and 5 since the are auto-placed in the grid-axis. Items 1,2,3 and 6 have a definite grid-axis placement when masonry layout starts so we simply position them in the requested column at the minimum position possible for its span extent.
That's the behavior with `masonry-auto-flow: definite-first` which is the default. With `masonry-auto-flow: ordered` you get:
> Do they just get placed after all the masonry-placed items, which are presumably all in the first implicit column?
Yes, all items with definite placement first, then auto-placed. The auto-placed items don't really have a column yet. It's resolved by the masonry layout step while honoring the `masonry-auto-flow: [ pack | next ]` preference for the positioning.
So, perhaps it's confusing to use the term _track_ at all in the masonry axis since there really aren't any tracks there. It's a continuous layout. I think it's still useful to have a "first implicit line" there though. It's convenient for intrinsic sizing purposes with auto-placed items, and it allows overlapping items at this line.
It's also useful to have a line at the start/end of the items in the masonry axis for abs.pos. items to align to, although I'll punt on the exact details of that for a bit. (Currently, I'm resolving `grid-row:auto/1` from the padding edge to the start of the first implicit line, and `N > 1` to the last implicit line.)
Example:
```html
<style>
.grid {
display: inline-grid;
grid: masonry / 100px;
padding: 40px;
position: relative;
border: 1px solid;
}
a {
position:absolute;
inset: 10px;
border: 3px dashed red;
}
y { background: lightgrey; }
</style>
<div class="grid">
<y>y</y><y>y</y><y>y</y>
<a></a>
<a style="grid-row-end: 1; border-color: blue"></a>
<a style="grid-row-start: 2; border-color: black"></a>
</div>
```
Result:
> For repeat(auto-fit), is there really a case that would differ here? An empty track would be at minimum run, right
Correct.
> so the only way it could possibly be empty is if there just aren't enough elements in the grid to reach that track; there's no dependence on the layout size of the elements.
Consider:
```html
<style>
.grid {
display: inline-grid;
grid: masonry / repeat(auto-fit, 100px);
width: 300px;
border: 1px solid;
}
x { background: silver; }
</style>
<div class="grid">
<x>1</x>
<x>2</x>
<x style="grid-column:span 2">3</x>
</div>
```
Item 1 and 2 have equal height so masonry layout places item 3 in column 1 (it doesn't fit in column 3 since it has `span 2` and the grid only has 3 columns). With `<x style="height: 4em">1</x>` though, the desired result is that item 3 is placed in column 2. We don't know until after we have flowed and placed all items preceding item 3 whether it's the former or latter case.
--
GitHub Notification of comment by MatsPalmgren
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4650#issuecomment-572290067 using your GitHub account
Received on Wednesday, 8 January 2020 22:32:22 UTC