- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 17 Feb 2012 17:13:47 +0100
- To: "www-style@w3.org" <www-style@w3.org>
[This a series of comments arising from Bert and I attempting to merge
the Template and Grid models into a combined Grid Template model so that
we can have one layout model going forward. Some issues arise from merging.
Others are "we found lots of issues while attempting to merge" comments.]
Cascading of Positions
----------------------
Right now there are three different ways of associating a grid
position with an element:
'grid-cell'
which assigns the element into a named template slot, thus
assigning its rows and columns
'grid-row' and 'grid-column' with 'grid-*-span'
which assigns its rows and columns by start cell and number
of tracks to span
'grid-row' and 'grid-column'
which assign its rows and columns by start and end grid lines
For example,
a { grid-cell: a; }
a { grid-row: 1; grid-column: 5;
grid-row-span: 2; grid-column-span: 3; }
a { grid-row: 5; grid-column: 9; }
Suppose I cascade all of these together.
We could of course come up with some rules, which would say, for
example, that only 'grid-cell' is honored. Or that the element
winds up starting in row 5 column 9, but spanning 2 rows and 3
columns, and 'grid-cell' is ignored. From the implementation
perspective, this behavior is well-defined.
But by arbitrarily prioritizing one method of positioning over another,
the result of the cascade becomes a mélange of what was specified
rather than a clear cascaded win of one rule over another. This is not
friendly to the author, for whom different methods of positioning are
expected to essentially be aliases of each other.
The grid position, really, should not be cascaded in parts depending
on how it was declared. Each position should be cascaded atomically,
so that each time the author specifies a position, he can know that
it will override anything that was specified at a lesser specificity.
He should not need to explicitly reset all potentially involved
individual properties to be sure.
Summary of issue: Grid positions should cascade atomically.
(Cascading rows and columns independently is ok, because it's obviously
expected to set both unless you want the missing one cascaded in from
earlier.)
Proposed Solution
-----------------
1. Fold the grid-*-span properties into their respective positioning
properties. This would require designing some kind of syntax to
distinguish between start + span and start + end, but it is doable.
2. Allow grid slot names as values for grid-row and grid-column. They
mean "assign to the same rows/columns as this slot".
3. Create a shorthand that sets both, so that positioning to a named
slot can be done easily.
For example,
grid-row: <slot> | <integer> [ <integer> | to <integer> ]?
grid-column: <slot> | <integer> [ <integer> | to <integer> ]?
grid-position: <grid-position-row> / <grid-position-column>
e.g.
To place in grid cell 4, 2:
- - - - - -
- - - X - -
- - - - - -
- - - - - -
grid-row: 2;
grid-column: 4;
grid-position: 4 / 2; /* shorthand */
To place in grid rows 4, 5, and 6 and grid rows 2 and 3:
- - - - - -
- - - X X X
- - - X X X
- - - - - -
grid-row: 2 2;
grid-column: 4 3;
grid-position: 2 2 / 4 3; /* shorthand */
or
grid-row: 2 to 3;
grid-column: 4 to 7;
grid-position: 2 to 7 / 2 to 4; /* shorthand */
Note: Grid's start + end syntax is in terms of lines, not tracks.
Or, if there's a template:
grid-template: "a a a a a a"
"b b b c c c"
"d d e e f f"
"g g g g g g";
To place in slot f, i.e. columns 5-6 and row 3:
grid-position: f;
To in the columns covered by slot c, but in the row occupied by g:
grid-column: c;
grid-row: g;
(The row/column split is not especially useful with named template
slots, but defining it makes the shorthand work properly.)
~fantasai
Received on Friday, 17 February 2012 16:14:22 UTC