If an image is absolutely positioned and has a height of 100%, it should scale to the height of its parent element. Instead, the viewport seems to be used as the basis for height calculation. This worked correctly in Safari 2.
Probably regressed in <http://trac.webkit.org/projects/webkit/changeset/14351>.
Created attachment 15406 [details] Evaluate percentage heights of positioned replaced elements with respect to their container's height Restores the behavior prior to the regression. In the block container case (first case in the layout test), Firefox and Opera agree with this behavior. In the inline container case, there is not always agreement between those two (depending on the other contents of the inline) and with WebKit, but they never compute the percentage out of the fixed-size container (which is the bug in WebKit TOT).
Created attachment 15407 [details] Evaluate percentage heights of positioned replaced elements with respect to their container's height
What does the CSS spec say about this? Are absolute positioned replaced elements supposed to be sized relative to the containing block or relative to the parent?
Comment on attachment 15407 [details] Evaluate percentage heights of positioned replaced elements with respect to their container's height Can't you just use the current block container height?
<rdar://problem/5316321>
(In reply to comment #4) > What does the CSS spec say about this? Are absolute positioned replaced > elements supposed to be sized relative to the containing block or relative to > the parent? I'd like to point out that this patch isn't about replacing "relative to the containing block" with "relative to the parent": in the first case in the layout test, the "container" div is both the parent and the containing block (and in fact both container() and containingBlock() return it). The thing is that the current code skips over containing blocks with 'height: auto', since in the case of a non-positioned child, the child's height affects the parent's height so you can't define the former in terms of the latter. However, positioned elements don't affect their ancestor's height, which is known (and 'final') by the time they are laid out. Anyway, the spec says: "Percentage intrinsic heights are evaluated with respect to the containing block's height, if that height is specified explicitly, or if the replaced element is absolutely positioned". Admittedly, I don't know what a "percentage intrinsic height" is in that (or any) context, but there is no other reference to percentage heights in <http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-height> (which is referenced from 10.6.5), so either that's the spec or the case is unspecified in which case matching Firefox seems like a good idea anyway. (In reply to comment #5) > (From update of attachment 15407 [details] [edit]) > Can't you just use the current block container height? Sorry, that was too vague for me. I'm not sure what you're suggesting. In the relative inline case I think it makes more sense to use the inline's height.
It's probably best for Hyatt to look at this closely. I think "intrinsic percentage height" is meant to cover the case of an SVG image, where the intrinsic dimensions may actually be percentages. Matching Firefox sounds good to me but maybe hyatt has more comment.s
Actually, I think this case is simply specified earlier, in <http://www.w3.org/TR/CSS21/visudet.html#the-height-property>: "The percentage is calculated with respect to the height of the generated box's containing block. If the height of the containing block is not specified explicitly (i.e., it depends on content height), and this element is not absolutely positioned, the value computes to 'auto'." So while it's true that in this case the height of the CB Is not specified explicitly, since the element *is* absolutely positioned, you should still compute the percentage relative to the CB.
Comment on attachment 15407 [details] Evaluate percentage heights of positioned replaced elements with respect to their container's height r=me
Landed in r24163.