W3C home > Mailing lists > Public > www-style@w3.org > September 2009

Re: Shrink to fit

From: L. David Baron <dbaron@dbaron.org>
Date: Fri, 25 Sep 2009 17:05:31 -0700
To: www-style@w3.org
Message-ID: <20090926000531.GA23525@pickering.dbaron.org>
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:06:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:21 GMT