In the inlines mode, when I delete an input element, the preceding character of that element will also be deleted.

[elevenwangyang]

Description
In the inlines mode, when I delete an input element, the preceding character of that element will also be deleted.

Recording
https://github.com/user-attachments/assets/b45ce396-72b6-4302-98c5-1fadaa3c9537

Official website example
https://www.slatejs.org/examples/inlines

Steps
To reproduce the behavior:

1. Clear the text within the input element
2. Delete the input element

Expectation
Do not delete the text before the expected element together.

Environment

• Official website example

[nabbydude]

Currently this is because by default deleteBackward (the method called when backspace is pressed) defaults to a until of 'character'. It deletes the first character behind the cursor, and since the inline is empty, it deletes the character beforeit. This happens whether the cursor is inside the empty inline or just after it (if inside it doesnt delete the inline, only the preceding character)

Usually this would also come up when moving the cursor left/right with the arrow keys but the inline example includes code to override the cursor navigation from 'character' mode to 'offset' mode, which is also why if you move your text cursor across a link in the same example there's a hitching feeling as your cursor moves to the same visual position twice--one just outside the link and one just inside. If you paste a button or link into the Paste HTML example it doesn't do the same--the boundary is one cursor stop and whether you land on the inside or outside depends on the direction you come from (at least in my version of firefox on windows). Which one is more intuitive I think depends on the type of inline and situation.

If you made a similar bandaid fix for delete I don't think would work (although admittedly I haven't tested it), pressing backspace at just after the empty inline would delete from that point to the previous offset--the middle of the inline--which is to say, nothing. Same thing would happen if you were to press backspace from inside the inline.

Expected behavior seems intuitive to me and matches vanilla contenteditable behavior (windows ff). I can't imagine any implementer that would want the current behavior to stay that wouldn't just normalize away the inline when it becomes empty. I think delete with character unit can be changed to account for this case--it sounds unintuitive for 'character' mode to not delete a character, but this already happens when deleting the break between blocks, so i don't think its that sinful.

Its a little ambiguous when things get complex though. If [text] is an inline with some text and | is the cursor then desired behavior is:

1. before[]|after --(backspace)--> before|after

but what about this? (where <text> is a second inline):

2. before[<>]|after --(backspace)--> before[|]after ? before[]|after ? before<>|after ?
3. and hitting backspace again? --> befor|[]after ? before|after ?

[elevenwangyang]

This is what I want：
1. before[]|after --(backspace)--> before|after

But in reality：
2. before[]|after --(backspace)--> befor|after

If I want to implement Option 1, are there any feasible solutions available at present?