Re: Flexbox Draft, with pictures!

On Tue, May 25, 2010 at 3:46 PM, David Hyatt <hyatt@apple.com> wrote:
> (1) I don't think "flex" by itself is a good term for display-inside.  I also agree that "box" is arguably too generic.  You might consider just combining the words flex and box together.
>
> display: flex-box
> display: inline-flex-box
>
> The same would apply to other properties, e.g., flexbox-begin not flex-begin.

I made the naming change as a result of feedback from Ojan Vafai.  You
and he are already discussing that, so I don't think I need to say
more.  ^_^


> (2) What happened to box-pack: justify?  I see no equivalent with flex-begin.

That's the only thing I regret losing, because it's somewhat annoying
to implement the same thing in my draft.  You have to do this:

hbox { display: flex; }
hbox > * { margin-left: 1fl; }
hbox > :first-child { margin-left: 0; }

Whereas it's very simple in the current draft:

hbox { display: box; box-pack: justify; }

However, the required method in my draft is what authors already have
to do to solve the problem of putting margins/borders between multiple
elements (frex, a thin line between list-items using border-top), but
not outside of them.  So, hey, knowledge transfer.

(Doing this with multiple lines is more difficult, and requires the
margin-break property to exist, but that's a problem in multicol too,
and needs to be solved in both places.)


> (3) How do you do box-pack: right in LTR with flex-begin?  Flexible padding on the flexbox container?

Yup:  hbox { display: flex; padding-left: 1fl; }


> (4) flex-begin: end?   Really? :)  I don't think "begin" is a good term to use here.  horizontal | vertical as as values seem like easier terms to understand to me.

The problem with horizontal/vertical is that there's no good way to
indicate the reverse direction.  The current draft has to solve that
with a "patch" property - box-direction - who's only purpose is to
reverse the direction you specified in box-orientation.

I'm open to renaming or reorganizing on that property and its values,
though.  -begin was just the best thing Elika and I could come up with
in under a minute, and I haven't me up with anything better yet.

One possibility that several people have suggested and I'm still
entertaining is to use directions explicitly, rather than referring to
an edge.  That is, do "lr","rl","tb","bt".  But then we also need the
logical directions, which means "se", "es", "ba", and "ab".  Is this
too silly?  I dunno.


> (5) I think the second optional part of flex-begin is really confusing.  I would consider making that a separate property rather than trying to merge it with flex-begin.  "before" seems like a crazy default for multi-line horizontal boxes.... the second line comes after the first, so "before" makes no sense to me.  You could probably just flip the meaning of "before" and "after" here to get the behavior I'd expect.

The idea is to be analogous to the first value, so that they both
indicate which edge of the box you align the first "thing" to - child
or line.  Then additional children/lines are placed in the direction
opposite.  That may not be intuitive enough, shrug.  I think that
simple uses like "flex-begin:top" are pretty easy to understand - the
children start out at the top and then go down.  Similarly, then,
"flex-begin:top left;" means that children start at the top, and the
first line is on the left.  New children are placed downwards, new
lines are placed rightwards.


> (6) In the current spec if I say <img style="box-flex:1">, the image will not be able to shrink below its minimum intrinsic width.  How do I do that with calc? <img style="width: 1fl; min-width: min-intrinsic"> seems pretty nasty for a behavior that should arguably be the default.   I suppose the counterargument is that <iframe style="width:0; box-flex:1"> is more wordy than <iframe style="width:1fl"> though.  If the latter is going to be the more common use case, then forcing min-width and max-width additions to clamp flexing to min-intrinsic and max-intrinsic sizes might be ok.

I don't think that's true.  An img's minimum width is still 0 by
default, and so it *should* be able to shrink all the way down to 0.

I can't understand your last sentence.


> (7) I think collapsing margins are unnecessary, especially in the horizontal direction.

Collapsing the margins is pretty simple to specify, and seems useful.
Does it cause any particular problems in implementation?


> (8) I would cut multiple lines from the draft.  No implementation does them, they greatly complicate things, and there's not much benefit.  We have multi-column layout for wrapping vertical flow, and we have inline-block, etc. for wrapping horizontal flow.  I'm unconvinced that we need wrapping flows that also flex in a first draft of this spec.

Since nobody does it, you yourself have said that it has a weak
use-case, and it really does complicate things significantly, I'm okay
with this.  I do want to address this at some point for the use-case
of tabs, but I'm okay with v1 not having the ability to do multiple
lines.

What do other people think?  I can remove it, I just have to do a
decent bit of work to back it out of the distribution algo.

~TJ

Received on Wednesday, 26 May 2010 00:28:55 UTC