Re: Flexbox Draft, with pictures!

On May 25, 2010, at 7:16 PM, Tab Atkins Jr. wrote:

> 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; }
> 

What about supporting child spacing via the border-spacing property and allowing flex on it?

hbox { display:flex; border-spacing: 1fl 0; }


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

I'll think about this some more.  I get that you are trying to combine box-orient and box-direction, but I worry about over-complicating things.  The 99% use case is just to be horizontal or vertical with a normal box-direction, and I feel like the attempt to combine the properties has made everything a bit more cumbersome to understand.

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

Regardless, I think additive flexing vs. replacement flexing is a key distinction here, and it would be good to make both easy to specify.  Having to do width: calc(fit-to-content + 1fl) just to do the former seems gross.  Maybe we have two unit types, one for additive flexing and one for replacement flexing.  If it wouldn't cause a calc parsing ambiguity I'd suggest something like width: 1fl+ or width:+1fl vs. width:1fl;

> I can't understand your last sentence.
> 

That's fine. I don't understand it either.

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

Margin collapsing is extremely complex (arguably one of the most complex areas of CSS2.1).  Any implementation that has to consider it will be more complex.  I admit I'm mostly arguing this point out of implementor laziness.

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


The multi-line idea reminds me of column-span values of 2+.  One can certainly see the usefulness, but I suspect if you want the spec to make rapid progress from an implementation perspective that it would be better to defer multiple lines to CSS4.

I'd argue that expanding flexbox into two dimensions (like the XUL grid) should be higher priority than multiple lines.

dave
(hyatt@apple.com)

Received on Wednesday, 26 May 2010 01:13:04 UTC