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

The CSS Working Group just discussed `[css-anchor-position-1] position-visibility: anchors-visible should be clear about when is visibility determined`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> emilio: the spec doesn't say when the anchor's visibility is checked<br>
&lt;TabAtkins> emilio: and when I was looking to implement, I realized the spec technically allows....<br>
&lt;TabAtkins> emilio: if it did something more complicated you could only do it as post layout<br>
&lt;TabAtkins> emilio: but the clipping thing specified is at layout time<br>
&lt;TabAtkins> emilio: the issue is about defining *when*<br>
&lt;TabAtkins> emilio: webkit does it during layout. blink does some intersection observer thing, which is a bit more flexible<br>
&lt;TabAtkins> emilio: but might be more confusing<br>
&lt;TabAtkins> emilio: if you change layout in a way that overflows, then elementFromPoint(), whether that hit test succeeds or not depends on timing<br>
&lt;TabAtkins> emilio: no strong opinion on what happens, just want it specified<br>
&lt;TabAtkins> emilio: I think Tab added an edit<br>
&lt;TabAtkins> emilio: should check with WebKit. and spec edit should use some of the post-layout things Rune is doing.<br>
&lt;futhark> q+<br>
&lt;TabAtkins> TabAtkins: I specified "just before ResizeObserver", because that's what Philip said and Emilio agreed. More details would be great.<br>
&lt;TabAtkins> emilio: it needs to be a bit more detailed, because ResizeObserver loop is more stuff - content-visibility, scroll size observer... it needs to be specced in amore detailed way. rune can give details<br>
&lt;astearns> ack futhark<br>
&lt;TabAtkins> futhark: sorry, don't have specific context on position-visibliity, but it does make sense to happen at same time<br>
&lt;TabAtkins> futhark: also on whether rpost-layout snapshot happens before or after resizeobserver<br>
&lt;TabAtkins> futhark: ties in, I agree<br>
&lt;TabAtkins> fantasai: I pinged antii to see if he has feedback. I have no idea how this timing fits in with anything<br>
&lt;fantasai> s/antii/antti/<br>
&lt;TabAtkins> fantasai: I just want authors to have something that generally works. not sure to what extent we care about exact nuances beyond that<br>
&lt;emilio> q+<br>
&lt;TabAtkins> fantasai: so how much of this is about authors caring about timing, and how much is about writing WPTs<br>
&lt;TabAtkins> fantasai: so long as the author-observable behavior is something they're happy about, and we have interop on aspects that we need *for authors*<br>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> emilio: not about locking things down. timing issue ends up... if we dont' define it, we'll hit compat issues.<br>
&lt;TabAtkins> emilio: it's pretty different observable behavior. if you do it before resize, then layout changes from an RO won't hide an anchor until next frame<br>
&lt;TabAtkins> emilio: on flip side, if you do it during layout, that's most CSS-y it's not really observable, but it's less flexible. can't check for intersection with other elements.<br>
&lt;TabAtkins> emilio: i'm assuming blink is actually reusing Intersection observer, which does a lot more than just checking scroll overflow<br>
&lt;TabAtkins> emilio: that's a big behavior different, should use one or the other<br>
&lt;TabAtkins> emilio: IO uses overflow-clip, o-c-margin, etc<br>
&lt;TabAtkins> emilio: and those are probably something the author would expect to work<br>
&lt;TabAtkins> fantasai: yeah, defining whether we check clip is definitely defined<br>
&lt;TabAtkins> TabAtkins: I think that's already defined<br>
&lt;fantasai> TabAtkins: We should define behavior we want<br>
&lt;TabAtkins> emilio: right now I think spec is just overflow based<br>
&lt;TabAtkins> astearns: so how to resolve on this?<br>
&lt;TabAtkins> emilio: if we want to check IO things, we need to define a fixed point in the frame timing<br>
&lt;TabAtkins> fantasai: I think we should just be checking for what's in the spec right now<br>
&lt;TabAtkins> fantasai: if we did clip path and other stuff.... I don't think tha't snecessarily what authors would expect<br>
&lt;TabAtkins> emilio: if you did this as an author you'd do IO<br>
&lt;TabAtkins> fantasai: sure but i'm not convinced it's really what you *want*<br>
&lt;TabAtkins> fantasai: so we have some qs to investigate. what do we think authors expect about clip behavior and anchor visibility? and the timing question<br>
&lt;TabAtkins> fantasai: which depends on that first q<br>
&lt;TabAtkins> emilio: I think that makes sense<br>
&lt;fantasai> s/first q/first question, so let's answer that one first/<br>
&lt;TabAtkins> emilio: I think spec currently only does check from the anchor to the CB of the positioned El, and that's another big change from IO<br>
&lt;TabAtkins> fantasai: right, I think IO isn't what we want to do<br>
&lt;TabAtkins> emilio: maybe. I think it's weird, for example, to not intersect with the viewport.<br>
&lt;TabAtkins> astearns: take back to the issue, then?<br>
&lt;TabAtkins> fantasai: yes<br>
</details>


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


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

Received on Wednesday, 24 September 2025 16:41:49 UTC