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

2011-02-03 06:19 EEST: Andrew Fedoniouk:
> On Wednesday, February 02, 2011 1:10 PM, Tab Atkins Jr.
>> 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.

This sounds sensible to me. If those 70 (or 50) new values are needed
with the latest flexbox draft spec and Andrew can do with much less,
then there must be some merit with Andrew's design.


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

I fully agree. If such a real world example could be represented, then
Andrew could describe how the same (or almost similar) example could be
implemented with his design. Then we can discuss if author burden is too
high with either design or if there is some important part missing from
Andrew's implementation (vs. latest flexbox design).


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

Usually when a model depends on more values under the surface
understanding it's behavior ends up being harder. The more values you
have under the surface, the more complex interactions those values can
do and the resulting behavior seems less intuitive.


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

I find current flexbox design hard in that flex() can be used to specify
both preferred width and flex - how is this simpler than just setting
e.g. 'width' to the sum of preferred width and requested flex: calc(10em
+ 1.2fl)? This way, negative flex does work exactly the same: calc(10em
- 0.2fl). I'd expect authors to have to learn about calc() in any case
because it has other uses in addition to flexbox. Not having to learn
about flex(), too, would be easier for authors.

I understand that flex() function allows having different flex settings
for shrinking and growing. I'm not at all convinced that the additional
complexity that this raises is worth the (still unknown to me) use cases
that this feature allows.


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

I believe that separating the display model and flow (layout) would be
beneficial. I find Andrew's design a bit simpler (as much as I
understand it) and he seems to be able to do it with less features added
to current CSS specification.

Perhaps all that we need is some kind of mapping from latest flexbox
spec to Andrews design. Then we can get all people speaking about the
same thing, hopefully. It currently seems to me that Andrew's design has
not been considered fully because some details are lacking (Andrew
understands those details, nobody else does).

-- 
Mikko

Received on Thursday, 3 February 2011 11:05:35 UTC