[css-grid] Reduced Subgrid Proposal

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