- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 15 Oct 2025 15:44:49 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position-1] position-visibility: anchors-visible should be clear about when is visibility determined`, and agreed to the following: * `RESOLVED: match IntersectionObserver behaviour, meaning that clip-path is taken into account` * `RESOLVED: browsers must use the content visibility timing, but may also update at other times` <details><summary>The full IRC log of that discussion</summary> <JoshT> TabAtkins: there's a few issues in this<br> <JoshT> ... what kind of clipping should position-visibliity be checking for<br> <emilio> q+<br> <JoshT> ... the current spec repeats explicit things about overflow. we want to match what intersectionobserver observes<br> <JoshT> ... my preferred resolution is that we match intersectionobserver. have different parts of the platform work consistently<br> <JoshT> ... if we want to do something new, intersectionobserver should do it too<br> <astearns> ack emilio<br> <JoshT> emilio: you mentioned occlusion and then intersection which are different<br> <JoshT> ... I agree that seems the right thing to do, but that restricts the credible solutions for the timing of things<br> <JoshT> ... ideally, we also want to run this magic intersectionobserver at the same time as other magic IO for content visibility<br> <JoshT> ... +1, but doing this also resolves the timing issue<br> <ydaniv> q+<br> <JoshT> TabAtkins: I am happy with that, do not care when it happens<br> <JoshT> ... I'm OK if it lags and persists for one frame<br> <JoshT> ... matching content-visiblility makes sense to me<br> <astearns> ack ydaniv<br> <JoshT> ydaniv: because it's a layout feature, some things layout related might be worth considering something closer to view-timeline<br> <JoshT> ... so it ignores transforms, for exampl<br> <JoshT> ... not a strong concern, but might be worth considering<br> <emilio> q+<br> <JoshT> ... to not affect other things you want interactions between<br> <emilio> q-<br> <JoshT> TabAtkins: anything we add here we'd want to add to IO as well, I think<br> <emilio> +1 to TabAtkins is saying, this seems like something that IntersectionObserver could want as an option<br> <JoshT> ... so if we do any calc here, we should do it on IO. authors might want to do this on their own<br> <astearns> ack fantasai<br> <JoshT> fantasai: webkit's implementation is more responsive than doing it at IO time<br> <JoshT> ... we simplified some geometrical calcs<br> <ydaniv> q+<br> <JoshT> ... so from authors perspective, do they expect clip-path to be considered or ignored<br> <JoshT> ... I don't mind syncing with IO<br> <JoshT> ... or we could copy the default behavuour of what IO does<br> <JoshT> ... are we considering clip-path?<br> <JoshT> ... keep in mind masking will not have an effect<br> <JoshT> ... do we want clip-path and masking handled the same way<br> <JoshT> TabAtkins: it's handled differently for a reason. masking is a bitmap<br> <JoshT> ... defininitely for intersection observer<br> <emilio> q+<br> <JoshT> fantasai: but what do authors expect?<br> <JoshT> TabAtkins: sure. spec intended to match IO and if it doesn't, that is a failure on my part<br> <JoshT> ... we should either use IO semantics or improve IO<br> <astearns> ack ydaniv<br> <TabAtkins> my point is just, we *do not* need to talk about improvement to IO in *this* issue.<br> <JoshT> ydaniv: as an author, I'd like it if clip-path would work, but masking not bothered<br> <JoshT> emilio: it would be surprising to me if clip path behaved differently to clip overflow<br> <astearns> ack emilio<br> <JoshT> ... if we want to change IO to not account for clip-path, that seems fine<br> <JoshT> ... everyone seems to agree syncing with IO, so maybe we could resolve on that.<br> <JoshT> ... I think current behaviour is fine, but if we want something else, I think that's OK but we should discuss separately<br> <JoshT> astearns: we could tie this to IO which does take clip behaviour into account, but we could have a switch to disregard clip-path<br> <JoshT> fantasai: I don't think we want a difference in behaviour<br> <ydaniv> +1 to emilio, considering overflow and clip-path the same<br> <JoshT> ... they should be able to do the same thing so the author could mimic this behaviour with IO<br> <JoshT> ... the downside of including clip-path is you'll be less responsive to changes. you can't cache info about clip-path<br> <JoshT> ... at the point you scroll to the clipped item, you have to recalc<br> <JoshT> astearns: I assume other impl are OK with not matching clip-path<br> <astearns> s/not matching clip-path/taking clip-path into account<br> <JoshT> emilio: seems to me that optimisation webkit has would be good for IO as well. you could do it if there's no clip-path<br> <JoshT> ... but using clip-path is probably the right call<br> <fantasai> s/at the point you scroll to the clipped item, you have to recalc/if you check clip-path, you have to do a full recalc on every scroll change/<br> <JoshT> ... it's the only tool for authors to implement it on their own, but also makes this quicker to implement<br> <JoshT> ... anything else we want to do, we should improve IO<br> <JoshT> astearns: would webkit be OK with tying things to IO behaviour with the option to improve it in future?<br> <JoshT> fantasai: I'd want to still know what is better for authors<br> <JoshT> ... but I'd want to take that as a separate resolution<br> <JoshT> emilio: seems everyone is fine with IO behaviour<br> <JoshT> ... the spec should probably point to the IO spec, for the alogrithm and whatnot<br> <fantasai> s/to still know what/to handle clip-path in whichever way/<br> <JoshT> PROPOSED: match intersection observer behaviour, meaning that clip-path is taken into account<br> <JoshT> RESOLVED: match IntersectionObserver behaviour, meaning that clip-path is taken into account<br> <JoshT> fantasai: it's fine to say we only do timing per frame on baseline, but we would prefer if implementations could be more responsive than that<br> <emilio> q+<br> <JoshT> TabAtkins: I think that's acceptable. spec it must at least match content-visibility but could be more responsive than that<br> <astearns> ack emilio<br> <JoshT> emilio: I have a strong preference for not allowing this and speccing when it happens<br> <JoshT> ... right now it's fine because it's barely observable. but we're discussing making it more observable by chaining values and things<br> <JoshT> ... I feel with the implications, the right thing is to specify the content-visibility thing, but won't object if fantasai wants more responsiveness<br> <JoshT> ... these things tend to cause subtle incompat issues<br> <JoshT> ... could also argue authors will use intersection observer for this<br> <astearns> q+<br> <JoshT> fantasai: if authors mimic this behaviour and get worse behaviour, that's expected<br> <JoshT> ... authors always get better stuff with just using CSS<br> <JoshT> emilio: I won't object, but I think it's not amazing. you'll need to impl clip-path with this special case and hooking it up to the IO code will simplify that<br> <astearns> ack astearns<br> <JoshT> ... i prefer not allowing it<br> <JoshT> astearns: I kind of agree with emilio. better from a spec perspective to nail it down so there isn't a difference in browsers<br> <JoshT> ... but it might not matter<br> <JoshT> ... would it be possible to spec when this timing optimisation could take place. it would be a MUST, not a MAY<br> <JoshT> fantasai: I don't think that would solve emilio's point<br> <TabAtkins> i think elika's reading on our take is also correct<br> <JoshT> astearns: my understandinf was trying to have a difference in timing between browsers is something we want to avoid<br> <castastrophe> q+<br> <JoshT> fantasai: problem if impl fire at a different time to IO time<br> <JoshT> ... but if you respond faster than other browsers, I don't think that would be a problem<br> <JoshT> emilio: so we could say either fire at the ???? or after every style or layout update<br> <JoshT> s/????/content visibility determination timing/<br> <JoshT> ... I think that's what webkit does<br> <JoshT> fantasai: I think that would be fine, but i don't see why we can't just say 'do it at this time and you can be more responsive'<br> <astearns> ack castastrophe<br> <JoshT> castastrophe: as an author, as long as it's something we can hook into consistently between browsers, I don't mind if it's faster<br> <JoshT> ... if I have something that fires after that, i need to be consistent<br> <JoshT> ... but in other situations we see that too. as an author, I wouldn't object<br> <JoshT> astearns: so we can spec that browsers must use the content visibility timing, but may also update at other times<br> <JoshT> emilio: would be good to confirm that that's the timing futhark has in mind<br> <JoshT> futhark: that's a current idea<br> <JoshT> emilio: should be consistent with other features like scroll-timelines, etc<br> <JoshT> futhark: I agree<br> <JoshT> RESOLVED: browsers must use the content visibility timing, but may also update at other times<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-3407111428 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 October 2025 15:44:50 UTC