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

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.

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.

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.

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?

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

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.

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?

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.

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.

-- 
Andrew Fedoniouk

http://terrainformatica.com



-----Original Message----- 
From: Tab Atkins Jr.
Sent: Thursday, January 27, 2011 5:44 PM
To: www-style list
Subject: [css3-flexbox] Trying out flex units again

I've finished the first draft of my attempt to do flexbox with flex
units, similar to my approach in my first drafts on my blog.

I've reverted the spec at <http://dev.w3.org/csswg/css3-flexbox/> to
dbaron's last draft, as my changes are substantial and potentially
controversial.  Plus, it's good to have the older draft to refer to
for now.  You can find the new spec at
<http://dev.w3.org/csswg/css3-flexbox/Overview.new.html>.  I'll swap
this to the main Overview.html file when the WG gives me at least a
token approval that I'm going in an acceptable direction.

I'm finally, actually, happy with this draft.  It feels right to me.
I'll give a quick rundown of the spec and what it involves:

New display value
-----------------

Just changed the names, to 'flexbox' and 'inline-flexbox'.  'box' was
far too generic of a term, given CSS's usage of it to refer to the
nodes of the box-tree.

flex-direction
--------------

A combined form of the current draft's 'box-orientation' and
'box-direction'.  I've gone over why I think this should be a single
property before.

flex-order
----------

Rename of 'box-ordinal-group', to fit with the flex- prefix and have a
shorter, easier name.

Flex units
----------

Flexbox children can use flex units in their margin, padding, width,
and height to specify that they are flexible, and by how much.

Flex units can be specified in two ways.  The first, using the 'fl'
unit, produces "absolute" flex, which starts from a preferred size of
0.  This fits the mental model of many people, as exemplified by
several comments in Daniel's thread a little while ago.

The second way is to use the flex() function, which produces "additive
flex".  In its simplest form, it takes a preferred size and a
flexibility, like "flex(auto, 1fl)", which creates a flexible length
with a preferred size equal to what 'auto' would produce and a
positive flexibility of 1 (no negative flexibility, so it won't shrink
if the flexbox gets too small).  You can optionally provide a negative
flexibility and min/max sizes for the length.  Additive flex is
necessary for many useful cases, as dbaron illustrated in Daniel's
thread.

flex-pack
---------

Rename to match the spec's convention.  It's otherwise identical to
the current spec.

flex-align
----------

This property is vaguely similar to the box-align property in the
current draft.  If it's 'auto', it does nothing special - free space
is distributed to the flexible lengths in the standard way.  If it's
'baseline', the flexbox children are first baseline aligned, then use
a slightly modified algorithm to distribute free space to the flexible
lengths in such a way as to maintain the content's alignment.  This is
intended to be a simple and sufficient solution to the use-cases that
require baseline alignment.  I would really love a good description of
several such use-cases, so I can ensure I design the free space
distribution correctly.  Right now the only thing I've got is "tabs".


I would love review of this.  Like I said in a previous thread, and
several times personally, I just don't think the keyword-based
approach to flexbox is viable.  The current draft has a few use-case
holes that, when you try to plug them, produce something
overcomplicated; as well, it's apparently unintuitive to have 'width'
and 'height' change to merely be inputs into the flex algorithm,
instead of either fully respected or fully ignored.  This new draft
hits the same full set of use-cases, but I think is really simple and
easy to use.

~TJ

Received on Friday, 28 January 2011 06:35:40 UTC