- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 14 Apr 2016 18:35:09 -0400
- To: "www-style@w3.org" <www-style@w3.org>, "Eric A. Meyer" <eric@meyerweb.com>, Jen Simmons <jen@jensimmons.com>, Rachel Andrew <rachelandrewuk@gmail.com>
This is in reference to the following issues: https://drafts.csswg.org/css-grid-1/issues-wd-20150917#issue-25 Subgrids considered essential Eric Meyer, Rachel Andrews, Jen Simmons, et al. https://drafts.csswg.org/css-grid-1/issues-wd-20150917#issue-28 Concerns with subgrid Igalia https://drafts.csswg.org/css-grid-1/issues-wd-20150917#issue-31 Simplifying subgrids François Remy Proposal ======== Remove subgrid keywords and revert to adding a new display: subgrid Subgrids act exactly like grids, except: 1. grid-template-rows/columns have no effect on subgrids. They get their grid track definition (number of tracks, track sizes, and gaps) from their parent grid based on their final row/col span and position. 2. Subgrids have no implicit grid. Items placed outside the grid are an error, and invoke overly-large-grid clamping https://drafts.csswg.org/css-grid/#overlarge-grids to the declared span (or alternately, cover the entire subgrid, similar to erroneously-placed abspos items). Thus no items can leave the subgrid's explicit grid, and the subgrid's size is determined solely by its declared span in the parent grid--and is in no way dependent on its contents. 3. As a result, while grid-auto-flow still works to auto-place the subgrid's children in its explicit grid, grid-auto-rows/columns have no effect. 4. grid-template-area can be used to declare named areas, but its effect gets clamped to the size of the subgrid. When a subgrid uses grid-template-areas, it gets line names from that; if not, it acquires the appropriate named lines from its parent grid. Line names are not merged between the two grids. Issue: We could also allow local line names via grid-template-rows/columns, but this feature currently complicates the grammar of grid-template-rows/columns greatly, so lacking strong use cases we think it's better to disallow it for this level. Note: Since the subgrid item's placement is run after its own placement and does not affect its size, its position in the parent grid can be determined before item placement. 5. To support valuable use-cases like the product listing in http://blogs.igalia.com/mrego/2016/02/12/subgrids-thinking-out-loud/ and https://lists.w3.org/Archives/Public/www-style/2016Jan/0141.html we re-add multi-track repeating. repeat(auto-fill, ...) and repeat(auto-fit, ...) gain back a full <track-list> argument. Per the use-case, only full track-list repetitions are allowed; if tracks are dropped, the entire track-list group must be dropped. Similarly, grid-auto-rows/columns take a <track-list>, and has the same "repeat the entire <track-list> as a unit" behavior. Positioning of a subgrid in the parent grid is same as for any other grid item. If a subgrid is *not* a grid item in a parent grid, its 'display' value computes to 'grid'. When sizing a grid with a subgrid grid item: A. The subgrid itself is sized like it was *empty*, only taking up the space defined by its margin/border/padding. (Neither width and height constraints nor alignment properties have no effect on subgrids; as in the current spec, they are always stretched.) B. The subgrid's own grid items are sized in the parent grid as if they were the parent grid's grid items. (Similar to how they'd act if their parent was display:contents.) However... C. If one of the subgrid's grid items is placed in the subgrid's first/last track, it is treated as if it had additional margin on that edge equal to the subgrid's margin+border+padding on that edge. Note: A subgrid's m/b/p may end up being larger than the tracks it fills, once the Grid Sizing Algorithm is run. This is no problem; the results fall out of the above "just pretend the subgrid's children are grid items in the parent grid, with magic extra margin". The subgrid's children might no longer look like they're properly aligned within the subgrid, but they'll remain properly aligned *to the parent grid* (or as aligned as they can be, given their extra-big magic margin). Open issue: Do we want 'overflow' to apply to subgrids? It shouldn't affect layout, of course, but if it's easier to force-compute it to 'visible' we could do that. Rationale ========= The three critical features of a subgrid are a) Scoped positioning b) Arbitrary depth c) Automatic margin/border/padding pass-through See http://blogs.igalia.com/mrego/2016/02/12/subgrids-thinking-out-loud/ We did not remove the margin/border/padding handling because it is a fairly critical feature of subgrids. Discussion with Igalia at the CSS Grid workshop in February seemed to indicate that this is not so tricky as they thought; certainly it helped however to note that subgrids do not have width/height constraints and that whether an item gets additional m/b/p depends solely on its placement. :) We did address the concerns about implicit grid tracks and overflow tracks by removing that possibility and forcing auto spans to resolve to one. Moving subgrid to a 'display' type disallows having subgrid behavior in one axis only and emphasizes that subgrids have different layout properties from regular grids. We discussed the motivating examples in François Remy's proposal, but concluded that the “action at a distance” effect is somewhat dangerous, and much more so if nested to arbitrary depth. (Cousin subgrids can link up and influence each other, which may or may not be wanted; and if it is wanted, it's pretty fragile.) His proposal did raise an important problem, however: to address his perfectly reasonable use case, we do need to extend the auto-repetitions in Grid to handle multiple tracks. (See #5, above.) Major Use Cases Not Handled =========================== Requiring subgrids to work in both axes at once means the following use case cannot be handled: header header sidebar main footer footer where main is a catalog whose columns line up with content in the header and footer (and therefore need to be part of the main grid) but whose rows are auto flow, and therefore need to be independent of the main grid. Without single-axis subgridding, we can't add rows to main without disrupting the alignment of main to sidebar and the placement of footer. ~fantasai and TJ
Received on Thursday, 14 April 2016 22:35:38 UTC