[beforeinput] Should we allow canceling the committed text from IME?

[chong-z]

Currently all events between compositionstart and compositionend are non-cancelable, and there shouldn't be remaining DOM update in and after compositionend.

So to override text insertion developers have to

1. Override insertText for normal typing
2. And use a cE=typing container to handle IME (See #76 #84)

Will it be better if we can make the last insertText for composition cancelable? So developers only needs to do 1.

---

For example with Hiragana IME:

(Press key labeled as a)

1. compositionstart
2. beforeinput (insertText, data='あ')
3. compositionupdate (data='あ', displays with underscore)

(Press Space twice to open selection box and switch to next possible character) (Events for the second Space)

4. beforeinput (deleteComposedCharacterBackward, deletes 'あ')
5. beforeinput (insertText, data='方')
6. compositionupdate (data='方', displays with underscore)

(Press Enter twice to Accept selection and Commit text) (Events for the second Enter)

7. beforeinput (deleteComposedCharacterBackward, deletes '方' with underscore) 8. beforeinput (insertText, data='方', no underscore)
8. compositionupdate (data='方', no underscore)
9. compositionend (data='方')

So my question is can we make 8. cancelable? (At this point IME should have finished and UA only need to remove underscores.)

---

Also am I using deleteComposedCharacterBackward correctly? It seems a little bit weird to fire two beforeinput for one compositionupdate...

[johanneswilm]

If this doesn't create technical difficulties, I think that would be preferable as it gives JS authors more options. In a basic setup they can let the user compose whatever characters they want, and then decide whether and how to embed the final text at the time the entire text is committed.

There may still be situations where one may want a cE=typing container. For example, in a collaborative editor, the edits of collaborators may change the structure of the document while composition is taking place. It will be difficult to make sure that none of the DOM structure around the currently composed character due to the work of collaborators. It will be easier to only make this decision at two points in time: when composition starts and when composition ends. If at both times the insertion of characters at the selection is possible, the edits go in. Otherwise not.

For example:

• User A is composing a series of characters inside a paragraph 1, while user B is switching the blocktype of paragraph 1 so that it becomes headline 1.
• User A is composing a series of characters inside a paragraph 1, while user B is adding a comment to most of paragraph 1, which causes this part of the paragraph to be wrapped inside a <span class="comment comment-1">...</span>.

[johanneswilm]

Thinking more about this, another way of dealing with this would be to let the user IME-construct the characters in place and just not send those changes to collaborators during construction and then handle your point 8 as the change event that will be distributed to collaborators.

This would then probably mean that one would A) cancel and remove half-constructed characters if a change arrives that will change the DOM surrounding the characters that are in construction. Or B) one could try to wait applying changes until the construction is done. Or C) a combination of both with a timer.

For example:

A) User 1 is currently constructing a number of characters in paragraph 1, when diff 1 form user 2 comes in that will turn the paragraph 1 into headline 1. IME is canceled and the already constructed characters are removed (by means of JavaScript). Diff 1 is applied.

B) User 1 is currently constructing a number of characters in paragraph 1, when diff 1 form user 2 comes in that will turn the paragraph 1 into headline 1. The JS editor waits until user 1 is done with the construction of characters within IME. The entire constructed character string insertion (point 8) is turned into a diff 2. The document is rolled back to the state before character insertions. Then first diff 1 is applied, thereafter application of diff 2 is attempted. if this application is successful, it is distributed to collaborators. If application of 2 proves impossible, it is given up upon.

C) Generally like B, but a timer is set when a new diff comes in and IME construction is taking place. If the construction of characters doesn't finish within X seconds, follow A.

This may still cause unexpected behavior -- for example it may not be clear to the person constructing characters why a particular incoming diff causes their construction to be interrupted -- but I think it should work.

In short: Yes @choniong, I think it would help a lot if we could make sure that 8 is cancelable. How would the JS know an insertion event is 8? Just by listening to all insertText beforeinput events during IME and then waiting for the one which is cancelable, which then must be the last one within that IME construction? This is certainly possible, although it's not that self-explanatory.

Also am I using deleteComposedCharacterBackward correctly? It seems a little bit weird to fire two beforeinput for one compositionupdate...

Yes, this looks correctly to me.

[johanneswilm]

There seems consensus to do this -- if possible. Android/iOS are currently investigating and this is tracked in https://github.com/w3c/input-events/issues/17