Re: Flexbox Draft, with pictures!

On Tue, Jun 1, 2010 at 11:11 AM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
>> -----Original Message-----
>> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
>> Sent: Tuesday, June 01, 2010 10:51 AM
>>
>> On Tue, Jun 1, 2010 at 10:13 AM, Alex Mogilevsky <alexmog@microsoft.com>
>> wrote:
>> > Actually I don't see anything difficult there.
>> > - "pack" has any effect only after any flex distribution is exhausted and
>> there is still empty space.
>>
>> Does that change the behavior of a "width:auto;margin:0;" child, which right
>> now is treated like "width:1fl;margin:0" and automatically expanded as much
>> as it can be?
>
> Not sure what "that" refers to, but either way if there is no extra space there is no pack.

Ah, sorry.  "that" referred to box-pack on an flexbox.


> I don't understand however why "width:auto" is same as "width:1fl". 'auto' is simply shrink to fit, and '1fl' consumes additional space, doesn't it?

Since the default behavior in the current flexbox draft is to stretch
in the align direction, I figured that should be the default behavior
in my proposal too, so I have "height:auto" flex the height as if it
was "1fl".  However, if you're providing a flexible margin or padding,
you probably know what you're doing, and so "auto" acts like
"fit-content" in that case.  I had "width" act the same way for
symmetry, though that's not the default behavior in the current
Flexbox draft.

It's possible that this is too much magic, now that I think of it.  It
might be better to just have 'auto' on width or height be
'fit-content', and 'auto' on margins be '1fl'.  It's really easy to
just say "height:1fl" if you still want the stretch behavior, after
all.


>> > - "align" has to deal with non-zero margins and padding already; if those are
>> calculated using flex or anything else it doesn't change any of align code.
>>
>> Would this have any effect if any of the vertical lengths were flexible, or does
>> it only have an effect when the total height of the margin box is inflexible
>> (either because all the vertical lengths are inflexible, or if all of the flexible
>> ones have hit their maximum size)?  That is, what effect does box-
>> align:center have on a child with "margin: 0 0 1fl 0;" (which aligns the child to
>> the top).
>> Similarly, does box-align:stretch change the behavior of height:auto?
>> (Again, right now height:auto computes to 1fl if it's the only flexible vertical
>> length on the box, or 'fit-content' otherwise.)
>>
>>
>> I personally doubt the additional complexity in the model to handle
>> pack/align alongside flex lengths is worthwhile, especially if you have to avoid
>> using flexible lengths at all for them to have a noticeable effect.
>
> You are right, simple alignment is redundant when you can do the same with auto margins. But you can't model baseline alignment with flex units, can you? And didn't you want a combination of 'stretch' and 'baseline' to work too?

Right, you can't do baseline alignment with flex units.  It's not in
my draft, but I was thinking of allowing vertical-align:baseline on
flexbox children, such that all the children with that have their
baselines aligned.  It complicates the sizing/positioning algorithm
quite a bit, though, so I haven't put it in yet.


> As far as combinatorial complexity, adding "fl" to margin calculation seems to not complicate alignment any more than any other margin. First all relevant margin are calclulated, then margin boxes are aligned. This works the same with any other alignment (e.g. in <center> element -- although deprecated, every browser has to implement it).

Ah, I wasn't talking about that complexity.  Yeah, the specification
and implementation is simple enough.  I just mean the additional
complexity of having it at all.  I don't like having two identical
ways to do things - in an ideal world, every problem an author runs
into has a single simple solution.  (I suppose I've drunk too much of
the Python koolaid.  ^_^)

box-pack and box-align have only a single case each that's not
completely trivial in flex units (justify and baseline, respectively).
 The one troublesome box-pack case is solved via a couple of possible
solutions, including one particularly simple solution from Hyatt that
I haven't put in my proposal yet.  box-align:baseline is the only
thing that's still giving me some difficulty, and I suspect that if I
want to hit that use-case I'll just have to bite the bullet and inject
some extra complexity into the model.  I think it's the least useful
of the box-align values, though, so I'm okay with not hitting it
immediately.

~TJ

Received on Tuesday, 1 June 2010 20:10:55 UTC