slate
slate copied to clipboard
ianstormtaylor
Paste-HTML example does not allow for pasting images
Do you want to request a feature or report a bug?
bug
What's the current behavior?
When trying to paste an img into the paste-html example, nothing gets pasted.
- Information about your OS, browser, Slate version, etc. OS: Mac Mojave Browser: Chrome Slate Version: 0.58.4
What's the expected behavior?
The expected behavior is that the editor should render the image that is being pasted.
What you are showing on the gif is pasting data.files, not text/html, i.e. you're not pasting HTML. The image pasting logic is handled at https://www.slatejs.org/examples/images
Relevant code: https://github.com/ianstormtaylor/slate/blob/1cf63f0a19a45c3b35ea3f8682e57a28cacfb4d1/site/examples/images.js#L47-L63
Hi @mdmjg! I agree it's a little counter intuitive that paste html can't deal with image pasting, however it's mostly because (as @markogresak has pointed out) the paste html example does not support images. It is a bit awkward but I'm hesitant to add image support to the paste example because that example would get a bit unwieldy and duplicative with the image example.
Interested in your thoughts on the duplication here.
Pasting images, in some cases, may require a back-end component for complete functionality (i.e. certain web pages will not allow images to be sourced from domains other than the original host). Sounds like out of scope for HTML example but perhaps worth an note/explanation.
@dmitrizzle not sure if it applies for the scope here. See the images example, it already supports it (see the code in my comment above). When copying the image, it's saved in the clipboard memory and you can read that via FileReader on paste. It's just a binary transfer.
If I understand correctly, what you're describing applies only if you want to store the editor content, including the image. But that's application-specific logic and not a concern of Slate. So it does not make to include it in the example code.
@markogresak I agree, all of this should be out of scope for the HTML example. However, the back-end component I mentioned isn't for storing. It's not really relevant to the point, but thought I'd explain anyways in case anyone is looking for answers here (feel free to remove):
If you ctrl+c content off another website (i.e. you are trying to copy your own blog article and submit it onto another website that uses Slate as an editor), the content is likely not to have images as binary but URLs. What needs to happen from there on, is the image URLs from the clipboard to be either converted to a binary (which won't happen automatically) or have all those image URLs copied on the back-end to the new server and provided as a new URLs. Leaving it as-is may lead to broken images or unintended hosting of images on third-party websites.
Taking a screenshot also returns the image as a URL rather than as file data.
Similarly, if you copy some HTML that includes <img> tags and paste it into slate, the images are removed (which doesn't happen with vanilla contentEditable). This happens on the image demo as well as the HTML example so I presume it's built-in behaviour for slate.
I haven't raised that as a separate issue because although it's different technically, it relates to the same use case, so the discussion here is relevant.
