Re: [CSS3] horizontal/vertical-align ?

--------------------------------------------------
From: "Tab Atkins Jr." <jackalmage@gmail.com>
Sent: Saturday, April 24, 2010 4:22 PM
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: "L. David Baron" <dbaron@dbaron.org>; <www-style@w3.org>
Subject: Re: [CSS3] horizontal/vertical-align ?

> On Sat, Apr 24, 2010 at 12:15 PM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>> What exactly are these problems? Any particular details?
>
> Dealing with flex units surrounding floats and anything to do with
> inlines gets relatively confusing.  That whole model is pretty crazy
> and difficult for authors to understand anyway; we don't need to be
> making it more complex.

I am not sure I understand the problem. Or what exactly makes it
more complex.

This
<p>Label: <input style="width:1*" /></p>
is not more complex than, say, this:
<p>Label: <input style="width:25%" /></p>

Where exactly you see the problem?

The only difference that style="width:1*" will make that input
to span all available horizontal space in line box.

Line box horizontal dimensions are established by <p> element
plus any floats on sides of it. Nothing new.

Things like <input style="width:1*" /> are widely used and quite popular
for aligning inputs on screen resolution aware forms. If this matters of
course.

The flex behavior in inlines is very close by the concept to 
text-align:justify
and actually it is implemented as a part of text-align:justify calculations.
I see no even subtle problems/conflicts with existing CSS functionality.

>
>> As for me the 'flow' is significantly simpler to specify
>> - it does not require any changes of existing properties.
>>
>> So you can define this:
>>
>> { display: block; flow:horizontal; }
>> { display: inline-block; flow:horizontal; }
>>
>> And in case of flexbox you are going to extend existing
>> 'display' property that is enough bloated already.
>>
>> As far as I understand, your recent effort to
>> split that 'display' into two parts is also about this,
>> correct?
>
> Yes.

Thanks, that is what I suspected.

>
>
>> Because if you have display: box;
>> Then you will want the whole bunch of them
>>
>> display: box | inline-box | list-item-box | table-cell-box.
>>
>> The same apply to proposed Template module BTW.
>
> No, there's no need for all of those.  The 'flexbox' value is for
> display-inside.  You can then set display-outside to be 'block',
> 'inline', 'list-item', or 'table-cell' without any trouble.
>

So Flexbox requires not only its 8 new properties but also
2 new of 'displays' that by itself require major redesign.
Each new property especially like these adds new dimensions
to compatibility matrix. The display interacts pretty much with
all box related properties so this really a lot - the whole setup
will be too fragile.

>
>> That is why my confusion: you have started some
>> task to make CSS ready for the Flexbox - to change
>> even architecture of the 'display' property itself.
>> Seems like Flexbox taken as "it is" does not fit into
>> existing CSS infrastructure, am I right?
>>
>> And at the same time David insist that "Flexbox is largely
>> separate from the existing box model."
>>
>> That all looks not exactly fair to be honest.
>> At least it creates such an impression.
>
> I believe there's some form of disconnect in our understanding.  Let
> me lay it out a little more clearly, and hope that it helps.
>
> CSS2.1 has two layout modes - table and static.  Static layout is
> designed for the layout of documents, and happens to work all right
> for simple websites, but precisely the features that make it useful
> for documents (a relatively robust text-handling model, floats, etc)
> make it less suitable for application layout.  There are just too many
> details that don't help you when you're doing application layout, but
> you still have to define how they interact if you want to add new
> abilities to it.

I am not quite following you here.  What meaning you give to 'static'?
I suspect it is far from "position:static" right?

If to speak about layout managers used in CSS then there are
three major layout models at the moment:

"text flow" content is laid out by rules of text flow - it is all about
inline, inline-block and character glyphs replacements. This model
has concept of line box.

"block flow"
content blocks is laid out one by one vertically. If some child
elements are not generating boxes (are not display:block | list-item )
then CSS specifies that anonymous box has to be created to contain
them. This mode has a concept of margin collapsing.

"table flow"
elements are replaced in a grid forming columns and rows.
Conceptually this very close to block flow just different
layout rules used to replace elements.

And that is it.

My 'flow' property simply specifies how exactly block flow
replaces its children. Conceptually there is nothing new here.
If you can have default flow:vertical or flow:table then nothing
should stop you to say flow:horizontal to replace children horizontally.
This is very natural and logical extension of principles that we have
already in CSS. No revolution here, just progressive advance.

>
> Flexbox avoids having to deal with that by defining a third layout
> mode.  Within a flexbox, there's no such thing as text, no such thing
> as lineboxes, no such thing as floats, etc.  The children of a flexbox
> are guaranteed to be blocks, and the pack/align/flex interactions are
> very simple and well-defined.  Doing this sort of thing lets you
> introduce new abilities without having to define increasingly-complex
> interactions with all the existing properties.

In FlexBox interactions are not simpler or more complex than
in elements under flow:vertical | horizontal. They are based on *exactly*
same principles. So if something is defined for FlexBox it can be defined
using exactly the same set of words in 'flow'.

But the 'flow' manages to do all this by using single property and
very simple to understand flex units already used in HTML.
And it does not require to redesign the 'display' and its friends.

And yet the flow/flexes allow you to specify things like this:

container { flow: horizontal; }
container > child { width:1*; margin-top:1*;}

See: 
http://www.terrainformatica.com/w3/flex-layout/images/sample-horizontal-bottom.png
that are in principle not achievable in FlexBox as it uses pretty
strange and limited one-dimensional flex system.

>
>
>> Any other value of the 'flow' is not anyhow different
>> from flow:horizontal. The only thing that changes is the
>> layout of children.  All other features stay the same.
>> So I do not understand how "simplest possible concepts"
>> are different from other possible concepts.
>> It is simply one concept - if you will specify it - you will
>> specify everything.
>
> Your "flow: vertical" is the ordinary static layout defined by CSS2.1.
> It's not the same thing as a vertical flexbox.

Negative.

flow:vertical is not flow:default.

flow:vertical 1) establishes context for flex calculations. So
if there is an empty space inside it then any child that have
say height:1*; will take that space (or portion of it).
And 2) any child of flow:vertical container establishes so called
flow root - e.g. it is a box for floats in the same way as
display: table-cell.

See #4 in http://www.terrainformatica.com/w3/flex-layout/flex-layout.htm
And this screenshot from flow/flex demo pack:
http://www.terrainformatica.com/w3/flow-flex-floats.png

>
> For example, what happens if you do float:left in a flow:horizontal
> box?  What if you have <div
> style=flow:horizontal;><i>foo</i><i>bar</i></div>?

Exactly the same that is specified in FlexBox at the moment.
flow: ... suppresses float interpretation on its immediate block
children.

If <i> elements there are declared as inline-blocks then
anonymous box is created to contain them. And if one
of this <i> has float:left than bounds of that anonymous
box will serve a role of float root container so it will float.
But not on <div> bounds.

As I said that is exactly what is specified in the FlexBox.

>
>
>> Say you will want to add in the future something like
>> "flow: stack' that will replace children in pack of cards.
>> You will not need to introduce new Stack Module for that.
>
> I'm not sure I understand the significance of creating or not a new
> module to organize the properties associated with a new layout mode.
> Modules are just a way of organizing things.

My implementation of flow:stack interprets flex units against bounds (box)
of the flow:stack container.  In flow:vertical free space distributed
among all children having flexes in size, margins and paddings.
In flow:stack flexes of each block are computed as if this block is the
only one in container.  So specification of such new layout as flow:stack
is one paragraph or so - it does not require full cycle of WD/TR - it is
just a next version of the document. So CSS can respond faster to
this changing world. Actually I have a queue of 3 more pretty
cool values (layout managers) for the 'flow'. E.g. flow:fixed-table
that allows to handle tables (a.k.a. grids) having >10,000 rows
in tables. Any existing UA will die on this.
I have a sample that is close to Excel sheet that has 50,000 rows with
20 columns.  People from Google Docs team can only dream about
such things.

>
>
>>> The 'width' property is a starting-point when box-flex is active; it
>>> provides a "preferred width" for the box.  The box will still grow or
>>> shrink as appropriate if the sum of all the preferred widths of the
>>> children of the flexbox are more/less than the width of the flexbox.
>>> Only max/min-width actually prevent flexing past some bound.
>>
>> That really stinks indeed. Sorry for the use of such vulgarism.
>> I simply have no other words about this idea.
>>
>> 'width' suddenly changes to some esoteric "preferred width" thing.
>> And you say it is not a change of existing box model.... How come?
>
> I never said it's a change to the existing box model.  The inside of a
> flexbox is definitely different from the "standard" box model (that
> is, static layout).

Side note: For some reasons  my mental parser has difficulties
handling "static layout" construct you use.

>
> The reason width is used that way is because it's the most sensical
> thing.  A non-flexing box is exactly the width it says it wants to be.
> A flexing box *starts* at that width, but declares that it's flexible
> if needed.  What's the point of making width be absolute if you're
> flexing?  You want a definite width inside a flexbox, you just have to
> declare box-flex:0.

Oh, my... What does it mean "*starts* at that width"?
And when and where it *ends* then?

Say we have element with the style:

min-width:100px;
max-width:400px;
width:200px;
box-flex: 1.0;

that is replaced alone in container having width:300px; then
what be its used width? What if container is say of width:150px; ?

And how is it different from just:

min-width:100px;
max-width:400px;
width:*;

?

>
>
>> What all this means then:
>>
>> { box-flex: 2.0; width: 56%; }
>> { box-flex: 2.0; width: calc(56% + 3px); }
>>
>> ?
>
> It means exactly what it looks like.  Both boxes start at their
> preferred widths (56% and 56%+3px, respectively), and declare that
> they're willing to flex.  Because they're guaranteed to add up to more
> than the width of their parent, they will definitely flex to be
> smaller.

Umm... that "start" again ... Is "start" about moment of time or is it
related to min/max bounds or what?
I've implemented flex algorithm but have no idea what this start-width
means and where to attach that sleeve. Honestly.
I suspect that I am not alone in this.

Is it possible to define all this somehow more formally?
Like using math or so?

>
> Since their box-flex values are the same, they'll shrink by the same
> amount.  In the end, they'll be exactly the size necessary to fill
> their parent, and the second box will still be 3px larger.

Oh... but what the width value will be used for at the end?

Say I have another setup:
1 { box-flex: 2.0; width: 30%; }
2 { box-flex: 2.0; width: 70%; }

what will be the difference with the previous one?

Something tells me that used values will be the same in this
case too.

It like my wife's favorite: "Our coffee is in that box from tea with
attached "salt" sticker on it. That is really easy to remember..."

Seriously: does anybody know what is width value used for
in display:box? Explanation should not contain term "starts" in it
if possible. Please, huh? I am intrigued.

This:

"In a horizontally oriented box, the flexibility is then applied which
may increase or decrease the used width." (C) David Baron, here:
http://www.w3.org/TR/css3-flexbox/#inlinesAndBlocks
sounds like an instruction for gambling machine: you may or
may not get what you have asked for. So why bother
to ask at all? Why to define the width? As it seems it is
not used anyway?

>
>> And what exactly will happen if you will use, say, use
>> transition on the width property:
>>
>> div: { box-flex: 2.0; width: 100px; }
>> div:hover { width: 200px; transition: width 1s; }
>
> It'll work as expected.  The computed value of width changes, so the
> transition will fire and animate the change in width.

And? What actual width that box will have?
I have strange feeling that FlexBox just discards any value of the width.
At least it is absolutely not clear from that document.

>
> (Of course, it's possible that the used value of width doesn't change
> at all, frex if it's the only child of the flexbox, as it will have
> already flexed to the full width.  Transitions only care about
> computed values, though.)

I am lost here, sorry.

If declared value of the width is not used for used-width
calculation then again what is this 'width' used for?

>
>
>> And how to define flex in both directions?
>
> The other direction flexes implicitly based on the box-align value.
> start/end/center flexes the margins, and stretch flexes the height (or
> width, for a vertical flexbox).

So no chances for explicit flexes in both directions?

Say in flow:horizontal I will want som elements to be aligned
to top and some to bottom. As far as I understand that box-align
will not allow me to do so, correct? If so then this is definitely bad
as such layout are used already.

>
>> And yet.
>>
>> Template Module[1] "de facto" introduces flex units among other
>> things and its own details of box model.
>> But these two modules, FlexBox and Template define the same entity -
>> layout manager for block content, not more not less.
>
> Exactly correct.  Template has flex units, and it's a further new layout 
> mode.
>

With two elements in a container these two declarations:

flow: horizontal;
flow: "1 2";

are equivalent. Template just defines different order of elements flow
that cannot be expressed in terms of linear vertical/horizontal flows.
All other features are exactly the same. Why do we need separate
module and so procedure of its approval? What is the motivation?
Someone at W3C is getting paid for number of lines in specs?

>
>> Try to imagine big picture of all this: FlexBox + Template module
>> versus simple 'flow' with 5 simple values + flex units.
>
> I'm not sure I understand the distinction you're trying to make.
> Combining Template and Flexbox is the same as combining your template
> and horizontal flow, for example.
>
> The only thing that's different is that the CSSWG is explicitly
> separating out static layout as a third type of layout mode.

Here is the problem how I see it:

There are two modules that, as we agreed, define in principle the same
thing - just two different layout managers. Both modules use
the same concept of flexes. But one uses flex units for defining
flexibility and another uses that box-flex thing.  At least Template
is not so limited and allows to specify flexes in both directions.

Sorry but from outside this looks like a plain and very childish design bug
of the whole system.

By my flow/flexes I have demonstrated that all this can be combined
into single, simple and proven to be useful, stable and extendible system.

So if someone think that such dichotomy of FlexBox and Template
modules is the way to go I would like to hear arguments what *exactly*
makes FlexBox and Template in their current forms to be so attractive.

>
>
>> Do you *really* like that "FlexBox + Template" panorama that opens?
>
> Yes, I very explicitly want to combine the two.  A lot of website
> layouts that are fairly complex and difficult to understand using
> current CSS properties become *enormously* simpler if you redo them
> using template and flexbox together.  Earlier this week I reviewed a
> bunch of complex websites both within Google and without, and
> established that this is definitely true.  And, because each defines a
> new and separate type of layout, understanding how they work and using
> them in practice is much simpler.
>

If you want to combine these two then you should start from
marrying flex units with box-flex and other box-** properties.
If you will really go that way you will end up with flow/flex.
Actually I have started from my own implementation of XUL
and discovered at early stage that xul:flex attribute is a path
nowhere - does not fit into CSS - foreign body - too many
conflicts like the one with width/height values.

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Sunday, 25 April 2010 03:52:29 UTC