Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add bind:innerText for contenteditable #3311

Closed
khorpy opened this issue Jul 30, 2019 · 14 comments · Fixed by #4291
Closed

Add bind:innerText for contenteditable #3311

khorpy opened this issue Jul 30, 2019 · 14 comments · Fixed by #4291
Labels
compiler Changes relating to the compiler feature request good first issue A small, encapsulated issue, ideal for a new contributor to Svelte to tackle.

Comments

@khorpy
Copy link
Contributor

khorpy commented Jul 30, 2019

There is already bind:innerHTML and bind:textContent implemented for elements with contenteditable="true". But there is also a third property that is also would nice to have: bind:innerText.

InnerText approximates the text the user would get if they highlighted the contents of the element with the cursor and then copied it to the clipboard

@antony antony added the good first issue A small, encapsulated issue, ideal for a new contributor to Svelte to tackle. label Dec 25, 2019
@himynameisdave
Copy link
Contributor

I would love to take on this issue! If possible, could someone direct me to where I would need to look to get started here?

@himynameisdave
Copy link
Contributor

I think this binding would apply to non contenteditable elements as well, correct?

@khorpy
Copy link
Contributor Author

khorpy commented Jan 11, 2020

@himynameisdave I think it makes no sense to bind to non contenteditable elements. The idea is to have user input inside contenteditable elements synced with the local state. That's what bind is for. Please check the docs (https://svelte.dev/docs#bind_element_property).

@himynameisdave
Copy link
Contributor

@khorpy yep fair point, I'll be sure to only apply it to contenteditable elements in my PR then. Thanks for the feedback!

@himynameisdave
Copy link
Contributor

@khorpy I'm having some slight issues testing this, would you mind providing some examples of the expected values you'd be getting from bind:innerText vs bind:innerHTML?

@josdejong
Copy link
Contributor

I can't wait to be able to use this new feature bind:innerText for contenteditable 👍 . I need innerText because it handles returns \n.

Is there any known workaround for the time being?

@himynameisdave
Copy link
Contributor

@josdejong not sure about workarounds, but if you could provide some test cases with \n that would be extremely helpful. #4291 is mostly complete, I'm just having some issues around testing it.

@josdejong
Copy link
Contributor

josdejong commented May 6, 2020

Just to explain a bit about my use case: I'm currently working on a proof-of-concept of svelte-jsoneditor written in Svelte (my way to learn Svelte). In this editor, I need input fields which automatically fit their contents. For that reason, I'm using contenteditable divs and not a textarea for example. Unfortunately there is no simple way to keep multiline plain text in sync with the contents of an contenteditable div. What comes closest is innerText, but this has serious issues too. Setting the innerText works like a charm, but the other way around, getting innerText, often results in too many return characters. In the JSONEditor, I had to write a custom getInnerText which traverses the HTML contents of the div. Besides that it's tricky to keep the cursor in place whilst typing and getting/setting innerText concurrently.

I hope this new feature bind:innerText will magically solve the issues I've always struggled with using editable divs, but I may be too optimistic 😄 . As far as I know there does not exist a solution to keep multiline plain text in sync with the contents of an editable div, which is probably the main reason to use innerText in the first place. It could be a killer feature if Svelte can tackle these complexities once and for all, though it's not trivial. Maybe it shouldn't be named after the (partly broken) innerText and should be named bind:text={text} for example. Just thinking aloud here. If you're interested in thinking this through I may be able to help, I've walked into all traps around dealing editable divs multiple times already 😜 .

Here is a small test playground I was using a few days ago to debug issues with .innerText, you can type in both the contenteditable div and the textarea to see how they behave with: https://jsbin.com/begicis/edit?html,output

@hbbio
Copy link

hbbio commented Nov 19, 2020

Beyond the missing binding, I have the impression that there are some bugs with contenteditable.

I tried to isolate a minimal example here:
https://github.com/hbbio/svelte-md

In this demo, a single store containing markdown is used in 3 editors (one HTML, two instances of markdown). Editing the HTML view does trigger updates to the other editors, but editing the markdown only updates the other markdown. This is despite logs showing proper updates to the store.

Also, when rapidly editing text, some substrings get copied erroneously (probably what you mention @josdejong).

I tried some other bindings methods (in other branches) to no avail.

Edit: I updated the repo with a simpler example (without immer and multiple editors), which shows the two different problems: 1. updating the store does not re-render the rich text editor and 2. editing the markdown adds extra characters (using bind:this={elt} and elt.innerText does not work better).

@stale
Copy link

stale bot commented Jun 26, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@Nazeeh21
Copy link

I would like to give it a try if this issue is still unresolved.

@dummdidumm
Copy link
Member

There's a open PR for this: #4291 . You could test that one out and provide feedback.

@stale
Copy link

stale bot commented Dec 25, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

dummdidumm added a commit that referenced this issue Mar 16, 2023
closes #3311

---------

Co-authored-by: Simon Holthausen <simon.holthausen@vercel.com>
@Conduitry
Copy link
Member

This is now supported in 3.58.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler Changes relating to the compiler feature request good first issue A small, encapsulated issue, ideal for a new contributor to Svelte to tackle.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants