Re: Flexbox Draft, with pictures!

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:
>> 
>>>> 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;'

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

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

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?

Received on Thursday, 27 May 2010 04:36:53 UTC