Re: [css3-flexbox] resolving flexible lengths

On Fri, Sep 30, 2011 at 1:38 PM, Ojan Vafai <ojan@chromium.org> wrote:
> On Fri, Sep 30, 2011 at 9:21 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>>
>> On Thu, Sep 29, 2011 at 8:39 PM, Ojan Vafai <ojan@chromium.org> wrote:
>> > There are a couple issues with
>> >
>> > the http://dev.w3.org/csswg/css3-flexbox/#resolving-flexible-lengths step.
>> > 1. It's not clear that the preferred size ignores min/max constraints. I
>> > think the spec should explicitly state that it ignores min/max
>> > constraints
>> > unless the preferred size is set to auto, in which case it takes them
>> > into
>> > account.
>> > The use-case this allows is the following:
>> > <div style="display: flexbox; width: 200px">
>> >     <div style="width: flex(1); min-width: 100px;"></div>
>> >     <div style="width: flex(3);"></div>
>> > </div>
>> > Clearly you would expect the first flex item to be 100px wide and the
>> > second
>> > to be 300px. If the preferred width took min-width into account you
>> > would
>> > instead get 125px and 75px.
>>
>> I assume you mean that we would expect both of them to be 100px wide,
>> right?
>>
>> 1. They both start at 0px (their preferred size).
>> 2. They are set to 50px and 150px, respectively.
>> 3. The first is reset to 100px and is now non-flexible.  Restart the
>> algorithm.
>> 4. The second is the only flexible box, so it gets all of the free
>> space and is set to 100px.
>>
>> I do need to be clear about when min/max is taken into account, and
>> when it's *not*.
>
> The spec needs to spell out how to compute the preferred/hypothetical size.
> WebKit's current implementation clearly does the wrong thing here and was
> modelled after the spec text. I didn't write this part of the code, but when
> I was comparing the spec text to WebKit's implementation, it took me a while
> to realize what didn't match the spec.
> "First, set all the flexible lengths to their preferred size."
> "Pretend that the flexbox is display:block, and still establishes a BFC.
> Pretend that the flexbox item is the only child of the flexbox (and also
> establishes a BFC). Resolve flexible widths/heights into their preferred
> sizes. Resolve ‘auto’ widths/heights by shrinkwrapping them. Using all this
> pretend knowledge, resolve the width and height."
> If the preferred size is a percentage or auto, then we need to compute the
> preferred size. When doing this computation, we should take min/max
> constraints into account, no?

No, I would think.  There's no reason min/max would apply to auto/%,
but not absolute lengths.  Since they clearly don't apply to absolute
lengths (doing so gives unintuitive results), they shouldn't apply to
auto or % either.

In other words, Flexbox overrides the normal way to resolve
widths/heights.  It only pays attention to min/max constraints at the
precise point it mentions them, and not before.

I definitely need to say this.  There's a reason the layout algorithm
is a rough sketch in an issue block right now.  ^_^

~TJ

Received on Friday, 30 September 2011 20:44:04 UTC