CSS2.1 has a nice complicated algorithm for sizing of replaced elements while preserving aspect ratio (currently our image frames use it), and there are plans in the works to make it more complicated yet (to make it work for cases when there is no intrinsic size but just an intrinsic aspect ratio). See http://lists.w3.org/Archives/Public/www-svg/2005May/0026.html I think we should factor this code out of nsImageFrame, either into nsLayoutUtils or into some shared "replaced element frame" class that will be used by images, <svg:svg>, etc. And implement that proposed algorithm, of course....
roc, didn't you do some work related to this about making iframes wrap around their content or something like that?
Yeah, I have a patch for that, but I'm not sure it's related to this bug.
Wasn't this done in bug 300030 which introduced nsLayoutUtils::ComputeSizeWithIntrinsicDimensions ?
More or less, except that's the old algorithm so far -- the one that doesn't handle intrinsic ratios, just intrinsic dimensions. I suppose we could do a new bug on handling ratios, but that's really what SVG needs.
Not sure what you mean by "but that's really what SVG needs". I've no preference on opening a new bug or using this one to finish the remaining work.
SVG needs an implementation of the algorithm that works with intrinsic ratios, since you can have an <svg> with percent width/height.
So I've been spending some time reading through sections 9 and 10 of the CSS 2.1 WD to try and get a better handle on this CSS thing. :-) I'm not at all clear how an <svg> with percentage values for width and height specifies an intrinsic ratio. The spec seems to allow for percentage as well as absolute intrinsic widths/heights when it says: 10.3.2 http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width Percentage intrinsic widths are first evaluated with respect to the containing block's width, if that width doesn't itself depend on the replaced element's width. If it does, then a percentage intrinsic width on that element can't be resolved and the element is assumed to have no intrinsic width. Similar for height in section 10.6.2. That seems to me to be a sensible way to handle the case. It also seems to allow for the case where one of intrinsic width/height is a percentage and the other is an absolute value, whereas if percentages are only supposed to establish an intrinsic ratio I don't see how that case would work.
Oh, sure. There's that stuff too (and we also don't handle it right now). Doesn't the SVG spec talk about what attributes of <svg> provide what for CSS? I seem to recall the viewbox mattering, no? That is, consider the following markup: <div style="width: 100px"> <svg width="50%" height="40%" viewbox="...."> The width should end up 50px. What about the height? The CSS spec says there's no intrinsic height in this case (as far as the percentage is concerned).
This bug was just fixed by the fix for bug 294086. Most of the reftests checked in for that bug cover this bug too.