Re: ISSUE-141 (IME examples): IME examples [DOM3 Events]

On Wed, Oct 6, 2010 at 9:22 AM, Web Applications Working Group Issue
Tracker <> wrote:
> ISSUE-141 (IME examples): IME examples [DOM3 Events]
> Raised by: Doug Schepers
> On product: DOM3 Events
> Hallvord R. M. Steen <>:
> [[
> In the text about Input Method Editors [1], the examples do
>> keydown: 's' (U+0073, Latin Small Letter S key)
>> compositionstart: ''
>> keyup: 's' (U+0073, Latin Small Letter S key)
>> keydown: 'i' (U+0069, Latin Small Letter I key)
>> keyup: 'i' (U+0069, Latin Small Letter I key)
>> keydown: 'Convert'
> Now, I'm not a developer - merely a "black box" QA tester - but is it
> possible to implement this in a cross-platform way? AFAIK, on Windows,
> Windows mobile and perhaps other platforms all the implementation will get
> in a keydown event is a VK_PROCESS virtual key code. How is the
> implementation then supposed to map that to an 's', an 'i' and so on?
> What sensible implementations currently do is to fire keydown with keyCode
> set to 220 (VK_PROCESS) and keyup with the actual key's virtual key code -
> if the platform makes it available in keyup events, otherwise 229.
> (Sorry about the number of separate E-mails today. I've tried to read the
> spec carefully earlier, but it's funny how you overlook things and they
> suddenly jump at you..)
> [1]
> ]]

I think I had similar concerns when looking at what the IME for Maemo5
or its successor could provide (it tends to take lots of shortcuts).

I think in general it is not safe to expect IMEs to be particularly
forthcoming in their contribution of events.

Also, the Maemo 5 IME can do things like complete "ti" as "timeless",
from my perspective this is really an IME effect, it's equivalent to
me <paste>ing "timeless" or "meless" over/after "ti" (however you want
to think about it), it isn't equivalent to me typing "t" "i" "m" "e"
"l" "e" "s" "s", as I didn't do that. One reason to consider this is
when you look at how PuTTY for s60 or the Maemo IME work w/ SSH
sessions over dialup. If each character is pressed, each would be sent
as its own *expensive* packet over a slow and expensive dialup link
(where the user is paying per padded encrypted packet), plus the round
trip response packets. In mobile devices each packet and each
computation to process each useless intermediate step is expensive, so
avoiding them is appreciated.

Received on Sunday, 10 October 2010 16:30:58 UTC