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

On Sat, Feb 5, 2011 at 4:56 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> I like this line of thought much better too. Essentially things that normally have min/max have that accounted in flexbox algorithm, others don't. It removes a lot of complexity.
>
> I definitely support the idea that anything that any flex anywhere is two values -- positive flex and (optional) negative flex.
>
> From implementation point of view, I think the model where width/height, paddings and margins are flexible in both dimension at the same time has approximately same implementation complexity but it is conceptually simple and elegant.

Excellent.  I'll take that as at least a token level of support, so
I'll start speccing it more fully.


> I still have to get over the concern about flex() function being applicable to mainstream properties, but having effect only in special environment. It may be not that different from % which may or may not have effect depending on parent -- but % is so special that it is mentioned in each property description, and we liked the way flexbox was initially defined as a proof that an entirely new model can be introduced without any updates needed to existing specs...

I see this as similar to, but less complex than, the issue with
percentages.  Percentages have a chance of being meaningful for lots
of properties, which is why we have to call them out specially every
time.  Flexes, though, are *only* useful in the case that your
immediate parent box is a flexbox.  Also, note that <flex> is *not* a
type of <length>.  We would just update the definitions of the 10
relevant properties (margin-*, padding-*, width, height) to mention
that they take <flex> along with their other values, but all other
properties that take a <length> don't need to mention anything.


> A possible alternative to flex() with general applicability is flex-width, flex-margin-left etc. ... not sure how popular that would be, but considering what we face with writing modes, it may become not that crazy...

Hah!  However, it seems that authors are sometimes confused by the
current behavior of having box-flex and width/height be separate
properties that combine to determine the actual dimensions of the box,
so I'd like to avoid spamming that confusion across margin and padding
too.  Using flex units directly avoids the confusion entirely.


> Another suggestion for flex() function if it is the way to go -- put preferred size to the end:
>
>        flex(positive-flex [, positive-flex, [preferred-size]])
>
> this way, the most common use will not have to reiterate the preferred size, regardless of default being 'max-content' (additive model, my preference) or zero (absolute model).

Hm, maybe.  My current thinking is that the 'fl' unit is an easy
shortcut to use when you want an absolute flex - writing "1fl" is
shorter than writing "flex(0,1)".  In your model, it would just be
"flex(1)".

My model lets you easily omit the negative flex if you don't want the
length to shrink, while yours lets you omit the preferred length.  I
guess it would default to 'max-content' if used on width/height or '0'
if used in margin/padding?  I don't have a strong preference here - I
can spec your idea and see how it goes.

~TJ

Received on Sunday, 6 February 2011 01:18:53 UTC