In the grid level 2 spec,
the sum of the subgrid’s margin, padding, scrollbar gutter, and border at each edge are applied as an extra layer of (potentially negative) margin to the items at those edges. This extra layer of “margin” accumulates through multiple levels of subgrids. Meanwhile, half the size of the difference between the subgrid’s gutters (row-gap/column-gap) and its parent grid’s gutters is applied as an extra layer of (potentially negative) margin to the items not at those edges.
and then the spec says
For each edge of a non-empty subgrid, to account for the subgrid’s margin/border/padding (and any scrollbar gutter) at that edge, a hypothetical item is contributed to the track sizing algorithm for each span size in the set of items spanning into the occupied track closest to that edge of the subgrid.
For the second quote, there are wpt tests that ensure that we handle a subgrid's margin/scrollbar/padding even in an completely empty grid, so I wonder if we need to expand this to an empty grid, as well, to match implementations.
In either case, the spec doesn't mention what happens to a subgrid's gap sizes if there are no items in a given track (or if the subgrid is empty). This is particularly problematic now that we support gap decorations.
For example, say you have the following test case:
<style>
.grid {
display: inline-grid;
grid-template-columns: repeat(3, auto);
background: orange;
height: 100px;
}
.subgrid {
display: grid;
grid-template: auto / subgrid;
margin-left: 20px;
margin-right: 20px;
column-gap: 30px;
column-rule: solid red;
height: 50px;
}
</style>
<div class="grid">
<div class="subgrid" style="grid-column: span 3; background: blue;">
<div class="subgrid" style="grid-column: span 2; background: green;"></div>
</div>
</div>
This renders as follows in Chromium:
If you apply the track size overlay in devtools, you can see that the gap decorations overflow the first dotted track:
Firefox renders something similar to Chromium (minus the decorations), and Safari produced something a bit different:
The reason we get the results we do in Chromium is that tracks are sized as follows, per the current spec (since there are no items):
- Track 1: 20px (blue subgrid's margin start) + 20px (green subgrid's margin start) = 40px
- Track 2: 20px (green subgrid's margin end) + 30/2 (half the blue parent's gap) = 35px
- Track 3: 20px (blue subgrid's margin end)
Because the spec only accounts for subgrid gaps in track sizing when there are items (or a subgrid's margin accumulation calculation happens to land on a parent gap), the gaps can end up overflowing the track. This seems like a bug to me, especially given that we now have decoration support.
My proposal would be to expand the spec to include gap handling for subgrids, even if there are no items in that track.
This would mean that in the test case above, we'd instead get:
- Track 1: 20px (blue subgrid's margin start) + 20px (green subgrid's margin start) + 30/2 (half the gap) = 55px
- Track 2: 20px (green subgrid's margin end) + 30 (full gap) = 50px
- Track 3: 20px (blue subgrid's margin end) + 30/2 (half the gap) = 35px
This way, the subgrid gaps should never end up overflowing the tracks it inherits.
cc @tabatkins @fantasai
In the grid level 2 spec,
and then the spec says
For the second quote, there are wpt tests that ensure that we handle a subgrid's margin/scrollbar/padding even in an completely empty grid, so I wonder if we need to expand this to an empty grid, as well, to match implementations.
In either case, the spec doesn't mention what happens to a subgrid's gap sizes if there are no items in a given track (or if the subgrid is empty). This is particularly problematic now that we support gap decorations.
For example, say you have the following test case:
This renders as follows in Chromium:
If you apply the track size overlay in devtools, you can see that the gap decorations overflow the first dotted track:
Firefox renders something similar to Chromium (minus the decorations), and Safari produced something a bit different:
The reason we get the results we do in Chromium is that tracks are sized as follows, per the current spec (since there are no items):
Because the spec only accounts for subgrid gaps in track sizing when there are items (or a subgrid's margin accumulation calculation happens to land on a parent gap), the gaps can end up overflowing the track. This seems like a bug to me, especially given that we now have decoration support.
My proposal would be to expand the spec to include gap handling for subgrids, even if there are no items in that track.
This would mean that in the test case above, we'd instead get:
This way, the subgrid gaps should never end up overflowing the tracks it inherits.
cc @tabatkins @fantasai