W3C home > Mailing lists > Public > www-style@w3.org > April 2012

Re: [css3-flexbox] Baseline of flexboxes and flexbox items

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 16 Apr 2012 17:14:25 -0700
Message-ID: <CAAWBYDBjXkQpD88PiyiMXnU62bOUJk5bxYr_iruF1hMxyjrBSw@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:52 GMT