Hi Andreas,

Andreas L Delmelle a écrit :
> On Mar 23, 2007, at 11:22, Vincent Hennebert wrote:
> 
>> Thanks for your perseverance ;-)
> 
> You're welcome. :o)

I'm sure we will manage!


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

If I understand you correctly, what you're saying is that if the fixed
positioned block's nearest ref-area is not initially visible, then the
top/left/etc. properties should be taken WRT the region-viewport-area?
I would really not agree with that. Besides the fact that that would
complicate the implementation, I think that if the fixed area turns out
to not be visible, then it will never be. Anyway if you give arbitrarily
great values to top/left/etc. you /will/ get an area that lies outside
the viewport-area, regardless of the value of the overflow property.


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

Now I'm starting to see what you mean. While it makes perfectly sense to
me, I'm almost sure this wasn't the intent of the authors when they
wrote the description of "fixed". Moreover there would then be little
difference with "absolute".


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

Well, yes. Although I'm not sure which one would actually be more
complicated to implement. Also, the following sentence in the
description of "fixed": "In the case of paged media, the area is fixed
with respect to the page" seems to go in that direction.

Cheers,
Vincent

Reply via email to