- 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