Div block embeds should allow a cursor to be positioned before and after the element (on the same line)

[charrondev]

Am I missing something or does this just not work? Placing the cursor to the left/right of a BlockEmbed works for iframes, images, and videos tags, but not with a div with any nested structure. I'm going to use the cloning medium guide for examples, but the same applies for other BlockEmbeds I've made with a div tag, and other arbitrary HTML inside.

Steps for Reproduction

1. Visit the tweet example on the quill site
2. Insert a tweet.
3. Notice the cursor has been placed after the embed.
4. Click either the left or up arrow key.

Expected behavior:
The cursor will be placed on an edge of the block, like the video embed above.

Actual behavior:
The cursor is moved above the block.

Platforms:

MacOS 10.3.3
Chrome 64

Version:
1.3.5

[seanabrahams]

@jhchen some pointers on how to fix this would be appreciated. Apologies if it's covered somewhere in the docs but I've been searching without luck.

An additional strange behavior is that if you hit backspace when the cursor is below the embedded tweet it deletes the tweet rather than moving the cursor to just after it (inline), from where you'd then expect to hit backspace again to delete it.

@charrondev any progress on your end?

[charrondev]

I've got this issue vanilla/vanilla#6776 probably taking up my full next few days. At least for us we have a lot of custom blots and already have a few hundred lines of custom keyboard handlers for our multiline blots.

Our solution is more likely not going to involve having a cursor before & after the block embeds. Instead the block level elements will be treated as a single element that can be focused using the keyboard arrow keys from before or after and custom focus states for the block level elements.

I'm planning on having the focus state act as if the cursor is at the beginning of the line, so backspace from the following line after an embed will delete the embed block.

Already this will require handlers for arrow keys at all positions of the document, and special behaviour will likely be necessary for the beginning and end of the document. For us this will already be similar to how we handle our multi-line blots, where arrowing from the last position or first position in the document will insert a fresh new line at the end/start of the document. Clicking on one of these blocks in the element will also focus it. I'll follow up here next week once we have our solution.

Our solution will also likely make extensive use of custom labels with summaries of the contents for accessibility purposes. I'm also considering a similar solution with the arrow keys for inline embeds that are to be treated as a single element, like an @mention that has already been formed, but I'm not a 100% sure that will be necessary.

Luckily Quill is extensible enough that a lot of this can be done just be registering a few custom blots and registering some custom keyboard handlers through our custom theme.

[charrondev]

Additionally having a clear selected state for the whole blot like this will let us import some better copy/paste handling for these types of blots.

#1337 Kind of outlined the strategy I'm taking here. @mcmire seems to have come across some issues with drag and drop but that's not an immediate issue for us.

[felipepastor]

Maybe this can help...

https://stackoverflow.com/questions/46130400/quill-js-create-nesting-block-elements-when-inserting-embeds

[JonathanTreffler]

This issue still exists. Is this going to get fixed ?

[quill-bot]

Quill 2.0 has been released (announcement post) with many changes and fixes. If this is still an issue please create a new issue after reviewing our updated Contributing guide 🙏