1240834 - (subgrid) [css-grid] Implement layout support for "subgrid"

Status: RESOLVED FIXED

(Core :: Layout: Grid, enhancement, P3)

Description

[Daniel Holbert [:dholbert] (PTO until 2/24)]

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

https://drafts.csswg.org/css-grid/#subgrids

Comment 1

[Daniel Holbert [:dholbert] (PTO until 2/24)]

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/

Comment 2

[Daniel Holbert [:dholbert] (PTO until 2/24)]

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.
}
http://meyerweb.com/eric/thoughts/2016/01/15/subgrids-considered-essential/#comment-3048117

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

[Eric A. Meyer]

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

[Daniel Holbert [:dholbert] (PTO until 2/24)]

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

[Eric A. Meyer]

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.

Comment 6

[Jen Simmons [:jensimmons]]

Any update on how this is going? I hear subgrid will land in Nightly behind a flag soon. That would be very helpful. Estimates?

Comment 7

[Sean Voisen (:svoisen)]

(In reply to Jen Simmons [:jensimmons] from comment #6)
> Any update on how this is going? I hear subgrid will land in Nightly behind
> a flag soon. That would be very helpful. Estimates?

Hi Jen – Sorry for the delayed response here. Mats is actively working on it. I don't know that it will make it in Nightly for 64 (functional, but pref'ed off), however.

Comment 8

[Eric A. Meyer]

(In reply to Sean Voisen (:svoisen) from comment #7)
> (In reply to Jen Simmons [:jensimmons] from comment #6)
> > Any update on how this is going? I hear subgrid will land in Nightly behind
> > a flag soon. That would be very helpful. Estimates?
> 
> Hi Jen – Sorry for the delayed response here. Mats is actively working on
> it. I don't know that it will make it in Nightly for 64 (functional, but
> pref'ed off), however.

I’m not clear on what this means, Sean.  Do you mean subgrid won’t be available in any form in Nightly for 64, that it will be there but disabled by default, or something else?

Comment 9

[Sean Voisen (:svoisen)]

(In reply to Eric A. Meyer from comment #8)

> I’m not clear on what this means, Sean.  Do you mean subgrid won’t be
> available in any form in Nightly for 64, that it will be there but disabled
> by default, or something else?

Hi Eric – Sorry, let me clarify. At this point, subgrid will not make it into Nightly 64. The earliest subgrid will be available is in Nightly 65 and it will remain disabled (behind the layout.css.grid-template-subgrid-value.enabled preference) until the DevTools team has had time to ensure that the grid inspector will work with it. If all goes well during testing in the 65 cycle – we will flip the preference on in 66 and it will ship with 66.

Comment 10

[Eric A. Meyer]

(In reply to Sean Voisen (:svoisen) from comment #9)

> Hi Eric – Sorry, let me clarify. At this point, subgrid will not make it
> into Nightly 64. The earliest subgrid will be available is in Nightly 65 and
> it will remain disabled (behind the
> layout.css.grid-template-subgrid-value.enabled preference) until the
> DevTools team has had time to ensure that the grid inspector will work with
> it. If all goes well during testing in the 65 cycle – we will flip the
> preference on in 66 and it will ship with 66.

Excellent.  Thanks, Sean!

Comment 11

[Tantek Çelik]

Assigning to :mats as I expect he'll be the one to resolve it :) Are we still on for ship with 66? Or another build? Either way, when we know perhaps send an "Intent to ship" accordingly. Thanks!

Comment 12

[Sebastian Zartner [:sebo]]

As much as I'd like to see this implemented, I don't believe this feature can ship in 66. The layout code is not implemented yet and we're just a week away from the soft freeze for 66. But let's see what Mats says.

Sebastian

Comment 13

[Daniel Holbert [:dholbert] (PTO until 2/24)]

[I'm moving a few open subgrid-related bugs from blocking-this-bug to depending-on-this-bug, for easier categorization/visualization. We have bugs in both lists, but given that subgrid shipped long ago, it doesn't really make sense to think of bugs-in-the-feature as "blocking" it at this point.]

Comment 14

[Daniel Holbert [:dholbert] (PTO until 2/24)]

We might as well close this metabug as fixed, to better-indicate that subgrid has in fact already shipped (years ago).

(We can still use this bug for tracking subgrid-related issues, but it's confusing/misleading to have this bug open when we do in fact support subgrid.)