[css-grid] Implement layout support for "subgrid"




2 years ago
3 months ago


(Reporter: dholbert, Unassigned)


(Depends on: 2 bugs, Blocks: 2 bugs, {dev-doc-needed, DevAdvocacy})

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [DevRel:P1], URL)



2 years ago
Bug 983175 added style-system support for "subgrid". Filing this bug on actually honoring "subgrid" styling in layout.



2 years ago
Blocks: 616605

Comment 1

2 years ago
Quoting Jen Simmons [:jensimmons] from bug 983175 comment #17:
> As authors are digging into how to use Grid, as industry leaders are writing
> their books about Grid, it seems like punting Subgrids is a bad idea. Even
> if including it means delaying Grid for months. There's not consensus yet,
> but a brewing question... Here's Eric Meyer's investigation, with usecases:
> http://meyerweb.com/eric/thoughts/2016/01/15/subgrids-considered-essential/
Keywords: dev-doc-needed

Comment 2

2 years ago
Note that "display: contents" gets around the core concern in Eric Meyer's blog post (being able to make grid items out of the grid's DOM grandchildren).  Two people already brought this up in the comments on his post, and his response is:
It’s interesting that display: contents can be used as a workaround for the lack of subgrid support, but this is exactly the problem I talked about at the end of the post: we’re already trying to hack our way around limitations, even before grids are fully public. This is what we do, and I love the impulse even as I recognize its downside. I really don’t want to see subgrids buried by hacks that take the place they should have filled.

Not to mention, while display: contents might work in this particular case, which is extremely limited by nature, my instincts are that it will not be exactly the same thing. Which is even worse, because if the display hack bends toward one coding pattern while actual subgrids bend toward another, it will be even harder to switch over from the hack to the proper approach. Far better to have subgrid support from the outset, and avoid trouble.

Seems like a lot hinges on whether his "not [...] exactly the same thing" instinct is correct or not.  If it ends up being pretty trivial to switch from "display:contents" to subgrid, then I think the we-can't-ship-grid-without-subgrid-support concerns that he's expressing are less compelling.

Comment 3

a year ago
Although if it ends up being trivial to replace subgrids with display: contents, then that implies subgrids aren’t nearly as hard to implement as has been argued, and it makes it a lot easier to ship with subgrid.

Comment 4

a year ago
For an author, it does seem pretty trivial to replace subgrids with display:contents, for use cases like the one in your post where the intermediate element doesn't need any special styling.

For a browser implementor, it's not that simple though (e.g. we can't just use display:contents under the hood) because we have to allow for the possibility that the subgrid itself has styling (like a border, or a transform, or relative positioning).  So the subgrid needs a box in the box tree, and its children also need to have boxes which participate in the subgrid's parent's layout. (Or grandparent, or great-grandparent, etc. -- depending on how deeply-nested the subgrid is.)

Comment 5

a year ago
Yes, for extremely limited use cases like I posted as an example, `display: contents` would generally suffice.  Not always, since the ability to style the intermediate element might be very useful, but certainly it could work in such simple cases.

But for any non-trivial use cases, `display: contents` is at best a letdown, and at worst the path to horrible hackery.  The exact things you identify as challenging for implementors are what make subgrids so useful to authors, and they make grid layout in general far more powerful.  With subgrids, an author can place a “module”—such as a story box on a news site, or an interface panel in a web app—into the page grid, style it, _and_ have the module’s contents align themselves to that same page grid.

Even better, if I’ve understood subgrids correctly, the contents align to the page layout’s grid lines using a line count that’s relative to their container, not the overall page.  So I can have an image in a subgrid that stretches from the subgrid’s second to fourth grid lines, no matter where the module lands.  It could start on the page grid’s first line, or its ninth.  The contents don’t need to know.

Without that, the CSS to make a given module’s contents line up with the page grid either has to be insanely complex, or modified on the fly via JS.  I suppose a third option is that the placement of modules would be severely limited in terms of placement and sizing, but that’s hardly appealing either.

So it appears my instinct was correct, and the existence of `display: contents` isn’t anywhere near sufficient to substitute for subgrids, as you made stated.


a year ago
See Also: → bug 1221677
Depends on: 1248227
Whiteboard: [DevRel:P1]
Flags: platform-rel?
platform-rel: --- → ?
platform-rel: ? → ---
Priority: -- → P3


6 months ago
Depends on: 1324493


3 months ago
You need to log in before you can comment on or make changes to this bug.