What should happen when "deleteByComposition" is canceled?

[whsieh]

According to the spec, "preventing the default action for [deleteByComposition] will mean that [the recomposed] range will not be removed from the DOM by the user agent." However, does this mean that the page should still show UI for editing the composition (for instance, a list of candidates) and allow typing to edit the composition, but just not modify the DOM in the process? If so, would the input events dispatched for a page that prevents default on both "deleteByComposition" and "insertFromComposition" look like this when recomposing text:

Dispatch beforeinput event of type "deleteByComposition"
< preventDefault() is called, and we keep the text being recomposed exactly the same >

< user selects a candidate/types something >
Dispatch beforeinput event of type "insertCompositionText"
Dispatch input event of type "insertCompositionText"

< user selects a candidate/types something >
Dispatch beforeinput event of type "insertCompositionText"
Dispatch input event of type "insertCompositionText"

< ...and so on... >

< finally, user hits enter to commit the composition >
Dispatch beforeinput event of type "insertFromComposition"
Dispatch input event of type "insertFromComposition"

^ I also had a question about the behavior of insertFromComposition in this circumstance, but Ryosuke added a question covering that here: #41

[whsieh]

• @rniwa @choniong @hober @ojanvafai

[johanneswilm]

@whsieh AFAIK, the composition will go ahead as planned, no matter whether or not deleteByComposition is being preventDefaulted. The first step of that is a noncancelable insertCompositionText which inserts the entire composition string into the DOM (in case of recomposition).

In the case of a recomposition, this means that if the JS preventDefaults the very first deleteByComposition, and then doesn't remove what is to become the composition string from the DOM itself, the contents of the composition string will be seen twice: once as it was before, and a second time in the composition string.

I've tried to summarize the procedure in this note: https://w3c.github.io/input-events/#h-note4 . We should probably additionally have some examples.

[rniwa]

Note is non-normative, this really needs to be spec'ed in normative text somewhere.

[johanneswilm]

Note is non-normative, this really needs to be spec'ed in normative text somewhere.

Yes, it is. I primarily added it as a help for JS developers who will try to use these events to create editors based on the beforeinput event. It is marked as non-normative, as it's not meant to define new behavior for browser implementers.

Is the note's content the same content you would like to see as normative text for implementers?

[rniwa]

The current node you linked isn't precise enough as normative text. We need to spec precisely what happens for each event but that the normative text probably needs to be in ui events instead.

@travisleithead @garykac

[johanneswilm]

We need to spec precisely what happens for each event

What do you mean by "each event" in this case? Do you mean to say you want the contents of the note referenced above, but in a more technical language? Or is it something completely different?

Gary has been starting a new spec on event order: https://github.com/garykac/event-order/blob/master/index.bs because ui events is too full.

[rniwa]

What do you mean by "each event" in this case? Do you mean to say you want the contents of the note referenced above, but in a more technical language? Or is it something completely different?

We need to specify the ordering of each event, and what happens when each one of the event is canceled, or DOM is mutated, etc...

Gary has been starting a new spec on event order: https://github.com/garykac/event-order/blob/master/index.bs because ui events is too full.

That's good. We really need to spec the precise event ordering there.

@annevk : I guess this is what you want re: processing model.

[annevk]

Not sure, it's not so much about order (although that's obviously a part of it), it's mostly how they influence each other, get their state, perform actions (such as drag-and-drop), etc.

[chong-z]

In short preventing 'deleteByComposition' should behave similar to collapse selection forward and start composition (but will probably pre-insert some marked text).

@rniwa Yes I agree that we need some precise definition for each inputType. But before that happens #34 (comment) is the original proposal for IME related Default Action and Event Order, hope that helps.