Making breakpoints intuitive *AND* selectable

#1

I’ve written a (now) very big and complex selection plugin that paints CSS onto the editor to make selections visible (I made the simple version OS on NPM https://www.npmjs.com/package/prosemirror-selection-leaf-plugin I’d add the more complex one but it’s reeeally bespoke to my build). To get this to work properly with <br /> I had to do some extra work. In the end, I settled on a node that is comprised as follows: <span class=“pm-br”><br /></span>

This is almost spot on, but the span causes some weird behaviour with the cursor sometimes. see the demo below:

ContentEditableSucks
ContentEditableSucks.gif851×256 654 KB

I’m certain that this is a problem with content-editable rather than prose mirror. I’m just wondering if anyone has any ideas how I might get around it. I’ve tried all kinds of variations, including separating out the span as a mark and the break as a node (which led to some weird and unreliable UX), using a div instead of br (again, weird UX) and a whole load of other subtle schema variations. simply put, this is the best of a bad bunch (again, thank content-editable for the glitches, for sure)

I’d really like the issue patched so, please, suggestions are very welcome!

My next avenue of investigation would be some kind of plugin to move the cursor back to the start of the line in the above instance (I think the cursor is actually rendering on the wrong line as the user is technically positioned after the break tag of the previous line rather than before it). Is it possible to move the user’s cursor in a plugin?

#2

Yeah, a span directly around a single br is probably a thing browser implementers didn’t think about very much yet. I’d encourage you to submit bug reports to whichever browser is misbehaving in the video (it should probably be easy to reproduce in a plain editable div), maybe they’ll eventually fix it.

As a workaround, you could try only applying the spans when the nodes are actually selected.

#3

I finally nailed it using unadulterated break tags and widget decorations! It requires quite a lot of digging around in a parent node’s content, but once I’ve figured out what constitutes a break that needs decorating, all I do is slap a styled decoration widget straight after it! One discovery I’ve made by virtue of all this work is that Chrome is especially ugly at selecting stuff in content-editable.

I’m still bowled over by just how counter-intuitive all the major browsers are in terms of managing selections in content-editable. Pity!