Dropcursor and dynamic flow direction (inline vs block)

1

Hi,

I’m trying to create a kanban board type drag & drop using a nested “card” node type. I’m using CSS grid to change the flow based on the depth of the card - outermost card has horizontally flowing children (creating columns), the next levels down have vertically flowing children. It almost works, but there are some issues with the dropcursor never showing as a vertical bar, even though the children are laid out in horizontal flow:

http://recordit.co/u9uY1hgDUp

(So the desired behavior would be for the dropcursor to detect that children are in a horizontal flow, and show as horizontal in-between the columns.)

  1. The dropcursor doesn’t seem to be sensitive to the actual flow of the content. I guess in this case it would have to look up into the DOM to find that, not rely on the schema?

OR:

  1. Is there a way for a node to dynamically express it’s flow (so I could set it to inline or block depending on the depth of the card)? Perhaps some way to dynamically decorate the node tree, inserting or hiding nodes and/or changing properties?

Thanks for all the work on this wonderful editor framework by the way :smile: – it’s really cool!

Cheers, Bjørn

2

Not sure if I understand it 100%, but looking at the code for dropcursor/updateOverlay(), it looks like it’ll treat all drop positions in nodes that do not accept inlineContent as a vertical “block” insertion, positioning cursor vertically in-between the nodes before (above) and after (below). Otherwise it’ll treat it like an inline insertion positioning the cursor horizontally in-between the before (left) and after (right) nodes.

I was just wondering if it wouldn’t be possible to just look at the relative position of the rects of the before and after nodes and use that to determine where and how to draw the dropcursor?

3

The library assumes, in several places (also for example cursor motion over selectable block elements), that block elements are above each other. I don’t think looking at element positions would help a lot—there seem to be a lot of corner cases, such as when there’s only one child, where that doesn’t help. It might make sense to have the dropcursor look at some node spec property to determine flow direction (defaulting to horizontal for inline content and vertical for block content).

4

Ok, so perhaps a way to override the current assumption that !inlineContent() => block => vertical, right? If so, then this predicate check could perhaps be used other places too so that’s the only assumption that has to be made?

I asked on stackoverflow if someone has some other clever way to do this in a general way: https://stackoverflow.com/questions/61988974/how-to-determine-whether-an-element-is-displayed-inline-or-as-a-block-in-javascr

5

Hey! Just found this thread, that video is awesome. Would you be willing to open source the node type or plugin? I’d happily contribute any further changes.