Re: Flexbox Draft, with pictures!

On Wed, May 26, 2010 at 9:36 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
> On May 26, 2010, at 11:32 AM, Tab Atkins Jr. wrote:
>> On Wed, May 26, 2010 at 10:07 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>>> On May 25, 2010, at 10:14 PM, Brad Kemper wrote:
>>>> On May 25, 2010, at 6:12 PM, David Hyatt wrote:
>>>>> Regardless, I think additive flexing vs. replacement flexing is a key distinction here, and it would be good to make both easy to specify.  Having to do width: calc(fit-to-content + 1fl) just to do the former seems gross.
>>>>
>>>> Why not this:
>>>>
>>>> 'width:1fl;  min-width: fit-to-content;'
>>>
>>> So, I'll be the first to admit I might be missing something. Is there any reason why it can't be this simple, instead of having to employ 'calc()'?
>>
>> Basically, I think the distinction between a "minimum size" (the
>> length *cannot* shrink below this) and "preferred size" (the length
>> starts here, and can then grow or shrink based on available space) is
>> valuable to preserve.  I definitely think that we don't want
>> "min-width" to mean something other than "the minimum width of the
>> box".
>
> That's not what I was suggesting. David Hyatt presented the idea that 'width: calc(fit-to-content + 1fl)' was a cumbersome (gross, actually), but he was responding to your reply to his earlier point 6, in which he was talking about how to prevent an image from shrinking "below its minimum intrinsic width." He mentioned that in the current additive model, "the image will not be able to shrink below its minimum intrinsic width." Thus my code that prevents that particular thing:
>
> 'width:1fl;  min-width: fit-to-content;'

Oh, okay.  Yes, if you want an image to flexibly scale, but not shrink
below its intrinsic width, then what you suggested is correct:
"width:1fl; min-width:fit-content;".  The most obvious solution is the
correct one, which is what we want.  ^_^


> However, I admit to mixing up the two models in my mind a bit. And regardlessly Dave did not want to have to do a calc(fit-to-content + 1fl) in order to simulate additive flex by using absolute flex units. The above would not go that far by itself, because it does not distribute the _leftover_ space (or lack thereof using negative flex), it only distributes the total space (I think I understand this right now; it's all starting to sink in more and more).

It's much easier, I think if you don't try to think of absolute and
additive flex as being different; they're really not.  My distribution
algorithm, which I believe captures the correct behavior, doesn't
distinguish between the two.  Here's how it works, generally:

First, figure out the free space.  Take the total amount of space, and
subtract from that all the inflexible lengths, and the minimum size or
preferred size of each flexible length (whichever is bigger).  Then
distribute the free space, adding it to the preferred width of each
length.

If I say "width:1fl", that has a preferred width, it's just 0px.  It's
not treated any differently than "width:calc(50px + 1fl)" or
"width:calc(fit-content + 1fl)" - the only difference is the preferred
width of each length (50px and fit-content, for those two).


>> Based on a short discussion with dhyatt, though, I think I agree that
>> we should make the most common additive-flex case easy, where the
>> preferred size is the fit-content size.  I suggest a second flex unit
>> which operates similarly to how the current draft of flexbox does
>> flexes.
>
> Two different kinds of flex unit seems likely to confuse and complicate. I'd rather have 2 properties to describe what the width or height should be before distributing flex space.
>
> 'width:1fl;  pre-flex-width: fit-to-content;'  /*additive flex width */
>
> 'width:1fl;  pre-flex-width: 0;'  /*absolute flex width */
>
> 'width:1fl;  pre-flex-width: 10em;'  /*some "preferred width" */
>
> Since width and height seem to be all that matter for the difference between absolute and additive, you can still use the single fl unit on other measurements, such as margin, padding, or border-width.

Possibly.  Additive flex still makes sense for padding/border/width,
but the specific common case hyatt is complaining about is only
applicable to width and height.


> BTW, why not flex units on 'border-radius', as long as that was a child of a flexbox (I might want bigger radii if my padding gets substantially bigger)? Or on border-image-width, since it can be based on border-width anyway (as the UA will therefore need to be able to translate what flex units mean to border-image-width)? Or the offsets of box-shadow, which you might want smaller if the margins or element widths are small?

border-radius, border-image-width, etc. don't participate in any
sizing calculations for their box; I don't know what flex units could
possible mean in that context.  Percentages do the job for most such
cases, don't they?  If not, then you're talking about a more general
constraint system, which is out of scope for this spec, but might be
interesting to pursue separately.

~TJ

Received on Thursday, 27 May 2010 17:45:28 UTC