- 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