Jeremias Maerki a écrit : > On 21.03.2007 21:22:04 Andreas L Delmelle wrote: >> 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. > > That's the picture I work with. Only for paged media you don't scroll > and the viewport is the page.
Well, that's still unclear. The area should be placed like in the "absolute" model, plus mustn't move WRT the viewport. In case of a continuous media, what should happen if the nearest ancestor ref-area doesn't appear yet in the viewport at the beginning of the viewing, but only after having scrolled a bit? Should the fixed area suddenly appear? Where? When the ref-area is scrolled away, should the fixed area suddenly disappear? Remain in the viewport? 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". Combined with the sentence "The area generated is a descendant of the page-area where the first area from the object would have been placed had the object had absolute-position="auto" specified", that would make the scheme absolutely clear I think. >>>> 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? > > Yes, definitely. If you look at the area tree XML, you'll see exactly > that. Only the renderer handles the positioning differently based of the > trait. Taking the b-c out of the normal flow only means in terms of bpd > cursor advancement. > >> If so, then percentages refer to the dimensions of the outer b-c's area. > > Yessss Re-reading the definition of "left" once again, it seems we may go with that. >> 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... > > Something like that. Not in the case of absolutely-placed areas I think, as they are removed from the flow and have no impact on the layout of normal areas. If the ipd of the nearest ancestor ref-area is auto, then we would just have to wait that it becomes known (based on the layout constraints of other normal areas) before placing the absolute area. <snip/> Vincent
