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

On Thu, Jun 3, 2010 at 7:03 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
>> -----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.

Ah, I see.  That won't work with baseline, though.

And I assume that table fixup works the same regardless of flow?
Unless the flow specifically says otherwise, that is.


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

That's certainly another possibility, and an interesting one that I'd
like to see pursued.


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

Generally, yes.  But vertical-align:baseline is *explicitly* about
affecting and being affected by the content of siblings.

I don't see any real difference in the model if vertical-align is
specified on the parent or the individual children.  Either way the
relevant children work together to determine how they should be
aligned.


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

The effects I've seen have been on random blogs across the internet,
so I can't recall any right now.  I'll put out a call for examples,
though, and hopefully someone has a better memory than me.


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

Ah, no, you were right in the first place.  I can make the adjustment
on a single margin, but then I have to double it (margin-top:
calc(10px+1fl); to move it down by 5px).  Your example of doing +5/-5
on the two margins is actually completely correct and will move it by
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.

Eh, it's not very important.  Just consider it as roughly equivalent to #7.


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

No, I'd assumed that you meant width:1fl.  The inner div has neither a
minimum or preferred size, though, so when the first distribution
round attempts to figure out how much space to give to the padding on
the outer div, the inner div doesn't contribute anything to that
calculation.  Thus the entire width is considered "free" and given to
the outer div's padding.


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

Sure.  (Rather, I'll edit my proposal.)


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

Ah, you're right.  box-pack operates with a high flex group.  You can
simulate this by making the margin instead be, say, .001fl.  Then the
boxes will eat all the space they can, and afterwards the margins will
get their turn.

I notice, though, that I've misread how box-pack works, and wrote my
algorithm incorrectly as a result.  As written, the current Flexbox
draft makes box-pack have *no effect* unless all the children are
either inflexible or have a max width.

I'll bring this up in a separate thread, because it has some complex
implications.


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

::outside::before!  ^_^


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

Not quite.  First, I typoed - the margin should be max(10px, 1fl).
Second, the way that margins collapse mean that the collapsed margin
has a minimum size of 10px and a flexibility of 1, same as both of the
original margins.


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

~TJ

Received on Friday, 4 June 2010 18:14:54 UTC