When I insert a horizontal rule as last node, it is impossible to set the cursor after the horizontal rule. I tested it in the demo.
- Remove every text and elements from the demo editor
- Insert a horizontal rule
- Try to insert text without overwriting the horizontal rule
I had the same experience when I removed the entire content and only had one horizontal rule.
But if instead I did the following, I could add a paragraph after it:
Remove all content.
Insert horizontal rule.
Hit Enter (an empty paragraph before the horizontal rule is created)
Move the selection with the arrow keys so that the horizontal rule is selected again.
Hit Enter (an empty paragraph is created after the rule.
So unless there is only one horizontal rule, it is possible to insert a paragraph after it. But it’s not very intuitive: Why is the paragraph inserted before or after the HR depending on whether or not there is content before the HR?
Hitting enter does the trick It really isn’t that intuitive. You’d expect to move the cursor to the end of the horizontal rule and start typing again.
There is no agreed-on ‘intuitive’ solution to this in WYSIWYG tradition, I think. Some editors allow cursor positions on the line of some block nodes (but not, for example, before and after table nodes, which have the same problem), but that leads to a rather icky behavior as well, since such cursor positions aren’t ‘real’, as you can’t type there or do other things associated with regular text cursors.
I’d agree there aren’t great options here, but the faux cursor still seems preferable to none. I’ve been doing a little bit of user feedback with Prosemirror and have gotten similar reports from users. Honestly, I’d also expect a cursor before/after a table as well. Would it make sense that any typing input from a ‘faux’ cursor forces a new node to begin before/after the table/hr?
ProseMirror doesn’t have faux cursors, and they are unlikely to be added at this point.
Fair enough. Maybe we can develop a plugin that decorates selected block level items.
That might work. Or you could try an interface that responds to the user trying to arrow beyond such an element in some way, either by directly inserting a paragraph, or by showing a control that helps the user insert a paragraph. I think we need some more UI experimentation here to find an unproblematic approach.