- From: L. David Baron <dbaron@dbaron.org>
- Date: Fri, 25 Sep 2009 17:05:31 -0700
- To: www-style@w3.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 UTC