- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 18 Jul 2013 18:03:46 -0700
- To: "www-style@w3.org" <www-style@w3.org>, Daniel Holbert <dholbert@mozilla.com>, Rossen Atanassov <Rossen.Atanassov@microsoft.com>, Boris Zbarsky <bzbarsky@mit.edu>
On 05/22/2013 02:04 PM, Christian Biesinger wrote: > On Wed, May 22, 2013 at 1:00 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> On Wed, May 22, 2013 at 11:49 AM, Christian Biesinger >> <cbiesinger@google.com> wrote: >>> Hm... in that case I'd like to ask, why is this behavior desirable? It >>> seems like lots of complexity for little gain compared to just >>> promoting the display types to block. >> >> The gain is that you get to rely on the same box-construction rules >> that you get inside of block layout. It's not good if two naked >> table-cells wrap themselves in a table in block layout, but break in >> flexbox layout. > > OK then... I filed a bug to fix the behavior in Chrome, though I'm > unconvinced how useful this behavior is. > > (https://code.google.com/p/chromium/issues/detail?id=243056) I'm similarly unconvinced. It certainly seems simpler just to do the computed value fixup, and would probably be useful in cases where you want flexbox, but use table layout as a backup. .flexbox { display: table; display: flex; } .flexbox * { display: table-cell; /* horizontal */ display: table-row; /* vertical */ } I've pushed a clarification here, but maybe we should instead change that part of the spec in favor of computed value fixup. bz, dholbert, Rossen, any thoughts? ~fantasai
Received on Friday, 19 July 2013 01:04:14 UTC