Re: [css3-grid-layout] Cascading Positions is Broken

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