* Official custom inlines example
This generalizes the "links" example to an "inlines" example, adding
a new example of an inline: an "editable button".
Firstly, this is important to demonstrate that Slate really does allow
_custom_ elements, and not just "standard" ones like links that you'll
find in any editor.
Secondly, it's important to show an example of an inline where "offset"
movement should be used. With links, it's arguable that the cursor
positions <link>foo<cursor/></link> and <link>foo</link><cursor/>
should be considered the same, because they display in the same
position. But with the editable button, the cursor is clearly in a
different position, and so offset movement should be used.
* lint
* fix integration test
* update readme
* try again
* 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
Due to standard link CSS, the cursor at the end of the link looks the
same as the cursor immediately after the link, and the cursor at the
start of the link looks the same as the cursor immediately before the
link. However, these are semantically different locations. I've had
several problems with Slate misinterpreting these locations, and had
trouble showing these problems to others using the standard examples,
because the only example of an editable inline element is the link.
To fix this, I've added a box-shadow to the link when it's selected. It
should now be clear to the user whether the cursor is inside or
outside the element.
* defer native events internally to Editable
* add changeset
* suggestions to make DeferredOperation a closure instead of an object type
Co-authored-by: Nemanja Tosic <netosic90@gmail.com>
* fix misapplied suggestion
Co-authored-by: Nemanja Tosic <netosic90@gmail.com>
* Fix bug: setting selection from contentEditable:false element causes crash
Fixes https://github.com/ianstormtaylor/slate/issues/4583
When clicking some text in a `contentEditable:false` element, if the
handler for this sets the selection, Slate crashes. Slate tries to find
a Slate range for the text that was clicked on, but there is no such
range, because the text is inside a `contentEditable:false` element.
Slate seems to be making a bad assumption that the current DOM selection
necessarily corresponds to a Slate range, but this is not the case if
the user just clicked into an element with `contentEditable: false`.
To fix this, I changed `exactMatch: false` to `exactMatch: true`,
which seems to mean "fail gracefully if there is no exact match".
* changeset
* Revert "Fix bug: setting selection from contentEditable:false element causes crash"
This reverts commit 71234284cd.
* Unconflate exactMatch flag: add suppressThrow flag for separate behavior
* Fix bug: setting selection from contentEditable:false element causes crash
Fixes#4583
When clicking some text in a `contentEditable:false` element, if the
handler for this sets the selection, Slate crashes. Slate tries to find
a Slate range for the text that was clicked on, but there is no such
range, because the text is inside a `contentEditable:false` element.
Slate seems to be making a bad assumption that the current DOM selection
necessarily corresponds to a Slate range, but this is not the case if
the user just clicked into an element with `contentEditable: false`.
* Updates "Saving to a Database" example to distinguish actual content changes.
* Update docs/walkthroughs/06-saving-to-a-database.md
* Update docs/walkthroughs/06-saving-to-a-database.md
* Update docs/walkthroughs/06-saving-to-a-database.md
* Runs prettier
* docs: clarifies not setting editor values directly & plugin order
* Changes reccommended order of withReact & withHistory, to match current knowleged
Co-authored-by: Dylan Schiemann <dylan@dojotoolkit.org>
* Don't remove selection when hovering over a non-selectable node
Fixes https://github.com/ianstormtaylor/slate/issues/4545
To reproduce the buggy behavior:
1. Create a page that renders a Slate element with a `contentEditable: false` element in it.
2. Start selecting some text with the mouse.
3. During the drag, mouseover the `contentEditable: false` element.
Expected behavior: After doing a drag-to-select with the mouse, from a valid anchor point on mousedown to a valid focus point on mouseup, the selection is set to those anchor and focus points.
Actual behavior: your selection is removed as soon as your mouse hits the `contentEditable: false` element. This is because the current behavior clears the selection if it is momentarily not a valid Slate location.
* Add changeset
* Allow passing custom slate editor creator to slate-hyperscript createEditor()
Makes it easier to create your own testing setup
* run fix:prettier
* remove unused createEditor
* Add changeset
* fix lint and remove accidentally committed file
To see the problem, visit https://docs.slatejs.org/general/changelog and follow the links after "...each package will maintain its own individual changelog, which you can find here:"
In Firefox, `range.cloneContents()` returns an extra trailing '\n', when the document ends with a new-line character. This results in the offset length being off by one, so we need to subtract one to account for this.
* correct immutability lockfile flag for yarn 3
* More experiments to re-enable the Version Packages action
* add changeset
* more work to fix automated changeset workflow
