W3C home > Mailing lists > Public > www-style@w3.org > December 2010

Re: [css3-flexbox] Flex-align possibilities

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 21 Dec 2010 14:39:36 -0800
Message-ID: <AANLkTinDre8=Do6VEcX7yuP5m3YD56tNJYkE4Ar5wBSz@mail.gmail.com>
To: Alex Mogilevsky <alexmog@microsoft.com>
Cc: www-style list <www-style@w3.org>
On Tue, Dec 21, 2010 at 2:04 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> Well, right, you can also get the same effect as " align+margin reduced" with auto padding (or almost same)...
> As I recall the biggest issue with flex-align is that in many cases it seems that it is there only for baseline. If it weren't, margins could just be enough.

Yup, baseline is the problem.  Without that I could get away entirely
with just using flexible margins and paddings.

> I see a few ways to go about it:
> 1) admit it is about baseline and call it "flex-baseline-align:none|baseline". That handles most cases via margins, and does extra just for baseline

Hm, that's a definite possibility.  It then becomes more like
flex-pack, where it's just intended for the valuable corner-cases that
you can't easily get with flex units (/ auto values, which are all we

As well, this removes any direction-dependence, so I don't have to
reuse the logical keywords for incorrect purposes here.

> 2) use vertical-align (we've discussed that one, right) -- just make it apply to flex items too, with same meaning as for table cells (or similar, if not everything about table cells makes sense to apply).

This is a possibility, but I'm loathe to re-use vertical-align.  Using
it for table cells in the first place was a mistake, because it
radically changes the meaning of the property.  Further, its values
are very badly named for flexbox, where "top" can mean top, left, or
right, depending on the flexbox direction and the writing direction.

> 3) take "align+margin" as is, it is fine that some outcomes are similar, as long as it is clear that they do. Anything more intuitive  than "vertical-align:text-top" I would find reasonable.

Also still on the table, though I'm slightly afraid of specifying it.
There will be a lot of temporary lengths that get used in the
computation of more temporary lengths, before I can finally actually
figure out how much free space there is.

> I am not sure BTW what "[anything]" means in the new column. Is it one of before/middle/after/baseline, and regardless of value the effect is the same? But that wouldn't do 2/3/7, would it?

Yes, [anything] means it doesn't matter.  Under that model, auto
margins get first crack at free space.  flex-align gets the scraps
left over at the end, just like flex-pack.

> Ah, actually wait a minute... pictures 4, 5, and 10 are wrong. There is no reason to stretch the box when there is an auto margin and no baseline alignment. You should have same picture for 1=4=5 and 10=12=13. And 6=8=9.

You're right that not stretching the box up/down is a possibility.
That may be better, I dunno.

1, 4, and 5 shouldn't be the same, nor the other ones.  The point for
each is that *first* the contents are aligned as specified by the
second argument, then *second* the boxes as a unit are aligned as
specified by the first argument.

Received on Tuesday, 21 December 2010 22:40:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:54 UTC