- From: Morten Stenshorne <mstensho@opera.com>
- Date: Tue, 17 Apr 2012 09:54:09 +0200
- To: Ojan Vafai <ojan@chromium.org>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style@w3.org, Daniel Holbert <dholbert@mozilla.com>, Alex Mogilevsky <alexmog@microsoft.com>, Tony Chang <tony@chromium.org>
Ojan Vafai <ojan@chromium.org> writes: > http://goo.gl/mjJLD > > The current behavior does seem wrong, but I agree that it's uncommon for > different display types to be mixed in one flexbox. > > I don't feel strongly about this, but my intuition is that the table-cell > behavior makes more sense. I'm thinking of the case of a toolbar (which is the > only baseline use-case I can think of). If you have a label for an input that > wraps, you wouldn't want every other item in the toolbar to move downwards. > > FWIW, WebKit's table behavior for inline-blocks doesn't do the above, which I > think violates http://www.w3.org/TR/CSS21/tables.html#height-layout. No, that actually looks right. <td style="display:inline-block;"> will insert an anonymous table-cell parent. A line will be created inside the cell for the inline-block, and the baseline of the line will be the baseline of the inline block, which is the last (second) line in the inline-block. Gecko, IE and Opera also agree with Webkit here. Such anonymous parent insertion will not happen for flexbox, on the other hand, because an inline-block is an acceptable flexbox item on its own. -- ---- Morten Stenshorne, developer, Opera Software ASA ---- ---- Office: +47 23693206 ---- Cellular: +47 93440112 ---- ------------------ http://www.opera.com/ -----------------
Received on Tuesday, 17 April 2012 07:54:55 UTC