You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now there are a few different situations where you want to include components directly inside the contenteditable editor element—menus, placeholders, etc. Sometimes you can get away with putting them in portals, but
But there are some issues when the components are inside the contenteditable:
The components's HTML will be copied in text/html data, which isn't good because it messes up users copying HTML content out of your editor.
Clicking on the component won't actually select the nearest spot in the editor, which isn't great for placeholders which should be click-through.
What's the expected behavior?
I wonder if it might be good to introduce an <Island> component that allows you to embed these small islands of potentially-ineditable, potentially-uncopyable, etc. content into the editor.
Where they all default to false, but could be toggled to true if needed...
editable === false would make it contenteditable="false".
copyable === false would remove its HTML content from the editor on copies and cuts.
clickable === false would make it so that clicking on it focuses the nearest editable element in the editor, like a placeholder behaves. Whereas clickable === true makes it so that it prevents the click event after you've handled it, so that it doesn't end up stealing the focus from the editor?
So I know they aren't the same thing, but I wonder if this could end up solving the problem I mention here: #2538
Could an Island potentially also contain normal slate components? The use case is toggling off the ability to edit a specific node depending on some state. Or is this outside the scope of this feature?
This really would be amazing. For example, I have a use-case where I would like to embed another editor (Monaco) in to a Slate document. Having an <Island /> component would be perfect for my use case.
Do you want to request a feature or report a bug?
Feature.
What's the current behavior?
Right now there are a few different situations where you want to include components directly inside the
contenteditable
editor element—menus, placeholders, etc. Sometimes you can get away with putting them in portals, butBut there are some issues when the components are inside the
contenteditable
:text/html
data, which isn't good because it messes up users copying HTML content out of your editor.What's the expected behavior?
I wonder if it might be good to introduce an
<Island>
component that allows you to embed these small islands of potentially-ineditable, potentially-uncopyable, etc. content into the editor.It might look like:
Where they all default to
false
, but could be toggled totrue
if needed...editable === false
would make itcontenteditable="false"
.copyable === false
would remove its HTML content from the editor on copies and cuts.clickable === false
would make it so that clicking on it focuses the nearest editable element in the editor, like a placeholder behaves. Whereasclickable === true
makes it so that it prevents theclick
event after you've handled it, so that it doesn't end up stealing the focus from the editor?Related: #2034
Related: #1397
Related: #1344
Related: #1769
The text was updated successfully, but these errors were encountered: