Re: [css3-grid] Notes from the Grid discussion

On Tue, Nov 27, 2012 at 12:11 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> The following are notes from the grid discussion that took place between
> me, fantasai, Peter Linss, Rossen Atanov, and Phil Cupp last week.  We
> discussed three major issues with Grid and how we will resolve them in the
> near future: positioning (with named lines, etc.), non-positioned contents
> of a grid, and non-child grid items.
>
> Positioning
> =========
> * We're changing from grid-row/row-span/col/col-span to
> grid-start/end/before/after.
> * Grammar is "grid-*: offset? && [ <integer> || <string> ]", where:
>     * <integer> by itself refers to the nth line, counting from the named
> edge
>     * <string> refers to the first line of that name, counting from the
> named edge
>     * <integer> <string> refers to the nth line of that name.
>     * "offset" in the property means you start counting from the line
> specified by the other property in the pair, *toward* the named edge.
>  (Don't yet know what it means to have both properties in the pair be an
> offset.)
>
> So, given a grid with a single row and the following lines:
> +--+--+--+--+--+--+--+--+
> |  |  |  |  |  |  |  |  |
> A  B  C  A  B  C  A  B  C
> |  |  |  |  |  |  |  |  |
> +--+--+--+--+--+--+--+--+
> (this is an 8-column grid, with 9 lines between and around the columns)
>

It's hard to understand the below without understanding how the lines get
named.  Also, why are you able to repeat the names of lines? That seems
unnecessarily confusing.

What do we gain from adding lines instead of keeping it just grid areas?
Most of your examples below seem much more confusing to me in the new
syntax.


> The following declarations are equivalent to the following old
> declarations:
>
> grid-start: 'C'; grid-end: 'C';
> ==>
> grid-column: 3; grid-column-span: 6;
>
> grid-start: 'C'; grid-end: offset 'C';
> ==>
> grid-column: 3; grid-column-span: 3;
>
> grid-start: offset 'C'; grid-end: 'C';
> ==>
> grid-column: 6; grid-column-span: 3;
>
> grid-start: offset 'C'; grid-end: offset 'C';
> ==>
> ???
>
> grid-start: 5; grid-end: 'C';
> ==>
> grid-column: 5; grid-column-span: 4;
>
> grid-start: 5; grid-end: offset 'C';
> ==>
> grid-column: 5; grid-column-span: 1;
>
> grid-start: 8; grid-end: 8;
> ==>
> ??? (invalid at computed-style time, because they describe a negative span)
>
> grid-start: 'B' 2; grid-end: offset 1;
> ==>
> grid-column: 5; grid-column-span: 1;
>
> A note - it makes a lot of sense, I think, for grid-end/after to count
> from the end/after when doing named lines.  It seems slightly confusing,
> though, when using numbers.  It seems like "grid-start: 3; grid-end: 5;"
> should mean a cell that starts at the 3rd line and spans two columns.
>  Maybe the direction needs to be controllable, like with an optional "from
> [start | end]" clause on grid-start/end?  On the other hand, you could
> write the preceding as "grid-start: 3; grid-end: offset 2;" or "grid-end:
> 5; grid-start: offset 2;", so perhaps it's fine that you don't have an
> explicit ability here.
>
> Alternately, just allow negative numbers which switch things around?  I
> could see, for example, a cell wanting to position itself with its start
> edge at the last "B" line, and spanning 1 column.  You can't do that in the
> current syntax, but with negative numbers you could do "grid-start: 'B' -1;
> grid-end: offset 1;".  With the keywords, it would be "grid-start: 'B' from
> end; grid-end: offset 1;".
>
> Template areas will create four named lines each, with the lines named
> "foo-start", where "foo" is the name of the area.
>
> fantasai believes that auto placement may be complex when using named
> lines.  fantasai, could you elaborate?
>
> We haven't yet figured out how to supply explicit named lines (besides the
> ones that come for free from grid areas).  We may punt to the next level,
> or if it looks simple, figure it out and introduce it in this level.
>  Depends somewhat on fantasai's response to the auto placement problem, I
> think.
>
> We continue to keep the shorthands we currently have, with their grammar
> suitably modified.  We also continue to allow them to take idents
> (referring to grid areas directly), which compute to the appropriate
> gridline name ("grid-start: a;" computes to "grid-start: 'a-start';",
> etc.).  (The shorthands will need some work to make them unambiguous -
> "grid-column: 1 'c';" is ambiguous between "grid-start: 1; grid-end: 'c';"
> and "grid-start: 1 'c'; grid-end: auto;", and maybe "grid-start: auto;
> grid-end: 1 'c';".  We might need to make the grammar "grid-column: <ident>
> | [ start <'grid-start'> ] || [ end <'grid-end'> ]". Bonus - this extends
> cleanly to setting all four in grid-area.)
>
>
> Non-Positioned Contents
> ====================
> For stuff that isn't a grid item (what this means tbd; does it mean that
> none of the grid-* properties are set?  Is there an explicit indicator,
> like display-outside:grid-item;?), flow it all together, wrap it in an
> anonymous grid item, and position that.
>

I'd prefer that we be consistent with flexbox and force all immediate
children of the grid to be grid-items regardless of their display property.
Obviously, text will need to be wrapped in an anonymous grid items still.
This is simpler for browser developers to implement and for authors to use.


> By default, the default grid item will either have "grid-start: 1;
> grid-before: 1; grid-end: offset 1; grid-after: offset 1;" (placed in the
> first cell of the grid) or "grid-start: 1; grid-before: 1; grid-end: 1;
> grid-after: 1;" (fills the entire grid).
>
> We're unsure about the best way to explicitly specify the default cell's
> dimensions.  Another set of properties
> (grid-default-start/end/before/after)?  A pseudo-element on the grid
> container that represents the default cell?  Something else?  I prefer the
> pseudo-element approach - you probably want the ability to specify the
> default cell as a full container element, with the ability to do alignment,
> padding, etc.
>
>
> Grid Item Descendants (not children)
> ==============================
> Unsure right now whether to allow descendants of a grid to become grid
> items.  There are three choices:
>
> 1. No.
> 2. Only if they're children after eliminating boxes via "display-box:
> contents;".  (Flexbox wants to do this too - lets you use wrappers in the
> DOM, but ignore them for styling.)
> 3. Yes, arbitrarily - when you're a "grid item" (see the note in the
> previous section), you seek out your nearest ancestor grid and position
> yourself in it.
>
> If (3) is chosen, what happens to the following?
> <div id=A display:grid>
>   <div id=B display:grid-item>
>     <div id=C display:grid-item></div>
>   </div>
> </div>
>
> Is C allowed to jump out of its parent, so that B and C end up
> layout-level siblings in A's grid?  Or do you need a clear path to the
> ancestor grid, without intervening grid-items, so that C computes to
> "block-level" instead?
>
> If we decide on (1) or (2), we can always open things up later.  If we
> choose (3), and then the latter option (C computes to "block-level"), we
> can also open that up in the future, by allowing grid items to explicitly
> select the grid they want.


I strongly prefer that we leave 3 for a future version of the spec. I think
we can meet the majority of the use-cases with considerably less
implementation cost if we pass on 3 for now.

Ojan