If you have a <kbd>block, you can’t move the caret after it but before the next character.
The video below demonstrates the difficulty in adding/editing the first character after a <kbd> block.
The discussion highlights a bug in the New Composer where users cannot move the caret between a <kbd> block and the following character, a behavior described as expected in HTML contenteditable elements. renato explains that the caret position is treated as a single point inside and outside inline nodes, with a workaround seen in inline code formatting. supermathie expresses frustration with WYSIWYG editors, citing this issue as a reason for avoiding them, a sentiment echoed by seanblue who notes similar bugs across various editors.
If you have a <kbd>block, you can’t move the caret after it but before the next character.
The video below demonstrates the difficulty in adding/editing the first character after a <kbd> block.
This is the “expected” behavior of a HTML content editable - inside and outside an inline node is considered a single position.
The inline code is a great example of an alternative: it shows a fake cursor at that single position, so when you arrow navigate, it’s the same position with different marks, and slightly shifted visually.
I believe an ideal state will be supporting that same behavior for other types of content.
… and this is why I don’t use WYSIWYG editors when possible ![]()
(this is a personal preference that goes back… 35 years all the way back to WordPerfect 5.1)
Exactly. They just never work quite right no matter how much they are refined. I’ve seen this type of bug in so many WYSIWYG editors.