Re: [csswg-drafts] [css-grid-2] How to properly accommodate margin/border/padding of a subgrid with no item on the edges (#7465)

Okay, @fantasai and I resolved the issue in the first comment in https://github.com/w3c/csswg-drafts/commit/4bc828a3e535f12bbe02dae538741bafff763174 : we should indeed be generating separate hypothetical items for each edge, and not ever combining any, so that assymmetric MBP is handled correctly.

But looking into the actual browser behavior, as summarized by @mattwoodrow, we probably should simplify and match browsers. In short, the current browser behavior is just to insert a single span-1 hypothetical item into the first/last track, with size equal to the MBP on that edge.

This is definitely simpler, and probably fine in practice. In particular, because the subgrid's MBP is only attached (as "magic margin") to items in the outermost tracks when actually laying out the items, the current spec's behavior will give bad results whenever we try to include MBP in sizing tracks other than the outermost. For example:
    
```css
.grid {
  grid-template-columns: 10px auto;
  }
.subgrid {
    grid-column: 1 / -1;
    border-left: 50px dotted;
}
.grid-item {
    grid-column: 2;
    width: 50px;
}
```

In this example, the current spec will generate a hypothetical item that spans both columns, and is 100px wide. Since the first track is fixed, this will cause the *second* track to grow to accommodate the extra space, resulting in columns of 10px 90px. But then the actual grid item living in the second column just naively lays out into that 90px-wide space, without moving aside to avoid overlapping the border, so why did we change the column's size in the first place? Unless we spec "magic margin" that spills over into items in interior tracks in some cases, we wouldn't get a good result here anyway.

On the other hand, the current browser behavior works just as good in cases where the first/last track can grow, and when the first/last track is fixed (or capped at a too-small size), at least the items lay out reasonably even if the subgrid box itself is not drawn around them (rather than potentially having their tracks grow for mysterious reasons).

CC @fremy in case there's anything here we missed.  Agenda+ to discuss and potentially resolve on this behavior.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7465#issuecomment-1265913276 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 3 October 2022 19:17:05 UTC