Re: [css-grid] Could a simpler subgrid lead to more implementer interest?

On 01/20/2016 03:21 PM, Francois Remy wrote:
>
> 1.Since subgrids can contain subgrids, technically it is possible
> to have to align on the main grid all descendants of the grid
> container through nested subgrids
>
> 2.Each subgrid layer can have its own padding and margin, so you
> have to keep track of possibly a high amount of information to
> layout correctly the descendants in the main grid

I think these two are critical features for subgrids.

> 3. Worse, when mistakes happen and subgrids have to resort to an
> implicit grid, they can potentially imbalance the whole main grid
> stack, and create completely buggy layouts, since there are no
> strong boundaries on the edges of the subgrid. Technically, I am
> pretty sure a subgrid item can even force to create an implicit
> grid track on the main grid.
> ...
> Firstly, dealing with the implicit grid in subgrids is a pain,

I'm not sure why this is a problem, given any grid item can cause
the creation of implicit lines in the grid. But I don't much care
about this functionality...

> Secondly, the layout of subgrids cannot be done, even partially,
> in parallel with the main grid, since the tracks have no inner
> definition on the subgrid, which means the entire layout has to
> be defined on the parent grid, that’s awful if you have more
> than one possible item variant.

A lot of things here can be parallelized:
   * placement within each subgrid can be parallelized
   * sizing within each item in the grid+subgrid set can be parallelized
   * sizing of each track in the grid+subgrid set can be parallelized

> Finally, there are a lot of second-order issues you have to deal with.

Imo these are fairly straightforward issues that we can resolve and
not something to get worked up over. :)

> What do you do when subgrids have different row-gaps?

2 options:
   * always use the grid-gap of the parent row
   * create an 'auto' value for grid-gap that inherits to subgrids,
     and use the computed grid-gap for the relevant grid/subgrid.
     (Gaps would be treated equivalent to margins on items instead
     of equivalent to extra tracks in this model.)

> What do you do about positioned elements and their anchors?
> Technically they are laid out in the main grid but they are also
> children of their parents who could have position:relative…
> Those questions are not easy to answer and I am not sure the spec
> answers them all.

I think you would position the absolutely-positioned elements
contained by the subgrid against the subgrid area, with each
cell reduced from the main grid by the appropriate amount of
margin/border/padding.

If you're talking about the static position... probably the
analogous thing to the static position in main grid also makes
sense.

> The reduced-subgrid proposal I would like to make is the following
> one: when the grid items have been put into their row/column
> positions, for each set of track where more than one reduced-subgrid
> element lies, the width and height of the subgrid tracks is
> automatically increased to the maximum width or height among the
> corresponding track for all items in the track set which feature
> the exact same explicit grid layout. Implicit grids, margin, and
> padding are considered as some kind of subgrid tracks and will be
> normalized equally (sorry, this is unclear but I don’t know how
> to explain it using words, pictures will help).
> ...
> The first part of the layout consists in putting the ProductGridItem
> into cells of the ProductGrid.
>
> The second part is to notice that for the first row, there are
> three reduced-subgrids sharing the same sub-row structure:
> padding-1-2-3-padding. The height of each padding-top is then
> normalized to the max padding-top among those three products
> (here all are 10px), then the height of the heading rows is set
> to the tallest heading row, ditto for all following rows and
> the bottom padding.

I think this is a very interesting approach, and while I don't
think it will solve all use cases, I do think it will make a
bunch of them much easier to solve.

> This produces the #2 use case I presented before. Producing the
> #1 use case (LABEL>INPUT column align) using the same methodology
> doesn’t look difficult.
>
> The advantage is that we limit the syncing to one level. Syncing
> can happen recursively but only one level at a time.

I think this is a major limitation of the proposal. In general in
CSS, we allow authors to introduce unstyled elements into the tree
which, if they do not affect grouping, do not affect the layout.
This proposal does not have that ability, which I think is important.

> Another advantage is that if an author makes any mistake, the
> product which has to introduce implicit grid cells will have
> a different grid layout and will not participate in the alignment,
> reducing the damage to itself. Since it cannot escape its own cell
> in the parent grid, it cannot mess up the layout of other grid
> items by using cells they would otherwise have used.

I think this is a very useful property of your proposal. It's also
useful that it doesn't require the author to declare what's happening
inside these items at the top level of the grid--in a lot of cases,
that will make for code that is easier to maintain.

I think there's a bit of a conflict here between two ways of approaching
the subgrid problem:
   1. A lot of designers think about their page in terms of a master grid,
      and want to be able to reference that master grid throughout the
      page layout. For this we need to be able to take named lines down
      from the parent grid into descendants.
   2. In other cases we want to be able to put things into the grid and
      have similar items align to each other, but ideally not have to
      mess with the master grid.

The current subgrid proposal addresses #1. Your proposal addresses #2.
I think we need to address both concerns...

There's a lot of things I *like* about your proposal. I think it makes
subgrids way easier to use for case #2.

I wonder if there's a way to combine the two approaches into something
coherent.

~fantasai

Received on Sunday, 28 February 2016 22:32:19 UTC