W3C home > Mailing lists > Public > www-style@w3.org > April 2010

Re: [CSS3] horizontal/vertical-align ?

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Sat, 24 Apr 2010 12:15:20 -0700
Message-ID: <AD26DD6B1EE4453EB4281AA90C5EDE3D@terra3>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "L. David Baron" <dbaron@dbaron.org>, <www-style@w3.org>


--------------------------------------------------
From: "Tab Atkins Jr." <jackalmage@gmail.com>
Sent: Saturday, April 24, 2010 8:43 AM
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:26 AM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>>> On Friday 2010-04-23 23:11 -0700, Andrew Fedoniouk wrote:
>> David, are you saying that for the markup
>>
>>   <div id="div1">
>>     <button id="button1">Hello</button>
>>     <button id="button2">Goodbye</button>
>>   </div>
>>
>> these styles (taken from Flexbox document):
>>
>>   #div1 { display: box; box-orient:horizontal; width: 300px; }
>>   #button1 { box-flex: 1.0; width: 100px; }
>>   #button2 { box-flex: 2.0; width: 140px; }
>>
>> are easier to spec/have less interaction edges than this:
>>
>>   #div1 { flow:horizontal; width: 300px; }
>>   #button1 { width: 1*;  }
>>   #button2 { width: 2*;  }
>>
>> ?
>
> No, in such a simple situation it's largely the same thing.  The
> problems come when you mix in the more complex properties and
> situations designed around document formatting.

What exactly are these problems? Any particular details?

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?

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.

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.

>
>
>> As for my educated knowledge flow/flex has exactly the same  set of 
>> things
>> that need to be specified.
>>
>> box-orient:horizontal; is exactly flow:horizontal
>> so to specify flow:horizontal you will need same number of words as for
>> box-orient:horizontal.
>> So is my confusion.
>
> As long as you stick to the simplest possible concepts, then yes,
> those simple concepts are the same across the flexbox model and your
> flow model.

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.

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.

>
>
>> And BTW another question:
>> what width will have box defined as: { box-flex: 1.0; width: 100px; }
>> ?
>>
>> As far as I understand if you have fixed width defined then you cannot 
>> speak
>> about its flexibility anymore.
>> So it appears as box-flex is already conflicting with such basic property 
>> as
>> width/height. How you guys solve such conflicts?
>
> 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?

What all this means then:

{ box-flex: 2.0; width: 56%; }
{ box-flex: 2.0; width: calc(56% + 3px); }

?

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; }

And how to define flex in both directions?

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.

Try to imagine big picture of all this: FlexBox + Template module
versus simple 'flow' with 5 simple values + flex units.

Do you *really* like that "FlexBox + Template" panorama that opens?

[1] http://www.w3.org/TR/2009/WD-css3-layout-20090402/

-- 
Andrew Fedoniouk.

http://terrainformatica.com






 
Received on Saturday, 24 April 2010 19:15:49 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:26 GMT