W3C home > Mailing lists > Public > www-style@w3.org > February 2011

Re: [css3-flexbox] Trying out flex units again

From: Andrew Fedoniouk <andrew.fedoniouk@live.com>
Date: Thu, 3 Feb 2011 22:23:58 -0800
Message-ID: <BLU159-ds106B8FCB23A8849575A097F8E60@phx.gbl>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "Alex Mogilevsky" <alexmog@microsoft.com>, "www-style list" <www-style@w3.org>
>-----Original Message----- 
>From: Tab Atkins Jr.
>Sent: Thursday, February 03, 2011 10:29 AM
>To: Andrew Fedoniouk
>Cc: Alex Mogilevsky ; www-style list
>Subject: Re: [css3-flexbox] Trying out flex units again
>
>On Wed, Feb 2, 2011 at 8:19 PM, Andrew Fedoniouk
><andrew.fedoniouk@live.com> wrote:
>> As of min constraints for margins:
>>
>> If flex margin collapses/overlays with non-flex margin then
>> the later one is used as a min constraint for the flex.
>
>In the current conception, margins don't collapse in flexbox layout.
>The use-cases where that would have been useful appear to be easily
>addressable with flex-pack instead.
>
>(But yes, in my earlier drafts where they did, an inflexible margin
>collapsing with a flexible did alter the minimum size constraint.)
>

margin collapsing is the must, IMO.

For example this:
div
{
  direction: ttb;
  flow:horizontal;
}
allows to define container with vertical text in paragraphs
and with margin collapsing in horizontal direction.
So on par with ltr texts.

>
>> In may implementation of flexes I am using existing 'border-spacing'
>> CSS property. Fixed value of 'border-spacing' on flex container
>> establishes min constraints for all flexes.
>>
>> So minimal value of the margin between two elements is
>> max( border-spacing, fixed(margin-A), fixed(margin-B) )
>>
>> 'border-spacing' is pretty handy and quite popular with flexes.
>
>Can you point me to some examples of it in use?

Consider this:

container
{
  flow: horizontal-flow; // or horizontal-wrap as someone suggested.
};

You do not know upfront how many rows you will have and
which elements will go to what row.
But you need to define somehow distance between rows and
elements inside rows.

'border-spacing' defines distance *between* children. But
distance of children from border of their container is defined
by 'padding' of the container.

Vertical border-spacing defines distance between rows and
horizontal one defines distance between elements in row.

Margins (especially non-collapsible) are barely useful in
fluid layouts.

So by defining

  flow: horizontal-flow;
  border-collapsing:10px;
  padding:0;
  border: 1px solid;

You will have potentially multiple rows of "bricks"
with 10px distance between bricks in both directions.
But distance from border of the container to children
will be zero.

All this is useful when you have multiple containers
that use different layout schemas but you would like
to have equidistant placement of all things.

>
>
>> Just for the note: I've implemented those additive flexes
>> and no one developer use them (I used to have pretty noticeable bug
>> in additive function implementation - no one mentioned it).
>>
>> I am estimating more than 500-1000 develpores at the moment who do
>> CSS design with my version of flexes. No one asked for additive flexes
>> and no one use them. Simple flex coefficient + min/max constraints
>> is enough.  That is probably not that representative sampling if to 
>> compare
>> with web designers auditorium but that are people who do
>> real desktop app UI designs ...
>>
>> I was actually very surprised that anyone found additive flexes useful.
>> I'd really appreciate if someone will show real life examples where
>> they are the must.
>
>dbaron offered a use-case - additive flexes are required to make
>nested flexboxes do what you expect, and are used in, for example, the
>url bar in the FF UI.
>

Take a look on Firefox UI. I will insist that this simple setup:

#toolbar
{
  flow:horizontal;
}

#toolbar > widget#address
{
  width:*
  min-width:XXpx;
}
#toolbar > widget#search
{
  width:15%;
  min-width:XXpx;
}

is indistinguishable from what they have there.

>There are several other simpler use-cases, too.  For example, in a
>horizontal nav, you may want each element to stretch so that there is
>equal space on each side of the titles (thus, "About" would be
>narrower in total than "Contact Us", but both would have the same
>amount of whitespace surrounding them).  This is a real requirement
>I've had before, and it does indeed create an attractive "balanced"
>appearance.  In a vertical nav, you want to make sure that items with
>one and two lines of text both look good, with the two-liners taking
>up somewhat more space.

That is easy. Depending on what you need you can use
either one of these:

ul
{
  flow: horizontal;
}
ul > li
{
  width:max-intrinsic;
  padding:*;
}

Or

ul
{
  flow: horizontal;
  padding-left:*;
  padding-right:*;
  border-spacing:10%;
}

ul > li
{
  width:max-intrinsic;
}

Or

ul
{
  flow: horizontal;
  border-spacing:10%;
  horizontal-align:center;
}

ul > li
{
  width:max-intrinsic;
}

>
>
>> BTW, about the 'flow'. I've designed recently
>>
>>  flow:radial;
>>
>> layout manager. Quite cool and useful for e.g. pie-menus.
>> See http://en.wikipedia.org/wiki/Pie_menu
>>
>> That is again about separating of display [model]
>> and the flow (actual layout manager)
>>
>> Consider this:
>>
>>  flow:radial; display:table;
>>
>> A bit artificial but why not?
>> In any case it is far from 'flex-direction' by nature.
>
>You are moving your own implementation in a direction far different
>than what the CSSWG is doing.  You've apparently found some way to
>reconcile flexes and block layout that works for you, and are now
>using flexes as the underlying layout mechanism.  That's great, but
>that's not what's happening here.  Our strategy instead is to define
>several loosely-interacting layout managers with different underlying
>constraint structures, and define how they tie together.

Ahh... That *is* the goal of CSSWG...
To create collection of loosely-interacting abstract things?
What about the idea that they actually
have to share the same DOM tree at the end?

I believe you are getting "loosely-interacting" and "modular design"
a bit over-simplified.

See: multi-column module, paged media, flow, grid and even standard CSS 2.1
('auto' in some cases, shrink-to-wrap) are all have concept
of flexes in one form or another. If your "loosely-interacting"
means that all of them will introduce their own flexes then be
ready to hear loud laugh from crowd of software and system architects.

In contrary I propose to establish common infrastructure for them:
generic flex unit and the 'flow' that will serve as an umbrella
for different and pretty much independent layout *modules*.

To be honest I am not getting you here.
That were you who said that 'flex-***' property does not work
with existing 'width' and 'height', right?

>
>I'll feel free to plunder your stuff for good ideas, but don't expect
>things to apply directly across.  ^_^
>

I am pretty "experienced kamikaze" to expect my ideas
to be applied as they are. I do not even consider all of the them to be
anyhow close to perfect. That is why I am here to discuss them
and any others. The problem is that anything that I saw that
far here are even further from ideal than simple flex/flow combination
that I propose.

-- 
Andrew Fedoniouk

http://terrainformatica.com
Received on Friday, 4 February 2011 06:24:32 GMT

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