On Mar 23, 2007, at 11:22, Vincent Hennebert wrote:
Thanks for your perseverance ;-)
You're welcome. :o)
<snip />
If the nearest ancestor ref-area is not immediately visible, then I
think this implies that the fixed-area's position is definitely not
relative to the viewport you refer to, but to another nested
viewport.
Then which one? If there is no block-container in the flow, then the
only viewport area is the region-body. And my question remains...
OK, take the region-body as an example, with overflowing content and
a fixed-positioned block-container that is a descendant of a block
that initially falls outside the region-viewport, and thus is not
immediately visible. Same as an absolute-positioned block-container,
it will appear at a certain position in the region-viewport-area
(regardless of where it was specified, or whether the containing
block is visible or not).
For our current output-targets, the story ends here, because there is
no scrolling. Note that an absolute-positioned block-container will
always appear, even if the containing block ends up on a part that is
clipped (never visible).
OTOH, if the fixed-positioned block-container is enclosed by a
regular one, then its initial visibility depends on the initial
visibility of the regular block-container, precisely because the
regular block-container establishes a new viewport/reference-area
pair. The fixed-positioned one will appear as a static part in that
new viewport once it becomes visible.
<snip />
As the idea is probably to mimic the "absolute" and "fixed" value
for
"position" in CSS2, I think the description of "fixed" should not
refer
to the one of "absolute" for placing areas. They should have written
something like "These properties specify offsets with respect to the
page's viewport area".
The term "page" seems too narrow here. Your suggestion would only
cover
the case of absolute- or fixed-positioned areas whose nearest
ancestor
ref-area is the page-area.
No, what I was saying is that the position would be computed WRT to
the
ancestor page-area (more precisely, the region-reference-area) instead
of the nearest ancestor ref-area, whatever it is.
Why? I think that would actually make it more difficult than it is
now, since a nested block-container would then also need to get at
the containing page, whereas now it is enough to stop at the first
block-container that establishes the reference area.
Cheers,
Andreas
