Closed Bug 1240834 (subgrid) Opened 8 years ago Closed 1 year ago

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

Categories

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

enhancement

Tracking

()

RESOLVED FIXED

People

(Reporter: dholbert, Unassigned)

References

(Depends on 1 open bug, Blocks 7 open bugs, )

Details

(Keywords: dev-doc-complete, DevAdvocacy, Whiteboard: [DevRel:P1])

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
Blocks: css-grid
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/
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.
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.
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.)
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.
See Also: → 1221677
Depends on: 1248227
Whiteboard: [DevRel:P1]
Flags: platform-rel?
platform-rel: --- → ?
platform-rel: ? → ---
Depends on: 1324493
Depends on: 1447166
Depends on: 1452368
Depends on: 1452383
Depends on: 1465290
Depends on: 1465296
Depends on: 1466358
Blocks: 1470462
Depends on: 1471758
Any update on how this is going? I hear subgrid will land in Nightly behind a flag soon. That would be very helpful. Estimates?
Whiteboard: [DevRel:P1] → [DevRel:P1][layout:p2]
Blocks: 1496502
(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.
(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?
(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.
(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!

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!

Assignee: nobody → mats
Flags: needinfo?(mats)

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

Whiteboard: [DevRel:P1][layout:p2] → [DevRel:P1][layout:backlog:2019q2:68]
Depends on: 1544896
Type: defect → enhancement
Blocks: 1547564
Blocks: 1547560
Depends on: 1548421
Depends on: 1548709
Depends on: 1558705
Depends on: 1558512
Depends on: 1569628
Depends on: 1590218
Whiteboard: [DevRel:P1][layout:backlog:2019q2:68] → [DevRel:P1]
Alias: subgrid
Depends on: 1761761
Assignee: MatsPalmgren_bugz → nobody
Flags: needinfo?(MatsPalmgren_bugz)
Severity: normal → S3
Blocks: 1800563
Blocks: 1800566
Blocks: 1700254

[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.]

No longer depends on: 1548709, 1590218, 1761761
Component: Layout → Layout: Grid

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.)

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Blocks: 1842312
Depends on: 1844182
You need to log in before you can comment on or make changes to this bug.