What should happen when "deleteByComposition" is canceled?

[w3c]

What should happen when "deleteByComposition" is canceled?

[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.

[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.

[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.