Re: [css3-grid] grid-cell-stacking and grid-layer should be removed

On Wed, May 18, 2011 at 4:46 PM, Phil Cupp <pcupp@microsoft.com> wrote:
> On May 18, 2011 12:51 PM Tab Atkins Jr. [mailto:jackalmage@gmail.com] wrote:
>> The grid-template functionality in Example 1 is valuable, and the fully anonymous grid-cell created in Example 3 isn't a problem so long as we define how it's ordered with respect to other grid cells.
>
> Sounds good.  With only the grid-template property defining the explicit cells, you can say that they occur in "template order," and that anonymous Grid Cells are painted above them.
>
>> The intuitive ordering for grid-cells then would be that grid-template cells are on the bottom by default (their relative ordering is unimportant, as they can't overlap), and anonymous cells are above that, in DOM order of the elements they're created for (this is unambiguous, since we have a guarantee of one cell per element here).
>
> I agree with your intuitive ordering, but I may not agree that the order of the explicitly defined Grid Cells is unimportant depending on what styles a Grid Cell can accept.  I think we have a simple mechanism to define the order in which they occur though now (see comments above).

Yeah, you're right.  They should be ordered as if they were cells of a
table; that is, cells are ordered first by the index of their topmost
row, then the index of their leftmost column.

>> Then, presumably, z-index can change the ordering, either directly on ::grid-cell for grid-template cells, or on the element for anonymous cells.
>
> Seems reasonable.
>
> Another question though, is the Grid the right place to define the mechanism for generating pseudo-elements that add "presentation-specific structure" to a document?  Just as display:stack should be factored out as a separate concept, should the notion of generating a container around a set of elements also be factored out?
>
> It seems like the model would be applicable elsewhere.  If I could pluck out of the document elements a, b and c, and place them in a pseudo-element that I then feed into a Flexbox so that the pseudo-element is considered a Flex Item, isn't that the same notion we're introducing here by aggregating elements into a Grid Cell and then handing it to the Grid for layout?

I agree that the concept could be pulled out into a more general
mechanism, and I think such a general mechanism should be created in
due course.  However, I think Grid holds a privileged position here,
or rather, I think that the template mechanism for creating
presentation-specific structure is privileged.  Given that, and the
fact that the template mechanism is tied up in Grid, I think that Grid
should go ahead and define this.  The particular way that templates
work allow us to avoid many of the ambiguities that the more general
mechanism would have.

An alternative approach would be to cut templates from Grid, and
instead define them within Regions, as template cells are pretty much
solely a receptacle for region flows.  Grid already has to deal with
the difficulties inherent in sizing a grid with overlapping cells, so
having another mechanism for producing *more* overlaps won't make it
any harder.  This also makes the "smash elements from different parts
of the document together" mechanism consistent between template cells
and ordinary elements.

Templates are clearly intimately linked with both Grid and Regions, so
placing them in either spec would work.  We could even just create a
Template spec, dependent on Grid and Regions, that details the
template functionality and otherwise defers to Grid for layout and
Regions for flow.

~TJ

Received on Thursday, 19 May 2011 02:46:27 UTC