mirror of
https://github.com/ianstormtaylor/slate.git
synced 2025-08-28 09:29:49 +02:00
Allow typing at the end of an inline element (#4578)
* Allow typing at the end of an inline
This fixes https://github.com/ianstormtaylor/slate/issues/4524
Steps to reproduce the buggy behavior:
* Create a page with an inline element, or go to
https://codepen.io/jameshfisher/pen/xxrXvVO
* Put the cursor at the end of the inline code element
* Type something
Expected behavior: If the cursor is at the end of an inline, text
should be inserted at the end of the inline.
Actual behavior: Slate moves the cursor outside the inline before
inserting text.
This current behavior is explicitly coded. I nevertheless claim that
this is a bug, or at least a misfeature in core. My expected behavior
comes from:
* The fact that the cursor is inside the inline. For the user, the
blinking cursor is visually inside the inline, not outside it. For the
developer, the cursor (i.e. editor.selection) is inside the inline,
not outside it. The definition of "the cursor" is "this is where your
text will go when you type". To break that behavior is really jarring.
* Slate's principle that "all of its logic is implemented with a series
of plugins". If the current behavior is actually desirable in some
circumstance, it should be in a plugin, not core. It's harder and less
elegant for me to remove the core behavior with my own plugin.
* Comparison with other editors. The following editors all insert text
at the end of the inline, as expected: default contenteditable,
Medium, Coda.io, Google Docs, OneNote, Evernote, QuillJS, TinyMCE,
EditorJS, ProseMirror. Two editors with the current buggy behavior are
Notion and Dropbox Paper, but I find it hard to imagine that their
current behavior on this issue is actually designed, and not just
accidental.
* Usability: how else is the user supposed to enter text at the end of
the inline ..? The only way seems to be to insert text before the end
of the inline, and then delete the rest of the inline. This is
obviously horrible.
* add changeset
* Fix test: insert at the end of an inline should _not_ have special behavior
* The selection is no longer moved in insertText so we don't need this special case
* fix:prettier
* Revert "The selection is no longer moved in insertText so we don't need this special case"
This reverts commit f9f36cd439
.
* Explain the real reason for this special case - native browser bugs
This commit is contained in:
@@ -288,7 +288,7 @@ export const Editable = (props: EditableProps) => {
|
||||
event.data &&
|
||||
event.data.length === 1 &&
|
||||
/[a-z ]/i.test(event.data) &&
|
||||
// Chrome seems to have issues correctly editing the start of nodes.
|
||||
// Chrome has issues correctly editing the start of nodes: https://bugs.chromium.org/p/chromium/issues/detail?id=1249405
|
||||
// When there is an inline element, e.g. a link, and you select
|
||||
// right after it (the start of the next node).
|
||||
selection.anchor.offset !== 0
|
||||
@@ -301,7 +301,8 @@ export const Editable = (props: EditableProps) => {
|
||||
native = false
|
||||
}
|
||||
|
||||
// and because of the selection moving in `insertText` (create-editor.ts).
|
||||
// Chrome also has issues correctly editing the end of nodes: https://bugs.chromium.org/p/chromium/issues/detail?id=1259100
|
||||
// Therefore we don't allow native events to insert text at the end of nodes.
|
||||
const { anchor } = selection
|
||||
const inline = Editor.above(editor, {
|
||||
at: anchor,
|
||||
|
Reference in New Issue
Block a user