Re: [w3c/editing] Ability to rollback changes after IME, so that editors that manage their own incremental rendering can assume the same DOM as before the IME (Issue #510)

michael left a comment (w3c/editing#510)

Actually got the `document.execCommand('undo')` workaround working. See #504.

Still would be great if there was an API that is designed for that purpose, as it might not be guaranteed that `document.execCommand('undo')` undoes the whole character composition sequence.

Here's some options I see:

### Option 1 - Lazy

```js
function oncompositionend(event) {
  event.resetDOM();
}
```
At the end of the composition you programmatically signal to roll back the changes.

### Option 2 - Eager

```js
function oncompositionstart(event) {
  event.rollback_dom_changes = true;
}
```

At the start of the composition, you signal that you want the DOM changes be rolled back. I think @roraja suggested that at the meeting.

### Option 3 - Declarative

```html
<div contenteditable="events-only">...</div>
```

This way we could just change the behavior per contenteditable element. This would mean that after pressing a key (e.g. `a`) nothing happens to the DOM, only the beforeinput events are fired and it's up to you if you want to handle them or not. In the case of an IME, it would still update the DOM during the composition but automatically roll it back after the composition has finished or was cancelled mid-way (as if nothing happened).

I'd personally find this approach the cleanest. Then there can't be race conditions across multiple event handlers etc. This mode could be promoted as the modern way to use contenteditable, when you are building an editor that maintains their own document state, rather then using the DOM as a source of truth (the old uncontrolled way).

What I don't like a bout Option 1 & 2 is that manipulate state within a event handlers (which to be guaranteed to be side-effect free need to be read-only. If you mutate state within your handlers that your responsibility, but somehow my gut says the browser should not change behavior between a sequence of events. It's better if the new behavior is defined upfront.

Currently contenteditable can take `"true"` or `"plaintext-only"`, so this would be the 3rd mode.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/510#issuecomment-3542204586
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/510/3542204586@github.com>