Re: [CSS3] horizontal/vertical-align ?

On Sat, Apr 24, 2010 at 8:52 PM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
> 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?

Let's say you instead had this:

<p>foo <img height=400px> <i height=1*>bar</i></p>

What's the height of the <i>?

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

Turning 'display' into a shorthand is a fairly minor change, since all
current values are still accepted.

Adding new display-inside properties has no effect on the complexity
of the box model.  For example, adding display:table did not make the
box model any more complex, because it doesn't interact with the box
model.  On the outside it's just a block or an inline-block, and
interacts exactly as expected.


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

The term is defined in CSS2.1.  It just means the normal way of laying
out text and block elements.  Everything that's not absolutely
positioned, a table element, or a ruby element uses static layout to
position itself.


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

container { display: box; }
container > child { box-align: end; box-flex: 1; }

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

300px, as it is capable of flexing to the full width of the container.


> What if container is say of width:150px; ?

150px, as it is capable of flexing itself that small.

> And how is it different from just:
>
> min-width:100px;
> max-width:400px;
> width:*;

All by itself in the container?  No difference.  But when combined
with another element, you see the difference.

Say you had a 400px wide container with two children; the first has
width:100px, the second has width:200px.  Both have box-flex:1.

The natural widths of the children add up to 300px, so there's 100px
left over to use for flexing.  This gets split evenly between the two,
so you end up with the first child being 150px wide and the second
child being 250px wide.


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

Sorry, I'm not being precise.  When I talk about the width it "starts"
with, I mean the computed value for width.  "ends with" is the used
value, after figuring out how much flex to add/subtract.


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

That's all done in the draft.


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

The width property provides a preferred width for the box, and is used
to figure out how much space is available for the flex calculation.


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

No, in this case the two elements don't change their widths at all.
Their preferred widths are 30% and 70%, which add up to 100%.  That's
exactly the width of the container, so there's no free space left
over, nor is there any "overflowing space".  So nothing needs to
change its width.

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

With luck, the example above have explained what width is used for,
and what is meant by that phrase in the draft.  The draft is very
precise about what is meant, and describes exactly how to calculate
the widths of boxes based on their width, min/max-width, and box-flex
values.


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

That depends on the width and flexibility of any siblings it has.
When the computed width of a box changes, that alters the amount of
leftover space, and thus alters the distribution of that space.


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

Correct, flexbox does not allow that.

Can you point me to pages that use this sort of layout?  I haven't
seen any so far, but new use-cases are always awesome to find.


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

In Flexbox and Template, the two corresponding declarations are *not*
the same.  When you get to slightly more complex examples, the
differences become much more obvious.  A multi-line template, for
example, aligns its cells just like a table does.  A multiline flexbox
doesn't impose any relationship between boxes on one line and boxes on
another.


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

I'd be happy to explain after you understand what the Flexbox draft
actually says.  At the moment you are drawing a number of incorrect
conclusions from what appears to be a hasty reading of it, colored by
your own experience with your implementation of flexes.


~TJ

Received on Sunday, 25 April 2010 04:56:16 UTC