On May 11, 2007, at 2:51 AM, Mike Wilson wrote: > 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".
But the % offset for 'top' cannot be computed in your case, as it depends on the height of the containing block, which is _basically_ unknown (it is 'auto'). > > 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". I agree that the spec is a little under-defined in this case. Maybe you should take this up with the CSS WG? They might still include a clarification [1]. ref you point 2 above. I don't think the browser makers have made 'an educated guess' :-). For 'left' or 'right' offset, it is based ultimately on the shrink-to- fit algorithm for width, something that is defined [2]. For 'top' (and 'bottom'), height has no shrink-to-fit possibilities, and hence your top: 50% computes to '0'. [1] you can take it up via the mailing list <http://lists.w3.org/Archives/Public/www-style/> [2] see towards the end of 10.3.7 <http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width> Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ______________________________________________________________________ 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/
