On Mar 21, 2007, at 10:42, Vincent Hennebert wrote:
Whatever follows in that second definition is irrelevant wrt
determining the base for percentage values to compute the initial
offset (or IOW: determining which is the nearest ancestor
Indeed, you're right. In fact we don't have to care about the "fixed"
value for absolute-position, because it doesn't apply to most of our
renderers (which belong to the paged media category). The only
which would be concerned is the AWT previewer, but that's another
(Re-reading the definition of "fixed" it actually doesn't make any
to me. The position is computed WRT the nearest ancestor ref-area, but
then it shouldn't move WRT the viewport. What if the ref-area appears
only when we start scrolling? Should the fixed area already be
suddenly appear, or whatever? grrr)
Well, it's only by forcing the issue that I begin to understand what
"fixed" refers to exactly. Until recently, I only /wondered/ what the
distinction was made for...
It makes more sense if you combine it with the definition of the
overflow property, I think. Some renderers could provide a scrolling
mechanism in case of overflow. A fixed-positioned block container
would in that case have a fixed place in the viewport, and the
content would scroll away underneath.
Leaves my original question:
What I'm still not sure about is:
"Absolutely positioned areas are taken out of the normal flow."
Does that mean that percentages on any block-container with
position="absolute" should always be based on the containing page?
... and I agree with you that if they are specified as percentages
that's unclear whether the percentage refers to the ref-area or the
containing block :-\
I thought I had the answer yesterday, but now I'm beginning to doubt
The additional restriction imposed by the XSL Rec. (7.6.1 - "absolute-
position") says "descendant", which I too eagerly read as "child". It
all boils down to the question: in the case of nested block-
containers, is the area corresponding to the outer b-c the nearest
ancestor reference area to the area corresponding to the inner b-c?
If so, then percentages refer to the dimensions of the outer b-c's area.
As Manuel indicated, if these dimensions are unspecified or
explicitly set to "auto", then the percentage would resolve to zero
because of the circular dependency: the resolved value of the
percentage would be needed to determine the base value...
Seems my proposed fix (bugzilla 41894) goes in the right direction.
Only it does not take reference-orientation and/or writing-mode into
account when mapping width/height to ipd/bpd... but that seems to me
currently a part of a larger problem. At certain places in the code,
nothing but ipd/bpd is used. Then at other places, we get explicit
references to width/height. I'm thinking of moving this logic to the
fo tree/property side. The layoutengine should work entirely with ipd
and bpd, if only to give the /impression/ of consistency... ;-)