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

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

From: Ojan Vafai <ojan@chromium.org>
Date: Mon, 16 Apr 2012 16:18:16 -0700
Message-ID: <CANMdWTsef3eM9z6FNE0OQR6nLc0KkL8LAUrOPTdmoxrXvsK1Hg@mail.gmail.com>
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>
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.


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

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.

Received on Monday, 16 April 2012 23:19:06 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:13 UTC