- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 17 Feb 2012 09:55:07 -0800
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: "www-style@w3.org" <www-style@w3.org>
On Fri, Feb 17, 2012 at 8:13 AM, fantasai <fantasai.lists@inkedblade.net> wrote: > [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> This sounds pretty good! Note that you left out 'auto' in the row/column, and your grammar doesn't allow a single <slot> for grid-position. You want: grid-row: <slot> | <integer> [ <integer | to <integer> ]? | auto grid-column: (same) grid-position: <slot> | <'grid-row'> / <'grid-column'> ~TJ
Received on Friday, 17 February 2012 17:55:57 UTC