Re: Flexbox Draft, with pictures!

On May 24, 2010, at 5:38 PM, Tab Atkins Jr. wrote:

> In case you've stopped following the last flexbox thread, or just gave
> up on a text-heavy draft without any pretty pictures, check out
> http://www.xanthir.com/:wih .  I've added code+visual examples in
> several places, which I think make it much easier to digest.
> 
> I'd welcome any feedback on the examples, as well as the actual text
> of the spec, of course.
> 
> ~TJ
> 

My feedback:

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

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

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

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

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

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

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

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

Received on Tuesday, 25 May 2010 22:46:44 UTC