W3C home > Mailing lists > Public > www-style@w3.org > November 2012

Re: [css3-grid] Notes from the Grid discussion

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 27 Nov 2012 14:53:23 -0800
Message-ID: <50B54463.70106@inkedblade.net>
To: www-style@w3.org
On 11/27/2012 02:33 PM, Tab Atkins Jr. wrote:
> A quick diversion - I forgot to put in part of the initial discussion
> about use-cases.  Let me rectify this.

Good summary. I think that was important to add. :)

>>> Grid Item Descendants (not children)
>>> ==============================
>>> Unsure right now whether to allow descendants of a grid to become grid
>>> items.  There are three choices:
>>> 1. No.
>>> 2. Only if they're children after eliminating boxes via "display-box:
>>> contents;".  (Flexbox wants to do this too - lets you use wrappers in the
>>> DOM, but ignore them for styling.)
>>> 3. Yes, arbitrarily - when you're a "grid item" (see the note in the
>>> previous section), you seek out your nearest ancestor grid and position
>>> yourself in it.
>>> If (3) is chosen, what happens to the following?
>>> <div id=A display:grid>
>>>    <div id=B display:grid-item>
>>>      <div id=C display:grid-item></div>
>>>    </div>
>>> </div>
>>> Is C allowed to jump out of its parent, so that B and C end up
>>> layout-level siblings in A's grid?  Or do you need a clear path to the
>>> ancestor grid, without intervening grid-items, so that C computes to
>>> "block-level" instead?
>>> If we decide on (1) or (2), we can always open things up later.  If we
>>> choose (3), and then the latter option (C computes to "block-level"), we can
>>> also open that up in the future, by allowing grid items to explicitly select
>>> the grid they want.
>> I strongly prefer that we leave 3 for a future version of the spec. I think
>> we can meet the majority of the use-cases with considerably less
>> implementation cost if we pass on 3 for now.

I agree with (2); I think we can do 3 easily in the future.

Received on Tuesday, 27 November 2012 22:53:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:06 UTC