- From: Ojan Vafai <ojan@chromium.org>
- Date: Mon, 16 Apr 2012 16:18:16 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Morten Stenshorne <mstensho@opera.com>, www-style@w3.org, Daniel Holbert <dholbert@mozilla.com>, Alex Mogilevsky <alexmog@microsoft.com>, Tony Chang <tony@chromium.org>
- Message-ID: <CANMdWTsef3eM9z6FNE0OQR6nLc0KkL8LAUrOPTdmoxrXvsK1Hg@mail.gmail.com>
On Mon, Apr 16, 2012 at 3:34 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote: > On Mon, Apr 16, 2012 at 3:12 PM, Morten Stenshorne <mstensho@opera.com> > wrote: > > "Tab Atkins Jr." <jackalmage@gmail.com> writes: > > > >> The baseline of a flexbox item is just whatever their display type > >> says it should be (there's no "flexbox item" display type). > > > > That would mean that a flexbox item with e.g. display:block and a > > flexbox item with display:inline-block would get their baselines > > calculated differently (first line vs. last line). Do we really want > > that? > > It's the simplest answer. Those display values had their baselines > defined that way for a reason. There's no real reason to mix, say, > display:block and display:inline-block - they're treated identically > by Flexbox otherwise, so you might as well declare all the children as > one or the other if you want a particular baseline out of all of them. > > On the other hand, table cells do their alignment with a special > definition, which you modified in your original post. Hm. > > Ojan, Tony, Alex, Daniel, do you have any particular opinion on this? > I can specify it either way - we can either keep the current "flexbox > items have their normal baselines, based on their display value" or > determine the baseline the same way that table-cells do. > 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. Also, what are all of you doing currently for the baseline of the > flexbox itself (for both 'row' and 'column' flexboxes, if it makes a > difference, and for the special case when the baseline of all the > children is perpendicular to the direction of the flexbox)? > Looking at the test-case above, we're using the baseline of the first flex-item. I think this is just an accidental side-effect of our implementation of flexbox inheriting from block. That seems as good a choice as any to me. WRT flex-direction:column, at first glance, our baseline behavior is buggy for the flex-items. I'm not really sure what flex-align:baseline is supposed to do with column flex-items. Ojan
Received on Monday, 16 April 2012 23:19:06 UTC