BalloonPanelView's limiter option should be configurable

[oleq]

ATM the limiter is hard coded by the Link Plugin to the editable element the selection is anchored to. Depending on the integration, some editors may be restricted by parents with overflow:scroll and then such limiter makes little sense as getOptimalPosition() works on DOMRects, which are the same regardless of the element being cropped by the parent.

Proposed config names: ui.floatingElementsLimiter, ui.balloonPanel.limiter.

Additionally getOptimalPosition() could check all the ancestors of the limiter which have overflow different than visible and intersect all their rects one by one up to window to find the real visible area which is available to position the BalloonPanel. That would, in most cases, make the limiter configuration obsolete.

[oleq]

Asking @oskarwrobel to chime in. I wonder if the getOptimalPosition() fix is just enough.

[oskarwrobel]

I wonder if the getOptimalPosition() fix is just enough.

I think it should be enough. Worth to try.

[Reinmar]

ui.floatingElementsLimiter still indicates that it's only about floating stuff (what about "aside" stuff?). And perhaps instead of "elements" you could say "components"?

[Reinmar]

Finally, "limiter" is how you call these things in the code. Please keep in mind that the config is for the "outside" world. I don't mean that "limiter" must be wrong, but perhaps there's a convention used by some other libraries.

[oleq]

We'll try to fix up the getOptimalPosition() a little first. There's a chance it will make the configuration obsolete. Plus, it will get even smarter, which is great for other possible use cases.

[oleq]

Closed by ckeditor/ckeditor5-utils#149.