oddbird/css-anchor-positioning

Update when anchor moves

jh3y opened this issue ยท 6 comments

jh3y commented

From what I can tell, the current implementation is responding to container resize/scroll. But, the browser implementation will also let update anchor positioning when the anchor moves within the container. That movement could be triggered in various ways.

See this demo: https://codepen.io/jh3y/pen/BaPwEMz/bb7b743f7935ca5e415629be01556d3a

Dragging the anchor will keep the boat tethered currently where anchoring is supported.

In this demo, the anchor position is dictated by a grid layout: https://codepen.io/jh3y/pen/xxzayVJ

Changing the grid layout works with the API but isn't detected in the polyfill.

There's also another scenario where the anchor could be updated via a dynamic custom property where the change isn't detected or picked up (That may be worth another issue. This demo shows it in action: https://codepen.io/jh3y/pen/LYrxpjB).

Understandably some of these scenarios might be tricky to monitor. Especially in a performant way. Is there perhaps a trade-off to say "This covers the main cases"? Interested to hear your thoughts.

Yes, I think you're absolutely correct. Right now the polyfill is using floating-ui to detect changes, but only because it was an easy first iteration. For each of the various use-cases you mention, if we can come up with a consistent (and performant) way to detect that a change has happened, it would be relatively easy to tell the polyfill to re-calculate. (I'll note that we've been focusing on basic support, and haven't done significant performance testing of the polyfill yet.)

Contributions welcome! ๐Ÿ˜„

animationFrame: true solves it, and we discussed an async technique here but it seems to be worse for performance.

I don't know if there's any other kind of observer to use to detect rect changes without a rAF loop. Would work if there was a RectObserver or something for the platform?

jh3y commented

Yeah, I can imagine it being worse for performance and it's hard to set detection on a case-by-case basis I imagine. By that I mean, whether to turn on RaF or not based on what's present ๐Ÿค”

A MutationObserver on the anchors might help a little if it's class/style changes. But, imagine floating-ui have some way already in place if the anchor changes shape, etc.? I'd need to go look through their docs again.

I guess we could observe somehow if the anchor property value changes and look up the chain if there is one somehow. But, that's also going to require hooking into different events which may or may not be happening ๐Ÿค”

@jh3y I think at least most of your examples should be fixed by using the new option exposed in #87?

It may be possible to add this as a default with good performance? Found a library we could adapt and integrate: floating-ui/floating-ui#2053 (comment)

This is now in 1.4.0

I think there are some rare edge cases where it won't update (if the reference is clipped/partially clipped inside a scrolling container, and it moves inside the clipped area), but for the vast majority of cases it should work correctly.