[css3-flexbox] use cases (RE: Flexbox Draft, with pictures!)


> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Tuesday, June 01, 2010 6:22 PM
> To: Alex Mogilevsky
> Cc: www-style list
> Subject: 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.  

Actually no, what I mean by this is that each flex item is a table-cell, individually wrapped into an anonymous table, and then vertical-align applies to content. This depends on how table fixup works inside a flex-box, which is currently undefined.

I am not serious though that people should use tables to make this case work. I am very serious though that vertical-align should work everywhere.

> > - 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?

Generally a property set on an element doesn't affect layout of content of its sibling. It does happen to table cells (with vertical-align), but it would be a cleaner model if sibling interaction would be controlled by parent.

> 
> 
> > 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.  ^_^

I would like an example from a real page on the internet.

> > 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.)

You are right, it is unnecessary. It is enough to mess with one margin. But your example only moves it by 2.5px.

> > 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.

The challenge still doesn't make sense, sorry. I understand what each code sample does, and clearly the last one can't be matched by current spec, but the 'challenge' fails to explain what exactly the author wanted.

> > 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.

My second example will  produce 0 width because your proposal doesn't have 'box-flex' in it. My mistake.
 s/ box-flex:1/width:1fl/
With that, does it illustrate the difference?

> > 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.)

The title of the last column says " Proposed Flexbox draft ". It should not contain examples that won't work with this proposal, it is just too confusing. You can add another column for other speculative syntax.

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

This example (claimed equivalent of "box-pack:justify")

        <style>
            hbox > * { margin-left: 1fl; } 
            hbox > :first-child { margin-left: 0; }
        </style>
        <div style="display:box; width:120px; ">
            <div style="max-width:50px; width:1fl"></div>
            <div style="max-width:50px; width:1fl"></div>
        </div>

... will  produce two 40px divs with a 40px space. "box-pack:justify" would have made it two 50px divs with 20px space. 

> > 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?

You are right, generated content won't do it because generated content is inside the element it applies to

> > 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.

Right, it doesn't.

> > 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?

Again, I was wrong considering inserting generated content as a sibling of flex item. Explicit spacer elements would be required in current draft to achieve this. Or a new kind of generated content that's outside of the parent.

> > 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".

I didn't read the challenge carefully enough. Actually your version in left column will have 20px spacing. And "min-width:fit-content" can be added there too, as it has no dependency on either draft.

> 

 (I want to keep the link to the use case page here as a reference: http://www.xanthir.com/etc/flex-use-cases.html )

Received on Friday, 4 June 2010 02:04:19 UTC