Yup I also come across this - some banners or header might have a high z-index, and could cover the tooltip, making bad UX.

Ideally, popper would be "smart" enough to detect all z-index items around it and avoid them. Obviously, this is not practical.

Any best practices?

for example:

The only solution is using padding in flip or shift which takes into account the other positioned element, or if your app is not scrollable and instead has individual scrolling containers (e.g. like a desktop UI), you can use a custom boundary to limit it from overflowing its container, thereby not overflowing other positioned elements.

I think this problem is hard to solve and I'm not sure how to even start on the "holes" thing.

Maybe I misunderstood the problem, but here are my immediate thoughts:

Ideally, the DOM would provide a document.nodesWithinRect() sort of like document.elementsFromPoint, and then we could just test if there is any intersection of the returned set with the set of nodes that shouldn't be overlapped. Since we don't have this DOM API, the reverse could be done: maintain the set of nodes that shouldn't be overlapped, tracking overlap of their bounding boxes with our target floating element. If any of these tracked nodes are positioned by floating-ui, then that's a little performance shortcut.

I will note that at the point where mutual positioning constraints come into play, this massively expands the scope of this library into something like autolayout.

I believe there are two algorithms for this — one easy and one hard.

The easy algorithm is already used to detect a clipping boundary. It would be the area of the visible viewport subtracting "fixed"/"sticky" floating elements that are not controlled by Floating UI, but don't really act like "holes" because they're at the edges of the boundary. These are UI elements like a sticky navbar or sidebar.

The hard algorithm is detecting actual "holes" anywhere inside the boundary, where the holes could be other floating elements controlled by Floating UI itself. Forgot to post this here when I first saw it, but I imagine the hard algorithm would generalize the problem and result in positioning like this:

https://twitter.com/blvdmitry/status/1550042703576055808

I decided to actually try to solve this and it took me 1 hour to get this far. I've got some logic working for both flip (which only needs a bool check), and shift (which needs the intersection amounts):

There are some remaining problems:

• shift.crossAxis
• size
• The API (maybe detectIntersection) and bundle size constraints
• Correctly dealing with multiple collidables for a shift (not applicable to the above)
• Detecting other floating elements where they both need to avoid each other, but one likely shouldn't take precedence over the other, meaning there's a kind of "half" avoidance from both (if there's only two), but it gets far more complicated if there's more, something like a flexbox algorithm if they're all side-by-side...

Do you think CSS grids could help? We could draw a grid on top of the page and position the cells to cover the holes, then you could position each tooltip in a cell and have it positioned by grid

The CSS grid solution sounds interesting, but I don't think it helps with needing to coordinate updates between multiple floating elements when they need to avoid each other. Further, positioning is granular to the pixel, and the grid solution may not be suitable for that.

Right now all floating elements can be updated independently of one another and don't need coordination, so we need some kind of system for that.

I've split this into two separate issues:

• Collidables (the demo above demonstrates it, can be shipped soon)
• Coordination (handling a group of floating elements that need to avoid each other in a flexbox-like way, appears trickier when integrating with the collision detection of the rest of the library). The collidable technique works in a rudimentary way for this already, but the positioning doesn't really look nice compared to coordination. [Core] Coordination #2268

does anyone know of an alternative library that does exactly what's described here in the issue?

my use case would be showing multiple popovers simultaneously without them overlapping, while avoiding certain other elements on the page.

@rbozan can you show an example of how the popovers are laid out? Would you prefer them to be laid out like a flexbox (coordination), or can they be arbitrarily positioned, as long as there's no overlapping, where popovers that were opened first (or positioned first) take precedence? The latter (this issue) is likely going to be shipped in a week once I get all the edge cases working correctly.

@rbozan can you show an example of how the popovers are laid out? Would you prefer them to be laid out like a flexbox (coordination), or can they be arbitrarily positioned, as long as there's no overlapping, where popovers that were opened first (or positioned first) take precedence? The latter (this issue) is likely going to be shipped in a week once I get all the edge cases working correctly.

Thanks for the reply. Indeed it would be the latter.

After some research I did choose d3 and their force directed graph but I'll gladly use something simpler for my use case.

@atomiks hi 👋 has there been any movement on the collidables feature?

Not really. I think I'll most likely release a basic version of the feature that covers some useful cases, but won't be "complete" (especially including #2268). Can I ask what you're looking to use it for? This will help me understand the popular use cases more.

One use case that isn't outlined here yet is the new WCAG 2.2 requirement to not obscure elements that receive focus. It would be nice if floating-ui could help us avoid overlaying floating ui elements over elements that currently have focus.

I went into greater detail in #2601 without realizing it's highly related to this here.