On Mar 21, 2007, at 10:42, Vincent Hennebert wrote:

<snip />
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 reference area)

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 renderer which would be concerned is the AWT previewer, but that's another question.

(Re-reading the definition of "fixed" it actually doesn't make any sense
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 there, or
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 again... :S

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... ;-)



Reply via email to