RE: Shrink to fit

For the record, IE8 does the same thing as Firefox 3 -- shrink-to-fit size is the parent size when the parent is smaller than optimal width and bigger than actual width after float positioning.

I'll agree with David that the requested layout mode is more computationally expensive -- it pretty requires full layout for shrink-to-fit calculation, while current behavior needs to just find the longest word (it is much, much more complicated than that, but it allow for a number of optimizations).

I think however that the reason for current behavior is interoperability more than performance. Not sure if the algorithm is documented in CSS2.1, but current implementations are clearly interoperable so this behavior is not changing.

It is of course possible to implement the other behavior too, if there is a need for it. Which leads to the next question - if an option existed for a "tighter" shrink to fit, how would it be used? Is there an example where it would make a significant difference? Perhaps something that would be really hard or impossible to do with current standard?

--Alex

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of L. David Baron
Sent: Friday, September 25, 2009 5:06 PM
To: www-style@w3.org
Subject: Re: Shrink to fit

On Thursday 2009-09-24 16:30 +0100, Neville Hillyer wrote:
> For some while I have been concerned that CSS 2.1 'shrink-to-fit' 
> cannot be made to work as many would wish except on a few old 
> browsers. An outer box cannot be made to shrink around inner boxes 
> except in the special case of the inner boxes all being on one line. I 
> have produced a web page on this at: 
> http://links.open.ac.uk/www/shrink-wrap/
>
> I am not proposing changes which would affect existing designs but I 
> am requesting an additional CSS 3 option which would invoke the 
> performance explained on my page. I accept that this would add a small 
> amount of complexity and, if imprudently implemented, may have speed 
> implications but, nevertheless, I think this more intuitive method is 
> sufficiently important to warrant this.

I think the behavior change that led to the "a few old browsers"
data point is that there have historically been two different approaches to implementing shrink-wrapping.

One is to use the same code that is used for layout, but run it in a mode where it does the layout according to different rules and computes shrink-wrap widths.  This produces better results for a small number of cases:  a few cases involving floats, and an easy choice to produce different results in the case you describe (it's hard to say whether it's better or not).  However, it is also a lot more complicated, much harder to get right, and much more likely to lead to buggy implementations of both shrink-wrapping and handling of dynamic changes in general.  The Firefox 2 behavior in the case you're looking at is sort of the natural result of this approach.
Based on looking at shrink-wrapping behavior around floats, I think this is the approach used by IE4-IE7, and by Firefox 2 and earlier.

The other is to do intrinsic width calculation using entirely separate code using an algorithm separate from the layout algorithms.  This is significantly easier to get right without major bugs, but it means that it's pretty much impossible to make intrinsic widths depend on characteristics of layout such as placement of floats relative to text.  Based on behavior in the presence of floats, I think this is the behavior used by Firefox 3 and later, by WebKit, and by Opera.

(I'm actually not sure what IE8 does, but I ought to look sometime.)

In this second approach, I think the implementation complexity of what you're calling an extra "option" is actually similar to the implementation complexity of intrinsic width calculation itself; it requires methods for every rendering object to compute the "occupied width" within a given width (and cache both the input and the result).

In other words, I think it's a lot of complexity for a relatively minor feature.  And I suspect the demand for this feature may be alleviated by having layout systems better designed for the layouts people are trying to design.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Saturday, 26 September 2009 00:38:37 UTC