W3C home > Mailing lists > Public > www-style@w3.org > May 2011

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

From: Phil Cupp <pcupp@microsoft.com>
Date: Wed, 18 May 2011 01:53:42 +0000
To: 'David Hyatt' <hyatt@apple.com>
CC: "www-style@w3.org CSS" <www-style@w3.org>
Message-ID: <26AA92D3A047B64C8F326A0BF9EB17FA33C48534@TK5EX14MBXC138.redmond.corp.microsoft.com>

On May 16, 2011 8:51 AM, David Hyatt wrote:

>I think grid-cell-stacking should be dropped in favor of just using the display property (more below).

Agreed on this point (below, however, I question the utility of explicitly defined grid-cells versus their complexity... maybe we don't need them?)

>So items that use anonymous cells are never coalesced? They always get their own unique cell?

Yes.  To my knowledge there's no way for an author to prove whether or not an anonymous Grid Cell really exists.  If we said they could combine and Grid Items could share an anonymous Grid Cell, I don't think you could tell the difference.  There is no selector that allows an author to change the styles of an anonymous Grid Cell and the Grid Cell's initial property values are such that the Grid Items included in that Grid Cell don't impact each other's layout.

>You've basically defined another display type here: the stack.  This was implemented in Mozilla years ago along with flexible boxes, and rather than trying to sneak it in as the default layout system for grid cells, I'd prefer it if we defined stacks separately and then just allow grid cells to use different display types.  Then authors could use flexible boxes or blocks to do grid-cell-stacking: rows | columns and stacks to do grid-cell-stacking: layer.
>This is an ancient document, but see section 2.2:

This all seems like good stuff.  I agree with your assessment.

>Note that z-index is supported on XUL stacks and works fine without introducing a new property.  I think grid-layer should just be replaced with z-index.  I don't think it's necessary to support grid-layer across cells, but maybe you have use cases besides stacking within the same cell that could convince me otherwise.

I've received this feedback multiple times (using z-index instead of grid-layer).  I'm fine with using z-index instead of grid-layer, but there are differences in their behavior.  Our current implementation differentiates grid-layer from z-index in that the Grid Element is the parent Stacking Context for static positioned Grid Items, i.e. Grid Items with a grid-layer: -1 were sent behind other Grid Items with a higher grid-layer, but not behind the Grid Element.

So If we used z-index in place of grid-layer then:

(1) Do we expect that z-index affects the painting order of static position Grid Items?  I would say yes.
(2) Do we expect that the Grid Element is the parent Stacking Context for static positioned Grid Items.  I would also say yes.
(3) Can z-index function per usual when the Grid Item has a relative, fixed or absolute position.  I think yes, i.e. I don't believe points 1 and 2 create side effects since the special behavior only applies to statically positioned Grid Items.
What are the implications for a styled Grid Cell?  The Grid Cell doesn't have a tree order (as you've already pointed out) so I don't think it can impact the tree order of a Grid Item when it is used to determine the painting order.  Can the Grid Cell affect painting order by being positioned and assigned a non-auto z-index (making it the parent Stacking Context for its Grid Items)?  If yes, then I think we need a way to break ties which I don't currently have an answer for due to the lack of Grid Cell ordering.  Can the Grid Cell be given a background and border?  Same problems.  Maybe we could say that the paint order of Grid Cells is only defined when they are assigned a z-index which is unique to the Stacking Context that they participate in, and otherwise undefined.  That doesn't seem like a very good answer though.

For these reasons I still prefer that we can't style Grid Cells beyond grid-row, grid-column and display (replacing grid-cell-stacking).  Also, while discussing these issues internally, several questions kept popping up as to the utility of grid-cell pseudo-elements.  Why not just use a real element as the container for related elements and position that using the Grid?

Would anyone strongly oppose eliminating the grid-cell pseudo-element (would also imply the removal the grid-template property) from the Grid spec?  Personally I find the grid-template property (modeled after template layout) and the grid-cell pseudo-element (modeled after the template layout ::slot concept) to be elegant, but I'm having trouble defending the need for the creation of a pseudo-structure to gather and layout related elements when I only have scenarios where a real containing element seems equally elegant and semantically correct.

Thanks for your thoughts, Phil
Received on Wednesday, 18 May 2011 01:54:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:46 UTC