Make onChange work for contenteditable #278

Closed
zpao opened this Issue Aug 19, 2013 · 17 comments

Comments

Projects
None yet
@zpao
Member

zpao commented Aug 19, 2013

Apparently it doesn't, but it would be pretty awesome if it did. We already listen for DOMCharacterDataModified so I don't think it should be too terrible. Tangentially it would be great to stop using mutation events and switch over to observers (let's not do that here though unless it dovetails really nicely).

Interested @spicyj?

@sophiebits

This comment has been minimized.

Show comment
Hide comment
@sophiebits

sophiebits Aug 19, 2013

Member

Maybe, I don't know anything about contenteditable.

Member

sophiebits commented Aug 19, 2013

Maybe, I don't know anything about contenteditable.

@zpao

This comment has been minimized.

Show comment
Hide comment
@zpao

zpao Aug 19, 2013

Member

Fair enough. Let us know if you do end up working on it.

Member

zpao commented Aug 19, 2013

Fair enough. Let us know if you do end up working on it.

@joshduck

This comment has been minimized.

Show comment
Hide comment
@joshduck

joshduck Sep 23, 2013

Contributor

I don't believe 'change' should fire for contentEditable fields but 'input' should be. See https://developer.mozilla.org/en-US/docs/Web/Reference/Events/input and https://developer.mozilla.org/en-US/docs/Web/Reference/Events/change

Contributor

joshduck commented Sep 23, 2013

I don't believe 'change' should fire for contentEditable fields but 'input' should be. See https://developer.mozilla.org/en-US/docs/Web/Reference/Events/input and https://developer.mozilla.org/en-US/docs/Web/Reference/Events/change

@sophiebits

This comment has been minimized.

Show comment
Hide comment
@sophiebits

sophiebits Sep 23, 2013

Member

@joshduck React's onChange intentionally deviates from the spec; see http://facebook.github.io/react/docs/forms.html.

Member

sophiebits commented Sep 23, 2013

@joshduck React's onChange intentionally deviates from the spec; see http://facebook.github.io/react/docs/forms.html.

@joshduck

This comment has been minimized.

Show comment
Hide comment
@joshduck

joshduck Sep 23, 2013

Contributor

@spicyj Sure. It might make sense to a) polyfill onInput for old browsers b) make onChange depend on onInput rather than directly on modification events. That way we get both events.

Contributor

joshduck commented Sep 23, 2013

@spicyj Sure. It might make sense to a) polyfill onInput for old browsers b) make onChange depend on onInput rather than directly on modification events. That way we get both events.

@masklinn

This comment has been minimized.

Show comment
Hide comment
@masklinn

masklinn Feb 2, 2014

That way we get both events.

Are both really needed though? Whenever a difference could exist, React's changes to change basically match the spec's input.

masklinn commented Feb 2, 2014

That way we get both events.

Are both really needed though? Whenever a difference could exist, React's changes to change basically match the spec's input.

@syranide

This comment has been minimized.

Show comment
Hide comment
@syranide

syranide Feb 3, 2014

Contributor

@masklinn Basically match the spec's is a world of difference when it comes to practical usefulness though.

Contributor

syranide commented Feb 3, 2014

@masklinn Basically match the spec's is a world of difference when it comes to practical usefulness though.

@masklinn

This comment has been minimized.

Show comment
Hide comment
@masklinn

masklinn Feb 3, 2014

Basically match the spec's is a world of difference when it comes to practical usefulness though.

Yes. A positive one, as input's behaviour (and react's onchange) are much more useful than the DOM's change event.

masklinn commented Feb 3, 2014

Basically match the spec's is a world of difference when it comes to practical usefulness though.

Yes. A positive one, as input's behaviour (and react's onchange) are much more useful than the DOM's change event.

@brigand

This comment has been minimized.

Show comment
Hide comment
@brigand

brigand Feb 21, 2014

Contributor

I need this for a simple editor. I have to create a ContentEditable component that basically does what <div contentEditable onChange={handler} /> should do. Target browser support is IE8.

The more we can do the normalize contentEditable, the better. It's very useful, but inaccessible due to quirks and weirdness and poor cross-browser compatibility. Full normalization would probably be too complex for React core, though.

Contributor

brigand commented Feb 21, 2014

I need this for a simple editor. I have to create a ContentEditable component that basically does what <div contentEditable onChange={handler} /> should do. Target browser support is IE8.

The more we can do the normalize contentEditable, the better. It's very useful, but inaccessible due to quirks and weirdness and poor cross-browser compatibility. Full normalization would probably be too complex for React core, though.

@edwardmsmith

This comment has been minimized.

Show comment
Hide comment
@edwardmsmith

edwardmsmith Feb 26, 2014

I'd love to see this as well - for same reason as @brigand - to work on a simple rich-text editor for prose.

I'd love to see this as well - for same reason as @brigand - to work on a simple rich-text editor for prose.

@willwhitney

This comment has been minimized.

Show comment
Hide comment
@willwhitney

willwhitney Feb 28, 2014

@edwardmsmith It may not work on older browsers, but for modern browsers you can use the onInput callback like so:

<div
  contentEditable="true"
  onInput={function(e) {
    console.log("woohoo!");
  }}
>initial content</div>

Edit: if you do that, be very sure not to use the app state for that 'initial content'. That will make it a controlled component that gets rerendered every time, and the user's cursor will jump to the beginning of the text with every keypress.

@edwardmsmith It may not work on older browsers, but for modern browsers you can use the onInput callback like so:

<div
  contentEditable="true"
  onInput={function(e) {
    console.log("woohoo!");
  }}
>initial content</div>

Edit: if you do that, be very sure not to use the app state for that 'initial content'. That will make it a controlled component that gets rerendered every time, and the user's cursor will jump to the beginning of the text with every keypress.

@zpao

This comment has been minimized.

Show comment
Hide comment
@zpao

zpao Aug 14, 2014

Member

@salier did we ever make this work? I know a lot has happened in this area since this time last year.

Member

zpao commented Aug 14, 2014

@salier did we ever make this work? I know a lot has happened in this area since this time last year.

@hellendag

This comment has been minimized.

Show comment
Hide comment
@hellendag

hellendag Aug 14, 2014

Contributor

For those requesting this, is your objective to have a controlled contentEditable component that makes use of and onChange event? Or to use native contentEditable behavior in an uncontrolled component?

If it's the latter, is onInput not sufficient for your use case for modern browsers? I'm inclined to agree with @masklinn , though as @joshduck notes, more work may need to be done to get better legacy browser support.

Contributor

hellendag commented Aug 14, 2014

For those requesting this, is your objective to have a controlled contentEditable component that makes use of and onChange event? Or to use native contentEditable behavior in an uncontrolled component?

If it's the latter, is onInput not sufficient for your use case for modern browsers? I'm inclined to agree with @masklinn , though as @joshduck notes, more work may need to be done to get better legacy browser support.

@zpao

This comment has been minimized.

Show comment
Hide comment
@zpao

zpao Sep 23, 2014

Member

Low desire here and a way to make this work so just going to close out.

Member

zpao commented Sep 23, 2014

Low desire here and a way to make this work so just going to close out.

@zpao zpao closed this Sep 23, 2014

@sharmaabhinav

This comment has been minimized.

Show comment
Hide comment
@sharmaabhinav

sharmaabhinav Dec 23, 2014

Is IE9 considered a modern browser ? I tried as @willwhitney suggested and it doesn't seem to work for IE9.

Is IE9 considered a modern browser ? I tried as @willwhitney suggested and it doesn't seem to work for IE9.

@brigand

This comment has been minimized.

Show comment
Hide comment
@brigand

brigand Dec 23, 2014

Contributor

The input event in IE9 has limitations e.g. it doesn't work on backspace, delete, the cut operation, or the delete operation. Is that already resolved in react (I don't have IE9 available right now)?

If you can get the event consistently, and borrow react's internal selection utility, contentEditable is somewhat useable. Of course you still have to normalize the generated html, but that's a problem of its own begging for a third party library.

Contributor

brigand commented Dec 23, 2014

The input event in IE9 has limitations e.g. it doesn't work on backspace, delete, the cut operation, or the delete operation. Is that already resolved in react (I don't have IE9 available right now)?

If you can get the event consistently, and borrow react's internal selection utility, contentEditable is somewhat useable. Of course you still have to normalize the generated html, but that's a problem of its own begging for a third party library.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Dec 23, 2014

Member

Just checking in here to say a combination of onInput and a mutation observer covers modern browsers and IE11.

Member

gaearon commented Dec 23, 2014

Just checking in here to say a combination of onInput and a mutation observer covers modern browsers and IE11.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment