- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 27 Nov 2012 14:53:23 -0800
- 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. ~fantasai
Received on Tuesday, 27 November 2012 22:53:52 UTC