Hi Paul, So you wanna join the game? ;-)
Paul Vinkenoog a écrit : <snip/> > The (1.1) spec says that if the positioning is... > > - absolute: > the positions are taken with respect to the nearest ancestor > reference area; > > - fixed: > the positions are taken with respect to the page viewport (for paged > media, like PDF) or the document viewport (for continuous media). > > But then 7.3, "Reference Rectangle for Percentage Computations", seems > a bit confusing, at least for fixed positioning: > > "When the absolute-position is "fixed", the containing block is > defined by the nearest ancestor viewport area." Thanks for pointing this out. Indeed this seems to add to the confusion :-\ > Normally you would assume that if you define a position wrt a certain > area (i.c. the page viewport), percentages are also interpreted wrt to > width and height of that same area. The added remark to the "left" property (7.6.5) states that it should be "interpreted in the prevailing coordinate system (established by the nearest ancestor reference area)". But section 7.3 says that "the containing block is defined by the nearest ancestor viewport area", which is always the same excepted for table-cells. What's not clear is if the references for the /offset/ and for the /length/ should be the same or not. The ambiguity could be resolved by considering that the added remark in 7.6.5 applies only to the offset, and that the statements in 7.3 to the computation of percentages. > Then again, thinking about what is an "ancestor area": the way I see > it, absolute and fixed positioning make an area break out of its FO > ancestry. That is, if fo:block-container A is a direct child of > fo:block-container B, but A's positioning is "fixed", the *area* > generated by A is not a direct child of the area generated by B, but > of the page-viewport area. Sure, but my understanding is that the ancestor area should be determined /before/ taking the object out of the flow. So the position of A should be computed WRT B, and only then A would be made a child of the nearest page-viewport area. IMO this notion of "out of the flow" has an importance only for the following siblings, whose positions are computed without taking A into account. > This in turn means that A's "nearest ancestor viewport area" is the > page viewport (or document viewport), and the apparent inconsistency > vanishes. > > Granted, it's an interpretation, but it seems the most logical one to > me. > > For visibility, this means: > > - On a continuous medium, a fixed-positioned area is > 1) always visible if it lies completely within the document viewport > 2) never visible if it's completely outside the viewport > 3) clipped if it lies partly within the viewport > All this independent of the scroll position of the document. > > - On a paged medium, the same applies, but now with respect to the > page. So again, the fixed area may be visible, invisible or partly > visible *on the page*, depending on size and offsets. > Of course the area may be "out of sight" even if it's (partly or > fully) visible, because you may scroll away from (that part of) the > page, or turn pages in a book. But that doesn't affect the principal > visibility. Scrolling through a PDF document has nothing to do with > viewport/reference pairs *within* the document's area tree. > > - With absolutely-positioned areas, the visibility may change over > time even if the entire page (or document) is always fully visible, > because one or more of their ancestor reference-areas may be > scrollable within their associated viewport. This all makes sense. > All this seems pretty logical and consistent to me, and (AFAIK) within > the specification. > > So I hope I'm not just adding to the confusion here... :-) You do, but still thanks for chiming in ;-) That enforces my willing to ask for clarification to [EMAIL PROTECTED] Cheers, Vincent
