Consider implementing more default positions of BalloonPanelView (and using it across features)

[oleq]

ATM when the editable (not the viewport, it's not about RWD) is narrow there are often no positions to choose from to fit the floating panel into the editable, no matter which one is assigned, the panel sticks out.

We need either:

• more itermediate possitions, for instance something in between arrow SW and arrow S,
• a totally fluid balloon arrow positioning when none of pre–defined positions provides any decent fit of the panel into the editable react.

cc @oskarwrobel @Reinmar @mlewand

---

If you'd like to see this feature implemented, add 👍 to this post.

[Reinmar]

I could understand this if the RWD was the reason to work on it. But if it's not RWD, then what's wrong with the above screenshot?

[oleq]

But if it's not RWD, then what's wrong with the above screenshot?

There could be a very limited (horizontal) space for the editor in the application. Whatever is left or right to the editable may be important and shouldn't be covered by the balloon. Or it could belong to a semantically different area like a sidebar or some navigation and having a part of a balloon there is unacceptable. What's more, if it occurs, developers can do absolutely nothing about that – there's no quick fix or a dirty hack to address this kind of issue.

We could fit the balloon in the editable with some extra positions because there's some space left but we don't do that. Instead of staying in the safe zone, CKEditor is "spilling" its UI in the app, something I wrote about earlier in the context of the mention panel. Our goal is to keep the editor UI contained within the editable as long as it is possible because this is the only safe area of the app we control.

This issue is about minimizing the chance of the balloon UI not being contained within editable by increasing the number of positions it can use.