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

Re: timing, I'm completely ambivalent about timing. I think it's perfectly fine for the visibility to lag by a frame; it sits in the same "chunky visual update" bucket as position-try does, where it's fine for the abspos to linger for a frame after the anchor has scrolled off, or pop in a frame after the anchor has become visible.

Whatever timing works best for implementers, I'm fine going with. If that's on IO timing, or on RO timing, or *anything else*, whatevs.

------

Re: what sort of clipping, I'm mildly of the opinion that we want to match IO's clipping, as @chrishtr says. That was my intention when writing the current text, I just didn't explicitly write the connection in. This makes these two *very similar* concepts across the platform match, which is usually a good thing if there's no strong argument otherwise. Given that IO is the tool we give to authors to do *this exact thing* themselves, if we think we need a more (or less!) powerful concept for anchorpos, we probably want to offer that same option in IO.

So I support *explicitly* making the connection with IO's clipping behavior.

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


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

Received on Monday, 13 October 2025 20:28:34 UTC