Re: [w3c/editing] Expose event.getTargetRanges() in oncompositionstart (and possibly oncompositionend as well) (Issue #511)

masayuki-nakano left a comment (w3c/editing#511)


@michael 
> in most browsers I believe the selection will be the same as the composition target range at `oncompositionstart`, however on Samsung-Android this is different. E.g. when you start typing at the end of the word, it will start a composition that includes the whole word (so also here selection !== composition target range at compositionstart).

In my understanding, when browsers dispatch `compositionstart`, the `Selection` should've already been updated for the range which will be replaced by the composition. And that must be enough for your case.

> There are two reasons I'd like to capture event.getTargetRanges() in oncompositionstart:
> 
>     1. More intuitive: It avoids adding logic to onbeforeinput to capture the target range before the composition starts (see relevant [code](https://github.com/michael/svedit/blob/ce56d875dc8d57a28e4aa413697a639c5d3e23d4/src/lib/Svedit.svelte#L108-L112) in my editor)

I'm not sure about this...

>     2. Also covers the special case where there's `oncompositionstart` followed by `oncompositionend` directly, with no `onbeforeinput` in between, like in the Samsung Android Dictation On/Off scenario. Here's a relevant  [workaround](https://github.com/michael/svedit/blob/ce56d875dc8d57a28e4aa413697a639c5d3e23d4/src/lib/Svedit.svelte#L239-L242) to avoid the problem shown in the video.

Well, sounds like that it'd be nicer if UI Events changes the definition of `compositionstart`. That's defined as:
> A [user agent](https://infra.spec.whatwg.org/#user-agent) MUST dispatch this event when a [text composition system](https://w3c.github.io/uievents/#text-composition-system) is enabled and a new composition session is about to begin (or has begun, depending on the [text composition system](https://w3c.github.io/uievents/#text-composition-system)) in preparation for composing a passage of text.

So, currently, `compositionstart` is exposed event of the native composition start.

However, in my experience, this does not work well if browsers do so strictly. Linux's Korean IME and Chinese IME may start composition immediately after an editable thing gets focus and ends composition at its blur. However, this must not be expected by web apps. So, I think browsers should dispatch `compositionstart` when the composition string becomes non-empty and `compositionend` when the composition string is either partially or fully committed. Then, the odd empty composition won't happen.

Cc: @garykac

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

Message ID: <w3c/editing/issues/511/3645314479@github.com>