- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 16 Apr 2012 17:14:25 -0700
- To: Ojan Vafai <ojan@chromium.org>
- 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>
Here's a slightly easier-to-read version of your test-case, also corrected to make the table case work better: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1471 On Mon, Apr 16, 2012 at 4:18 PM, Ojan Vafai <ojan@chromium.org> wrote: > 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. This won't happen, though - if the <label>s are all display:block, they'll all line up according to their first line inside. One of them being multi-line doesn't push the others down. That only happens if you have a bunch of inline-blocks like <button>s, and one of them is multi-line. IIRC, it's *intentional* that a bunch of buttons will line up with their normal alignment behavior in a flexbox. > 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. Nope, we're doing right per-spec with inline-blocks. An inline-block in content generates a line box around itself (and it is then baseline aligned like an inline-block normally is). Table-cells grab that line-box, not the one *inside* the inline-block, for their own alignment purposes. Firefox definitely matches us on this. However, that won't happen with Flexboxes, since inline-blocks are flexbox items directly, and don't get wrapped. If we adopted the same algorithm, it would take the first line-box from inside the inline-block. >> 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. Yeah, this behavior is kinda stupid, but I can't think of anything better, really. If everything is baseline-aligned, then adjacent flexboxes will *also* end up baseline-aligning across each other, which is nice. > 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. The rule is that if the child's baseline is perpendicular to the main axis, just start-align them instead. Our behavior here is definitely buggy. ^_^ ~TJ
Received on Tuesday, 17 April 2012 00:15:14 UTC