Re: [css3-flexbox] Trying out flex units again

On Thu, Jan 27, 2011 at 10:35 PM, Andrew Fedoniouk
<andrew.fedoniouk@live.com> wrote:
> Tab, you do not expect me to pass by, do you?
>
> First of all about use of 'display' again.  As far as I understand
> elements that have display: list-item, table-cell, etc.
> cannot have flexible content inside.  Technically they perfectly
> capable to do so but specification prohibits this for some reason.
>
> So that hypothetical 'display-inside' of yours that
> will define flow of blocks inside the container is a must.
> But why you guys so stuck with the 'display' name?
> Why not to introduce something brand new like 'flow' or
> 'layout' and leave that 'display' alone in its current ugliness.

If the new properties are just subproperties of an existing property,
it's tradition to follow the naming convention of using the original
property as a prefix.

It's not required, but in the absence of anyone else suggesting
something different, I'm sticking with it.

(I think you're suggesting that 'display' can just function as the
display-outside property.  That's not true.  "display:table", for
example, should be "display-outside:block; display-inside:table".)


> About flex units in general. Flex units make perfect sense in context
> of tables, multi-column, page, etc. layouts.
>
> But your document explicitly prohibits this. I do not think that
> postulating such artificial limitation is present and future friendly.

This restriction will be changed in the future when we specify how
flex units work elsewhere.  For example, I think it's trivial to
support flex units in Positioned Layout, to make centering an abspos
element in its container trivial (just set all the margins to 1fl).

For now, though, I think the clarity afforded by simply saying "These
are special units, don't try to use them anywhere else because they
won't work" is valuable.


> For example our practice shows that
>  column.some { width:1fx; }
> in tables is pretty useful.
>
> I don't think that such artificial limitation makes any sense.

Tables are grossly underspecified right now.  Until someone actually
sits down and specifies how tables work, I'm not touching them with
flex units.


> About the choice of names 'flex-***'.
>
> 'flex-direction' can and will be read as "direction of flexibility".
> Which is not exactly the case with flex units as far as I understand.
> Even in horizontal containers child blocks are flexible in both directions.
>
> 'flex-order' is even worse -  "order  of flexibility".  Very far from
> "rendering-index" meaning. Why not to reuse 'z-index' for that at the end?

The naming intent is to logically group them together with a short
prefix.  Several people have responded favorably to the "flex-" prefix
without confusion, so I'm going to stick with it for now.

> 'flex-pack' is a synonym of either vertical-align or horizontal-align
> (hypothetical)
> When 'flex-pack' happens to be in vertical direction how it interacts
> with existing 'vertical-align'?

It doesn't.  vertical-align has no meaning on flexbox children, as it
is defined only for inline and table layout.  I need to mark that in
my list of properties that don't do anything in flexbox layout.
Putting vertical-align on the flexbox itself has the same meaning as
it would on any block or inline.


> If to consider the need of defining <center> element behavior in CSS then
> we need to introduce 'horizontal-align' anyway. I propose to drop
> 'flex-pack' and 'flex-align' completely and to use vertical-align and
> horizontal-align
> instead.

As I said in my email, I've already tried the keyword approach.  I
can't get it to work in a sufficiently elegant way while hitting all
the use-cases I want.


> In general this spec is better than previous attempts and I am trying to
> match
> it with what I have:
>
>  flow:horizontal  == flex-direction: inline;
>  flow:vertical      == flex-direction: block;
>  flow:horizontal-wrap == ?
>  flow:vertical-wrap == ?
>
> Last two are multi-row and multi-column
> block flows. As far as I understand your spec have no wrapping
> options at all?  Any plans for that?

At this level, no.  No browser has implemented multiline flexboxes so
far, despite them being in the older draft for some time, so I'm
considering them relatively low-value here.  I'd rather get the basic
flexbox stuff mature and implemented first.

It's definitely something on the table for Flexbox 2, though.


> flow:vertical
> flow:horizontal-wrap
> flow:vertical-wrap
> are quite widespread in UI. E.g. in almost any OS folder view in GUI shell
> uses all three of them for presenting file names in different modes.

Folder views don't quite use a multiline flexbox, they use some sort
of grid.  I'm thinking we can solve this by bolting some additional
functionality onto tables.  For example, a property that defines the
number of columns in a table, and affects the generation of anonymous
table-row boxes (so that it'll only wrap the specified amount of cells
in a row, and start a new one if there's more).


> I would like to highlight again the following:
>
> There are quite a lot different and very useful layouts. E.g.
> flow:stack; - similar to card deck but with the ability to use flexes.
>
> Such variety does not fit nor in 'display' nor in
> 'flex-direction' as for some layouts term 'direction' is quite
> far linguistically speaking.

I'm interested in pursuing more layout models in the future.  Once
I've gotten flexbox into a maintenance mode, I'll start on Positioned
Layout, and I expect to contribute to Grid Alignment as well.  If
there are more useful layout models after these three are done, I'll
definitely want to work on them.  ^_^

~TJ

Received on Friday, 28 January 2011 16:58:52 UTC