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

>-----Original Message----- 
>From: Tab Atkins Jr.
>Sent: Wednesday, February 02, 2011 1:10 PM
>To: Alex Mogilevsky
>Cc: www-style list
>Subject: Re: [css3-flexbox] Trying out flex units again
>
>On Wed, Feb 2, 2011 at 11:50 AM, Alex Mogilevsky <alexmog@microsoft.com>
>wrote:
>> The difference between the original spec and this draft is that instead
>> of one flex value stored per element there is up to 70 (up to 5 values
>> in flex() function, times margins, borders, padding, width and height).
>> It is not all that difficult to implement but it is more storage, more
>> testing and more complexity for the user... Is there a good reason?
>
>Yes.  Without flex(), you can only specify preferred/minimum sizes for
>width/height.  This means that in the minimum-space situation you're
>*required* to either have inflexible margins/paddings, or let them
>shrink to zero.  This can produce unattractive layouts - it's common
>to depend on some minimal degree of margin or padding for legibility
>and aesthetics.

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

>
>(Not that it reduces your argument too much, but borders aren't
>flexible.  Last time I tried to do that I got pushback but not any
>support, so I'm just dropping it.  So that's only 50 values.  As well,
>there's not just one value stored per element in the current model -
>you still have to remember the values of margins, paddings, width,
>height, and the min/max versions of the last two, plus we'd agreed to
>do both positive and negative flex.  So it's more like 16 vs 54 (50 +
>min/max-width/height), not 1 vs 70.)

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.

>
>This is theoretically more complex, in that there are more values, but
>in practice it appears that authors find this simpler.  It seems to
>map well to how people *want* to think about flexible boxes, so they
>don't need to create new complexity in their mental models.
>
>It's possible that flex() itself is too complex, though.  Widths and
>heights already have min/max constraints, so they only need preferred
>sizes and the two flexibilities.  I think my use-cases could get away
>with just having margins/padding take a preferred size, a positive
>flexibility (indicating it can grow, with no max), and optionally a
>negative flexibility (indicating it can shrink, with no min).  Would
>it make you happier to track only 3 values per property rather than 5?
> That would reduce the difference to 16 vs 34, and additionally
>simplify the processing model somewhat.
>

Can I remind that in general adding flexes in CSS is a matter
of adding one type of length value - flex unit per se and
single property - the 'flow'. Everything else is already in place.


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.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Thursday, 3 February 2011 04:19:51 UTC