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

>-----Original Message----- 
>From: Tab Atkins Jr.
>Sent: Friday, January 28, 2011 8:58 AM
>To: Andrew Fedoniouk
>Cc: www-style list
>Subject: 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".)

display:table element may have different table specific layouts
defined. For example:

display:table;
flow:horizontal;

display:table;
flow:vertical-wrap;

There are other pretty interesting cases. Like scrollable
grids that I have. They are all table based layouts.

display:table governs structure of rendering tree.
The 'flow' tells how exactly elements are replaced.

These two are equivalent in LTR/RTL writing systems:

display:table; flow:default;
display:table; flow:vertical;

Generally speaking:
As for now the 'display' defines requirements to
structure of rendering tree. It just happens that
pretty much all of 'display' modes have associated
default layout manager (LM).  Each 'display' type
may have various specific LMs defined.
At this stage we may focus on simple cases - set of
LM's for display: block | inline-block | list-item | table-cell
but it would be pretty wise to consider existence of others
in future.


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

It is more about -direction and -order parts than the flex-.
Word 'direction' is quite limiting.

For example these:

flex-direction: stack;  // or
flex-direction: "1 2"
                "4 3";  // template

cannot be considered as directions.

'flex-flow', 'flex-layout' or 'flex-layout-method' are
more universal/extendable and better reflect the idea.
IMHO of course.

And 'order' as you've mentioned
has to be replaced by 'index'. But I do not see any
reasonable value for the flex-order at all.
If you have templates then you do not need flex-order as
templates do reordering in more predictable manner.

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

Standard meaning of vertical-align on the flexbox itself makes no sense.
As you know vertical-align on block elements does nothing in CSS.
So it may have some meaning only on display:inline-block flexbox but,
again, only hypothetically.

vertical-align:baseline of flexbox element will not work as
baseline computation happens before flexbox vertical content computation.

Other vertical-align values are useless if you will allow
vertical flex values to be computed against line box.
That by itself has great value.
This { display:inline-block; height:*; } is pretty popular
when designers need to replace e.g. different <inputs> on the same line
and they want these inputs to be of the same height.

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

OK. Let's imagine that you have Flexbox 1 implemented.
And now you want Flexbox 2. Where will these new layout method names
go? I mean that 'flex-direction' is a wrong name for good
portion of them.

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

In most cases it is more flex box than anything else.

As an example, take a look on right side bar of Sciter
built-in help system:
http://terrainformatica.com/w3/sciter-help-system.png
That side bar is shown in two widths.
It is styled as:

#toc > ul
{
  flow:horizontal-flow;
}
#toc > ul > li
{
  display:block;
  width:*;
  max-width:auto; /* all items have the same width equal to widest item */
}

That is very close to what e.g. Windows Shell shows when you switch
"View -> Small Icons" (on W7).

>
>
>> 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.  ^_^
>

I understand. But as I said on this stage it is critical to use
proper naming.

Example of bad choice:
  background-repeat: ...

Later if you want to add new values to it like:
'stretch' - no-repeat but the image spans whole back-box.
'expand' - stretch but keep ratio.
...
background-repeat:expand is not that pretty, right?


-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Saturday, 29 January 2011 06:18:23 UTC