Make drop-down menus smart

[samclarke]

Makes drop-down menus smart.

If they take up more space than is available below the menu item and there is enough space above, they will open upwards. If there isn't enough space to fully open in either direction they will open in whichever direction has the most space and show a scroll bar so they never overflow the viewport.

Fixes #656, fixes #152 & fixes #543

[samclarke]

I've just realised there is an issue with this. It will only scroll the drop-down with the page, if the editor is in a scrollable container then the drop-down won't scroll when the container is scrolled.

I'm not actually sure what the best UX is around this is so I've had a look at how other editors handle this. I can't see how Word, Pages, Open Office or Google docs handle this as they're designed to be used full screen so don't have this issue.

The options seem to be:

Option 1

Place drop-downs within the editor container so they will scroll with the scrollable parent. This does limit the size of drop-downs to the scrollable container size.

This appears to be what CKEditor does although CKEditor seems to ignore scrollable container when doing the calculations so will open the down-down upwards even if the editor is the the first child of a scrollable parent resulting in the dropdown being cut off (possibly a bug?) like the video below.

Not ideal as limits drop-down size and will cause the drop-down to be cutoff if opening upwards unless the scrollable parent is taken into account.

https://user-images.githubusercontent.com/490870/113579631-7c160280-961c-11eb-9373-4b473643b753.mp4

Option 2

Do what this PR does and place drop-downs in body. This will only scroll with the whole page not a scrollable parent. This seems to be the same behaviour as TinyMCE.

This will result in the menu item and dropdown becoming detached if the scrollable container is scrolled. This does open outside of the scrollable container though so allows more space to be used and nothing gets cutoff if opening upwards.

Also not ideal but I think it might be better?

https://user-images.githubusercontent.com/490870/113580309-71a83880-961d-11eb-9a12-1a81be22313a.mp4

Option 3

Variation on option 2 where the drop-down is scrolled with the scrollable parent. This is better until toolbar is scrolled off page at which point there is a floating drop-down as the drop-down isn't contained inside the scrollable parent.

Not ideal either. This option has a better UX than 2 until scrolled off page at which point its worse.

https://user-images.githubusercontent.com/490870/113580328-7a007380-961d-11eb-84ac-0a4a3096b7de.mp4

Option 4

Variation on option 1 where drop-down only open downwards. Still have the smart left / right behaviour but it never opens upwards. Essentially the old behaviour except with smart left and right positioning. This seems to be what Froala editor does.

Not ideal for space but might be better?

 

None of the options are ideal, they all have pros and cons to them. I think either option 1 (if taking the scrollable parent into account when doing the calculations) or option 2 (this) are the best choices. Any ideas?

[jdarwood007]

I saw this and I think option 1 or option 4 are the best. In any case, somebody will always see any of these options as a bug if they encounter it. I would think 1 or 4 are the best scenarios we can hope for with the most amount of desired results.

If we do 3. Could we possibly detect if the scrollable container leaves the view port and auto-close it?

[samclarke]

In any case, somebody will always see any of these options as a bug if they encounter it.

Yeah, there doesn't appear to be a good solution to this. The only native examples I can find are:

<select> which always open above everything, even if the select is scrolled out of view so can appear detached but it closes as soon as any scrolling occurs though isn't an issue most of the time.

datalist which, at least in Chome on Linux, will remain open above everything and appear detached on scroll: https://jsfiddle.net/t7Ly6sxa/ In Firefox it closes as soon as any scrolling occurs.

If we do 3. Could we possibly detect if the scrollable container leaves the view port and auto-close it?

It's doable and it might be the best option UX wise too. Performance wise it isn't great but should only an issue while a drop down is open. Only issue is it could be a pain to debug and handle all the edge cases but definitely worth looking into.