Thanks for the detailed explanation above - i think we need to jump on a call on Monday and discuss this in detail, but until then, thoughts below:
Should I follow the same handle strategy for embeds and images ie when it receives the focus, I'm revealing the handle ?
Instead of giving users the ability to move content by hovering (then clicking and dragging) on the element borders, why don't we bring back the "move" icons in the contextual toolbar? See the attached wireframes (WF 1-3) That way, we can keep the existing behavior and relegate the moving functionality to a specific point in the UI.
For instance, if you have an image floating on the left with some text on its right and if you drag an element so it's added right after the image, the element will be visually added right before the text not below the image.
Wait, isn't this the expected behavior though? In your situation, I'm dragging the new element in between the image and the text, correct? Then it makes sense that the new element appears in the place that the text did. Maybe this would be better explained on a call?
How do we handle list ?
We should make the list it's own separate element. Is there a reason why it's not in the current implementation? If it's an element, then the user would be able to move the lists around, wouldn't they? Let's dive into this a little bit more on the call
I would suggest we introduce a "structure mode" in Online Editor to handle the elements position. In that mode, the user would not be able to edit the content but only to move (and maybe remove) blocks.
If we allow users to move the elements by use of the "move" icons in the toolbar, wouldn't that achieve the same goal as the separate "structure" mode? Essentially the same as Sir Trevor, except the functionality would be within the toolbar that appears when a user clicks on the element instead of on hover as it is currently in Sir Trevor.