1
0
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:
Jim Fisher
2021-10-19 18:46:17 +01:00
committed by GitHub
parent cab8edea7b
commit 67badb7dd0
4 changed files with 12 additions and 26 deletions

View File

@@ -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,