[css-grid-2] Dual-axis vs. Per-axis Subgrids

[fantasai]

This issue is a placeholder for discussion of dual-axis vs per-axis subgrids. General implementation concerns and author use cases are both welcome. Specific problems with the spec as it stands should be filed separately.

[rachelandrew]

These are some use cases I gathered prior to the Tokyo Face to Face https://codepen.io/rachelandrew/project/full/68cc7a5da9cfbb56c6e8366d7d92e6ba/XWYGMD/

[css-meeting-bot]

The Working Group just discussed Review state of Grid Level 2, figure out next steps.

The full IRC log of that discussion

<dael> Topic: Review state of Grid Level 2, figure out next steps
<fantasai> https://www.w3.org/TR/css-grid-2/
<dael> fantasai: Issue with grid L2 it has some proposals and no feedback. I can do anything to go forward
<dael> fantasai: Open issues are like here's 2 proposals for subgrid, which do we want?
<dael> fantasai: I wanted to bring this up because there's strong requests from the community to do this, but the spec for subgrid is there's 2 specs for subgrid. I don't know what to do next.
<dael> florian: Is there author feedback?
<dael> rachelandrew: I have feedback. Authors really want subgrid. The use cases I've seen are tied to dimension sub grid....the proposal that was pulled from L1 wouldn't solve them. People want the columns to be the sub grid. They don't want to define the rows. Having to locked to both dimenstions would be more frustrating then useful. Things I"ve seen assumed one dimension.
<dael> fantasai: Proposal is to resolve on per axis subgrids.
<dael> Rossen: Didn't we decide in tokyo?
<dael> tantek: We added it as a possibility in tokyo.
<dael> Rossen: sgtm. I thought we did that.
<dael> Rossen: This is the 1.5 dimension model?
<dael> fantasai: No, the way we set thing sup there's not many changes from one version to the other. Differences are in green. Main change is for per axis you need to ensure that if you're interweving the algo of the parent and child grids.
<dael> fantasai: Algo is all defined. That's where spec is at. I think it's complete mostly.
<dael> astearns: Do we have impl?
<dael> fantasai: I don't think anyone is working on sub grids.
<dael> TabAtkins: Mats was interested and opposed the non-per axis. That's what Igalia part impl.
<dael> rego: We didn't impl anything yet.
<tantek> Mats is working on it, see the Firefox subgrid meta bug (with dependent implementation bugs) https://bugzilla.mozilla.org/show_bug.cgi?id=1240834
<dael> fantasai: Syntatic difference the per axis has a subgrid keyword on grid-template-rows and grid-template-columns. Just one was a keyword on grid-template.
<dael> astearns: Would anyone object to single axis subgrid?
<dael> TabAtkins: No one has described how to do it yet.
<dael> fantasai: It's in the spec. Here's the algo (section 2.4)
<dael> astearns: It's spec as a diff to a doc with both.
<dael> fantasai: It inlines everything in. It just has two colors of ink.
<dael> astearns: Anyone besides TabAtkins have concerns on single axis subgrid.
<dael> rego: Seems more complex to impl but it would be good to know use cases. If there are clear use cases where we need this it's fine.
<dael> rachelandrew: I brought use cases to the last F2F but I rarely see something from an author that works for double axis. An ecommerce site that has a template where they want it to work no matter if there's 2 rows or 6 rows of stuff.
<dael> rachelandrew: Let me see if I can find the examples
<dael> astearns: Would people object to 2 axis subgrid?
<dael> florian: I think rachelandrew would.
<rachelandrew> https://codepen.io/rachelandrew/project/editor/68cc7a5da9cfbb56c6e8366d7d92e6ba
<dael> astearns: I'm hearing some people for and against single axis subgrid but I haven't heard opinions on 2 axis besides everyone thought it was too hard to get to for the first level of grid.
<tantek> IIRC, all variants of subgrid were too much for grid level 1
<rachelandrew> this is a better view, some examples https://codepen.io/rachelandrew/project/full/68cc7a5da9cfbb56c6e8366d7d92e6ba/XWYGMD/
<dael> Rossen: I still agree it was a good move to hold it back. To your second point as to if one or two axis is what we want, now that we can reason about it and think hoelistically the one axis is an easy shortcut to cover some use cases but during Tokyo I heard enough compelling reasons to have the per axis. I will admit I haven't reviewed spec. But I prefer the per axis one. I don't think there will be all that much work per axis, at least in our impl.
<dael> astearns: Perhaps we could leave it at peole should review the spec and look at the use cases and then come back soon?
<dael> rachelandrew: I could probably get more use cases now that people are using grid.
<dael> astearns: Is there an issue for choose which appoach?
<dael> fantasai: Yep.
<fantasai> https://github.com//issues/2280
<fantasai> github: https://github.com//issues/2280
<dael> astearns: I suggest we continue discussing in that issue.
<dael> astearns: Anything else?
<dael> fantasai: Whe do we want to return?
<dael> Rossen: End of F2F.
<dael> astearns: WE can try and bring this up end of Thursday. Then perhaps we can make a decision.
<dael> astearns: Please take breaks or lunch time if as you read you have questions.
<dael> dbaron: Would it help to get someone on a call.
<dbaron> s/someone/Mats/
<dael> fantasai: It would be good to have Mats look and reply on github.
<dael> fantasai: I haven't heard from him.
<dael> dbaron: If you want me to poke him can you send me what you want me to do?
<dael> fantasai: Review the spec and comment.
<dael> florian: Also express a preference? Or he always has.
<fantasai> fantasai: And if there's nothing wrong with it say it's good
<dael> astearns: Other part of grid L2 as aspect ratio contols
<dael> github: https://github.com//issues/1116
<astearns> github: https://github.com//issues/2280

[zellwk]

My main usage is to use subgrid for nested grids. Here's an article and a video detailing my usecase.

Furthermore, I believe single-axis subgrids are easier to work with. If we have single-axis subgrids, we can rely on browsers to create implicit grids—which means we can use autofill and autofit.

[rachelandrew]

I think one of the biggest issues with double axis subgrids is that it would make creating reusable components very hard. I would want to create a component that could accept variable amounts of content and be able to drop it into a variety of layouts. Tying the inner to the outer, and needing to change the outer based on the content of the inner would mean a lot of repetition in CSS to cope with this.

A quick demo of the issue is here: https://codepen.io/rachelandrew/pen/geEeaE

[meyerweb]

Here’s a use case from 1997, with two grid approaches to making it work without subgrids:

https://meyerweb.com/eric/css/examples/grid/mit-libraries.html

NOTE: that was assembled a while back for other reasons, so the page doesn’t discuss one- versus two-axis subgrids.

I was able to remake the example layout in Grid without subgrid, and have row and column tracks that could respond to contents, by flattening the HTML. As one does, now. That’s the first case shown

In the second case, the one with a good markup structure, I’m pretty sure I would want dual-axis subgrids instead of per-axis, but I may have misunderstood the terminology. As it was, without any subgrids, I had to layer three grids with each other, and enforce static track sizes in order to make sure everything lined up. I would have very much appreciated a subgrid feature that let me set up min-content or fit-content columns and rows, in the creation of that layout.

[stitchng]

I will go for dual-axis over per-axis

[MatsPalmgren]

I've implemented a prototype subgrid layout in Gecko and I figured I should give some feedback on it here.

The following features are supported:

• subgrids can be subgridded in either or both axes independently
• subgrids can be nested to any level
• full support for writing-mode - an orthogonal subgrid subgridded in its column axis attaches to its parent grid's row axis and vice versa
• line names in subgrid ancestors are overlaid onto the names in the subgridded axis
• line names can be specified in the subgrid axis using the subgrid <line-name-list>? syntax
• grid-template-areas are supported on subgrids, and are overlaid similarly
• grid-aligned abs.pos. children can be subgridded (for line name resolution)
• subgrids are fragmented the same as any other grid container

All of the above can be combined in arbitrary ways.

I followed the "Per-Axis Proposal" in "Characteristics of a Subgrid Item" for the most part, i.e. the subgrid itself contributes its border/padding/margin to the sizing of the edge tracks, but is otherwise transparent to track sizing of its container.
Subgrids do not have implicit tracks (in a subgridded axis), all lines are clamped to its explicit grid, which is the extent of the subgridded axis.
I disregarded point 'g', 'h' and 'i' in the spec. I don't see any need to impose such restrictions on the subgrid box itself. It behaves exactly as any other grid item when it comes to flowing/aligning/positioning it.

I implemented the above prototype in roughly three weeks full time. I mention this because I think it demonstrates that the "Per-Axis Proposal" is fairly straight-forward to implement and the primary motivation for the "Dual-axis Proposal" was that the the "Per-Axis Proposal" would be too complicated to implement. The existing Grid algorithms for line name resolution and track sizing are already axis-independent and introducing support for subgrid into them results in the "Per-Axis Proposal" almost automatically. I don't see any wins from an implementor's perspective in the "Dual-axis Proposal".

So based on that implementation experience, I propose the following:

1. remove the "Dual-axis Proposal" - I don't think that it makes it any easier to implement subgrid and the "Per-Axis Proposal" is fairly straight-forward to implement anyway, as demonstrated
2. remove g, h and i from "Characteristics of a Subgrid Item" -
   I don't see any motivation for these restrictions. It just means more code to write and maintain. I'm pretty sure authors will make use of unrestricted subgrid box sizing/alignment/positioning in interesting ways... :-)

That's the broad strokes - I'll try to provide more detailed feedback on this implementation later.

Secondly, I also wanted to mention that I see some opportunity for a new feature related to subgrid layout. The grid placement algo has an 'occupied' state for each cell in the grid. Currently, a subgrid item occupies the full extent of its grid area. It would be fairly trivial to support stenciling/masking these bits to/from the grid/subgrid. That way, we could make subgrid items avoid being placed in cells that are already occupied in the outer grid. We could also make items in the outer grid be placed inside the boundaries of the subgrid that weren't occupied by items inside the subgrid. In case that would useful... :-)

[mrego]

Amazing feedback @MatsPalmgren! We were not so sure about how it would work, but if you have already implemented it I guess there's no doubt that the only choice should be per-axis approach.

Also from the use cases it seems that there are clear needs to suport the per-axis approach too.

Just as a note due to a previous comment, the dual-axis proposal is included in the per-axis if you just set subgrid in both axes.

[css-meeting-bot]

The Working Group just discussed Dual-axis vs. Per-axis Subgrids, and agreed to the following resolutions:

• RESOLVED: Remove the duel-axis proposal
• RESOLVED: Publish a new WD of Grid L2 with the removed duel-axis proposal

The full IRC log of that discussion

<dael> Topic: Dual-axis vs. Per-axis Subgrids
<dael> github: https://github.com//issues/2280
<tantek> Note also that Mozilla (mats) now has a public intent to implement on subgrid (on dev-platform)
<dael> Rossen: We took time to review and there's impl feedback from Mats that per-axis makes sense and is implementable. So we either can discuss more or resolve.
<dael> Rossen: Anything remaining to discuss in this issue before we move to adopt this?
<dael> Rossen: Objections to publishing Grid L2 with the per-axis subgrid model?
<dael> ChrisL: Is that fpwd?
<dael> Rossen: It is.
<dael> Rossen: Is it?
<dael> Rossen: Did we not publish the original fork?
<dael> fantasai: We did.
<dbaron> https://www.w3.org/TR/css-grid-2/
<dael> Rossen: So it's an updated WD.
<dael> Rossen: Are there objections to adopt the per-axis model and publish a WD?
<dael> rego: There are clear use cases and mats has a working sample. He is asking to remove a section and add that hte duel axis is included.
<dael> Rossen: I'd like to publish as is and then open invidiual issues against it.
<dael> Rossen: Other comments?
<dael> tantek: You don't want to make Mats' changes before publishing?
<dael> Rossen: We open them as separate issues.
<dael> fantasai: Mats is asking to loosen it a bit.
<dael> fantasai: We need a resolution to remove the duel-axis proposal.
<dael> Rossen: Objections to removing the duel-axis proposal?
<dael> RESOLVED: Remove the duel-axis proposal
<dael> Rossen: The second issues, removing g,h, and i from subgrid shoudl that be a separate issue?
<dael> fantasai: I'm happy to remove i, g and h I don't understand.
<dael> Rossen: That's why I suggested a separate issue.
<dael> fantasai: I don't have a problem discussing and republishing in 2 weeks.
<dael> Rossen: Objections to publishing a new WD of Grid L2 with the removed duel-axis proposal?
<dael> RESOLVED: Publish a new WD of Grid L2 with the removed duel-axis proposal
<dael> Rossen: People someone open the g,h,and i as a new issue.

[fantasai]

Thanks for all your feedback, @MatsPalmgren! I just checked in edits to remove the dual-axis proposal in favor of the per-axis proposal, as you recommended. I also removed the allowance to ignore overflow (item i).

Wrt removing g and h, I don't understand what it would mean for a subgrid to not be stretched or to have its tracks aligned in a manner that isn't controlled by the parent grid, so I did not make any changes to those items. Please file a separate issue on those with a better explanation of what's expected to happen if we lift those restrictions if you think something there needs to change. :)

Thanks~