Re: [css3-box] Issue with the current shrink to fit algorithm

On Thu, Oct 28, 2010 at 3:46 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 10/28/10 7:52 AM, Giuseppe Bilotta wrote:
>>
>> Therefore, I propose the following small change to the shrink to fit
>> algorithm: the preferred width should be computed by considering not
>> only the explicit linebreaks, but also the ones that would occur if
>> the width matched the containing block width.
>
> Determining the latter involves doing a full layout on all the descendants,
> no? And if you have nested shrink-wrap containers, doing that a number of
> times that's exponential in the nesting depth?

And how is that different from the first step of the current
algorithm? Don't you need to do a full layout of all the descendants,
including their shrink-wrap containers, to determine the preferred
width in that case too?

The only difference I see is that in the algorithm currently used, the
layout is done assuming max-width: none, whereas in my case it would
be done assuming max-width: available-width. Or am I missing
something?

There's an additional bonus here, too, since most of the results of
the layout during the "preferred width not greater than the available
width" can actually be directly used, whereas with the current
specification, after laying out the inner boxes assuming no max-width
you'd have to re-layout them assuming the shrinked width.

>> (2) find the preferred width by formatting the content as if the width
>> was set to the available width
>
> Gecko used to do this.  It turns out that it causes performance nightmares

As per my comments above, I find this surprising. If anything, the new
algorithm would be more efficient rather than less.

> and _still_ gives "incorrect" results in many cases.  The set of cases where
> this behavior helps is very small...

I would like to know of some of the cases where my proposed algorithm
would give "incorrect" result, although I would assume that nested
shrink-to-fit would give unexpected results in a few cases. But i
would dare say that these cases are fewer than the cases where the
_current_ shrink-to-fit does not actually _shrink_ to fit its
contents, instead expanding to match its container width.

-- 
Giuseppe "Oblomov" Bilotta

Received on Thursday, 28 October 2010 14:53:16 UTC