Thanks for your insights Philippe!
> > Or are you saying that the height of the containing block used for
> > positioning will be different from the calculated size of the actual
> > element? This doesn't seem to be the case as the other, absolutely
> > pos'd, child DIV finds bottom:0 nicely.
>
> Yes. The height of the parent div (containing block in this case) is
> 'auto'.
> 'height' refers to a declared value.
> The computed size is a different matter in this case (actual,
> calculated height).
> The other child div behaves differently because it is _absolute_
> positioned. Because for absolute positioned elements height can
> always be resolved.
> Percentage values for height and by extension offset ('top') are a
> complicated matter. Basically, only absolute positioned element know
> their 'height' based on the intrinsic values (computed).
> 10.5 states this quite clearly
> <http://www.w3.org/TR/CSS21/visudet.html#the-height-property>
Ok, looking at 10.5 (and 10.2) I find that when we have
parent.height = auto
parent.width = auto
relativechild.height = nn%
relativechild.width = nn%
then the CSS rules say that the child height should be reset to auto:
relativechild.height = auto
and the child width is undefined:
relativechild.width = <undefined>
I can clearly understand why, as a layout calculation would otherwise
easily lead to an endless recursion in the UA.
But extending this reasoning to the offset properties, like left and
top, seems unfair as they cannot cause any layout recursion. The child
height and width may cause recursion as the parent element may base its
own size on the child size, but the parent element will never base its
own size on a child's offset.
The specification is very clearly written for height percentages (10.5):
"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'."
but I lack the corresponding text for top percentages (9.3.2) which
are only specified as "refer to height of containing block".
So, could you comment if my reasoning below is plausible? :
1) The spec doesn't mention special handling of percentage offsets when
the parent's size is dependent on child size.
2) Standard browser makers have made an educated guess that the spec's
reasoning behind height/width should be extended to the offset
properties (which is not implied by the spec).
3) When I set a top percentage the standard browser resets top to auto
which is why I see no "upwards shift".
4) When I set a left percentage the standard browser is free to do what
it prefers as this is undefined and, as they probably reason the
way I do above, can calculate the correct widths without risk of
recursion and then use a percentage based on that, which is why I do
see a "left shift".
> And if you use any other unit of measure (px, em, ex, ...) the
> relative positioned element will move upwards, because that doesn't
> depend on the height of the parent element.
Yes, I have noticed this also. Too bad it is 50% of an unknown height
I need ;-).
Best regards
Mike
______________________________________________________________________
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7 information -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
