Re: [w3c/uievents] specify how compositionend works if the caret has been moved to a different element (#5)

Not sure how dead this is either, but since it's still open I guess my input might also be useful at some point. ;)

There are two definitions in the current draft which I deem underspecified:
1. composition session
1. active text passage

# 1. composition session
A composition session is currently defined as starting with a `compositionstart` event, followed by one or more `compositionupdate` events and ending with a `compositionend` event. This seems underspecified in two different ways which lead to Android being different than every other platform I am aware of.

## 1.1. When to issue `compositionstart`
Should a composition session start when the first change occurs, or is it sufficient to display an IME for existing text? As an example, on Android, placing the caret inside a word starts a composition for the word touched by the caret.

## 1.2. When to issue `compositionend`
Can a composition session span multiple disjoint ranges? Currently, on Android, placing the caret inside a word, inserting one character and finally moving the caret inside a different word is all part of one single composition session. On other platforms, a composition session would start only when the character is entered, and moving the caret to a disjoint location would end the composition without starting a new one.

# 2. active text passage
The definition of the `componentupdate` event is the only place where the notion of an `active text passage` is mentioned. It does suggest that Android was taken into consideration as placing the caret inside a word will make the whole word part of that `active text passage`. Unfortunately, wordarounds must be used by client javascript code in order to reconstruct that range as it is never provided by the event.

# Potential solutions
Without requiring major changes to the current implementations, I believe client javascript code could handle composition events better if both `compositionstart` and `compositionupdate` events provided the range associated with the `active text passage`. This way, both behaviors unique to Android could be reasonably managed without brittle workarounds.

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