Thanks again for your input and for helping me understand this! > > 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. > > 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').
The algorithm for calculating the actual height (when set to 'auto') is described in: 10.6.7 'Auto' heights for block formatting context roots. where I find the following description: "If it has block-level children, the height is the distance between the top margin-edge of the topmost block-level child box and the bottom margin-edge of the bottommost block-level child box. Absolutely positioned children are ignored, and relatively positioned boxes are considered without their offset." Reading this, especially the phrasing "considered without their offsets", leads me to think that the rendering is thought to take place in two phases something like this: 1) Calculate sizes and lay out elements in normal flow 2) Lay out pos:absolute children and shift pos:relative children to their final destination. If this maps well to what implementations can do, then there wouldn't be a problem using a percentage in (2) as the actual height was calculated in (1). Please get me right, I sense that you have a very deep understanding of the mechanisms at work here and I primarily want to have a deeper understanding myself. At my current level I still cannot deduce from the spec why top offset needs to be handled with the same limitations as height. Maybe there are things I need to know about how UAs normally go about rendering a page? (I'm sure there is something solid that forces this, as all standard browsers do this, but I still fail to see it.) > 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]. I'm actually already a subscriber of this list so I'll try and do that (though, not being a "regular" on the list I expect to be ignored as seems to be the custom for w3c mailing lists ;-). > For 'left' or 'right' offset, it is based ultimately on the > shrink-to-fit algorithm for width > For 'top' (and 'bottom'), height has no shrink-to-fit possibilities, > and hence your top: 50% computes to '0'. For a casual reader like myself, the shrink-to-fit algo doesn't appear conceptually different from the "auto height" algo in 10.6.7 I mention above. I would expect these two to create symmetry between how width and height are handled, albeit with somewhat different rules as the page flow goes up to down, block elements fill to available width but not height, etc. > [2] see towards the end of 10.3.7 > <http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width> Yes, and the corresponding behaviour for height is described in 10.6.4 and our case applies to rule number (3), which makes the reference to 10.6.7. 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/
