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.

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


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


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

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.


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

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


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


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

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.


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

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.

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

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


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

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


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


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

~TJ

Received on Saturday, 24 April 2010 23:23:29 UTC