On Tue, 25 Jul 2006, James Bursa wrote:
> Ok. Can you also take a look at calculating of the static
position of a
> box? - our current scheme of "guessing" 0 isn't entirely satisfactory
Any ideas on the best way to implement this? (static position is defined
I guess we could put absolutely positioned boxes in their normal flow
position in the tree, as well as in the absolute_children list (similar to
floats). Then for blocks and tables, layout_box_context() could
essentially treat them as a 0-height block and give them a static position
which later absolute positioning could use. That wouldn't work for
absolutely positioned inlines - currently they get converted to blocks as
the spec requires, so they can't be in an inline container.
Maybe we need a BOX_ABSOLUTE after all.
I think that this may be the best solution. An alternative might be for
absolute boxes to have some knowledge of their parent/previous sibling box
and use that to calculate the static position. That doesn't strike me as a
particularly satisfactory solution, though.
> This is one of the two outstanding issues that I'm currently
aware of (it
> affects a number of sites - Slashdot, Google Groups and Zen Garden); the
> other is that our plot order is wrong, so the wrong bit of content ends up
> on top (obviously, there's still z-index to implement).
I think this also requires that the original order of boxes is not thrown
Indeed, which would suggest (to me, at least) that a BOX_ABSOLUTE-style
solution may be the best option as it would allow the retention of the
document order of boxes.