Re: Proper use of compositionstart and compositionupdate events for Android IMEs

Ryan Landay wrote:
> I'm interested in getting feedback, especially from developers of rich
text editing applications, as to
> whether the spec could be changed somehow to make it more useful. E.g.,
should we be able to
> send the initial composition text in the data field of the
compositionstart event, even if it's not selected?

Thanks very much for reaching out, Ryan! As a developer of mediawiki's
VisualEditor, I'd say not knowing enough about the composition range has
always been a major limitation for us.[*]  So *anything* that lets us pin
this down more is good. Yes, full candidate window events would be great,
but until then, just getting the initial composition string in a
compositionstart would be a lot better than nothing.

2018-02-21 16:18 GMT+08:00 Johannes Wilm <johannes@fiduswriter.org>:
> Question: Between such a "fake" compositionend and compositionstart
event, would it be possible
> for JavaScript to manipulate the DOM? I mean usually within a composition
not much can be done,
> so the JavaScript will wait until the composition is done with applying
any changes. In a collaborative
> setup there may even be changes coming in from collaborators that are
held back until the
> composition is done. So it would be good to have at least interruptions
in the composition process
> (such as when the composition range changes) to be able to work on trying
to merge local and remote
> changes.

We have also experienced this type of issue - applying collaborative
updates can interact badly with the IME, so queueing the updates and
deducing "safe" times to apply them is basically the only practical way
forward. Again, more info about the composition range will always be better.


[*] Not knowing composition ranges is a major reason we switched to using
explicit "link cartouches", where the cursor has to explicitly step in/out
of links (with transparent image "nails" bookmarking the cartouche
boundaries) - see
https://www.mediawiki.org/wiki/Help:VisualEditor/User_guide#Editing_links .
The combined restrictions imposed by unknown composition ranges,
unguessable bidirectional cursor behaviour, font-specific grapheme
clustering and the sheer number of (browser x version x OS) behavioural
variations make it really hard to handle link boundaries in any other way,
because they break most possible ways of fixing up the document as the user
types. (It took us well over a year to settle on this workround).

Thanks,
-- 
David Chan