Re: [CSS3] horizontal/vertical-align ?

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

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

vertical flexes in inline-block elements are computed against 
line box. So that <i> will have 400px height.

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

On "adding display:table did not make..."

A lot of code relies on  
  display: none; 
  display: block; 
to switch visibility. If suddenly <table> transforms into 
just a display:block it is a trouble.
Before the display:table all that blocks were just display:block's.
That was a bit risky decision to change display type of elements
already published in the wild.
> 
> 
>> 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.
> 

I am not aware "static layout" term, sorry.

I know that position:static is a static positioning. 
Static positioning means that for replacing such elements 
some CSS built-in algorithm used. 
No matter of the display. Table layout is a perfectly static 
layout. That is why my confusion.

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

So width value is ignored here. Confusing at least.

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

Uh... Cool...

So if container has width, say, of 200px then width value 
of children is not used and distribution of widths will be 1:1. 
If it happens to be greater than 300px than suddenly distribution 
will be calculated using some other non-linear formula.  

Such non-monotonic functions are highly non-desirable in
layout algorithms - may even cause oscillations. 
At least animations in such circumstances may bring some 
surprises.

Thinking about how this setup will work when container will 
change from 200px to 300px. I cannot predict how all this will
be calculated. Highly non-intuitive. At least for myself.

> 
>> Is it possible to define all this somehow more formally?
>> Like using math or so?
> 
> That's all done in the draft.
> 

In the one that is published? If yes then where?

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

I do not understand this. You and spec say that used value of the width
can be less than its declared (a.k.a. preferred ) value.  
But it can be less only when no free space left in container. 
Are you sure you understand all this in the right way?

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

And what happens if you have this:

1 { box-flex: 2.0; width: 30%; }
2 { box-flex: 2.0; width: 69%; }

what would be their width ratio? 1:1 or 
close to 30:69? If later one then what box-flex 
value is used for? If 1:1 then the same question about 
widths.

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

Pretty much any page on the Web.

display: box;
box-orient: vertical;

And now imagine that you have some headers centered. 
You have to be able to align elements individually.

There is a question actually what margin:auto means 
in context of box-orient: vertical;

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

Ok. For three elements in a container

flow: horizontal;
flow: "1 2"
         "1 3";

horizontal will replace elements in single row.
Second declaration will make two rows with first child to span 
two rows. The difference only in the way how blocks will be laid out.
Nothing changes in principle. The container itself will have the same 
display value and its children will use same metrics and principles
of width/height, min/max calculations.

In the same way as changing from box-orient: horizontal  
to box-orient: vertical should not require introduction of brand new 
module in CSS with its own units and bunch of properties.

I am not sure if I put this clear enough. Hope you will get what I mean.
> 
> 
>> 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.
> 

Actually I went even further. I've implemented flexes. So something 
I do understand. I hope so at least.

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Sunday, 25 April 2010 07:30:51 UTC