Re: [csswg-drafts] [css-grid-2] Dual-axis vs. Per-axis Subgrids

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 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 sugrid axis using the [`subgrid <line-name-list>?`](https://www.w3.org/TR/2015/WD-css-grid-1-20150317/#track-sizing) 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"](https://drafts.csswg.org/css-grid-2/#subgrid-items)  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' ](https://drafts.csswg.org/css-grid/#auto-placement-algo) 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... :-)

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

Received on Wednesday, 11 April 2018 18:13:41 UTC