[css3-grid] Notes from the Grid discussion

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)

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.

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.


~TJ