Re: [csswg-drafts] [css-anchor-position-1] position-visibility: anchors-visible should be clear about when is visibility determined (#12732)

TL;DR:  I propose that we resolve no change to the existing WD spec, which already specifies overflow clips up to the abspos CB, and also the timing of visibility checks. I think this already agrees with implementation behavior for both Chrome and Safari.

> What types of clipping should position-visibility be checking for?

I agree that overflow clips between the anchor element and the abspos CB should be taken into account, but not the viewport. The reason is that, if the anchored element looks to the user like it's part of a subscroller, then it doesn't make sense to the user what it's anchoring to if that anchor point is not even visible on the screen.

Example [here](https://codepen.io/una/pen/ogbxmQj/6647de7b869f7ba3ff661879f2739c0d) (observe what happens when you scroll further up or down in that scroller which has a tooltip for "Item 6"). (Note: this demo is from @una who is close to the developer community.)

The browser viewport doesn't have this problem because its clip always applies to everything--including anchored elements--and so there is no point to doing it there because it will have no effect. But for a subscroller, the anchored element escapes the clip of the subscroller because it's out of flow.

I also don't think other clips need to be taken into account, because it's just a scrolling effect due to the user agent controlling scrolling, not any other visual effect.

> When should it be calculated? 

I agree that visibility should be re-evaluated after every layout (*) so that there is no lagging across frames.

From what @fantasai said, I think the WebKit and Blink implementations actually already match.

Blink does position-visibility hiding computation updates [after layout and before JS ResizeObservers](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/local_frame_view.cc;l=2350;drc=e7c21c2a4b1c1b81de83b6a4a12375c055ae6e8a) (but it is also part of the loop between them, so if a ResizeObserver dirties layout then visibility will be re-calculated after the subsequent  layout).

Implementation note: The intersection observation generated for `position-visibility` by Blink is also delivered during that same frame. We do this with a special kind of Blink-internal sync observation not available to JS-generated IntersectionObservers.

(*) Or more more precisely, every layout that is part of the update-the-rendering/animation frame generation steps.

-- 
GitHub Notification of comment by chrishtr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12732#issuecomment-3348934620 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 29 September 2025 20:28:44 UTC