Re: Flexbox Draft, with pictures!

On Tue, Jun 1, 2010 at 5:52 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> 2, 3: It is not impossible actually. Consider this:
>
>        hbox > * { display:table-cell; vertical-align:middle; }
>
> Using a table is not pretty but it gets the job done. We wouldn't need a table if 'vertical-align' applied to any block. Why not do that first?

That only works if you're willing to accept the effects of using a
table on the pack-direction.  That is, you lose the ability to pack at
all.  The children have no spacing between them (other than what
border-spacing specifies) and must fill the entire parent in that
direction.

I've used tables to fake flexboxes before, but they're not a
general-use replacement.


> 4: I don’t think the code in either column does what the challenge wants.
> - in current draft it is possible to either stretch or align baseline but not both.

Ah, you're right.  I was misremembering how box-align:baseline worked.


> - the speculative code in "proposed" means "align children of flexbox item on baseline" but it would be wrong to expect that baseline to relate to baseline of its siblings.

Why would it be wrong?


> 8,9: agree (although not sure how important it is though)

I assure you that effects in this line are used on the internet, and
that I want to be able to do them.  ^_^


> 10: relative is probably better in second column anyway, but if you want to use FL you want to also decrease bottom margin by 5px to avoid layout change:
>
>        hbox > :hover { margin: calc(5px + 1fl) 0 calc(-5px + 1fl); }

That's not necessary.  When you change the margins, the amount of
space given to the flexes will change as well.  It'll move without
affecting layout elsewhere.  (Doing as you suggest would have the
effect of moving it by 10px, actually.)


> 11: I don't get the use case. How is it different from simply centering?

It's not significantly different, this case just came to mind as
something that should be exercised.  It also points out a minor
additional ability of my proposal.


> 12, 13, 14, 15: second column code won't work if there is flex and max-width on children:
>
>        <div style="display:box; width:200px; box-pack:end">
>        <div style="max-width:150px; box-flex:1">
>        </div>
>        </div>
>
> Will produce a right-aligned 150px-wide child. But
>
>        <div style="display:box; width:200px; padding-left:1fl">
>        <div style="max-width:150px; box-flex:1">
>        </div>
>        </div>
>
> Will get you a right-aligned 100px-wide child.
>
> This will be different of course only if max-width keeps limiting effect of flex. If we consider max-width only before flex (as has been proposed) both solutions will have same effect.

Actually, the second case will produce a right-aligned 0px wide child.
 Parent flex is computed in the first distribution round, but child
flex is done in the second distribution round.  You need to pair that
with a min-width to prevent the child from being squished to nothing.


> 15: I like box-pack version much, much better. Also this doesn't work with max-width, unless there is a way to assign flex-group to a margin.

Actually, the second suggestion in my draft can omit the "hbox > * {
width:fit-content; }" rule if I change things so that 'auto' width and
height act like 'fit-content' all the time.  So then it would just be
a comparison of "hbox { box-pack: justify; }" versus "hbox {
flex-spacing: 1fl; }".  I'd call that pretty even.  (The latter has
the benefit that it interacts with the flexes of the children too.)

Can you elaborate on what you mean by "this doesn't work with max-width"?


> 16:
> current draft: it is possible with generated content on first and last child

Ah, right.  I'll add that.


> proposed draft: the code assumes horizontal margin collapsing (which I am not a fan of). Without that it is still possible but is similar to 12-15.

Indeed, because I like margin collapsing.  ^_^


> 17: this exact case should also work with generated content, but if you happen to want anything more complicated (like 1/3 margin somewhere) current spec won't do it.

Hmm, could you illustrate how it would work with generated content?


> 18: also
>
>        hbox > .end-packed:before { box-flex: 1fl; }

You sure that works?  Remember that .end-packed::before is a child of
.end-packed, not hbox, and so shouldn't participate in hbox's flex
distribution.


> 19: agree
>
> 20: very interesting case. Both versions should work (assuming min-width:fit-content works). Space distribution algorithm may be tricky when there is more space than content width but less than needed to make them all equal.

Could you elaborate on what you mean by that last sentence?  An
example, perhaps, with a pointer to what you think might be tricky?
(I know that mine would work - the free space allocation algorithm is
completely precise in this case - they just won't all be equal until
there's enough space for them to be.)


> 21: generated content would do it too

I don't think I quite see this one.  Could you illustrate?


> 22: I think the "challenge" describes what "current" is doing. "proposed" also flexes margins but it is not called for.

I explicitly ask to shrink margins if there's not enough space - "but
shrink their spacing and keep their widths at intrinsic if they would
overflow".

~TJ

Received on Wednesday, 2 June 2010 01:22:38 UTC