W3C home > Mailing lists > Public > public-html-ig-zh@w3.org > August 2011

Re: Re: ISSUE-137 (IME-keypress): Should keypress events fire when using an IME? [DOM3 Events]

From: John Hax <johnhax@gmail.com>
Date: Fri, 12 Aug 2011 14:12:22 +0800
Message-ID: <CAEeYXHVUg2mc4Pjox1OH-keL-QkyvaMoGAONcbS60RT0THjQjQ@mail.gmail.com>
To: "Kang-Hao (Kenny) Lu" <kennyluck@w3.org>
Cc: (wrong string) 妯傛渻ML <public-html-ig-zh@w3.org>
我认为这个事情是相当显然的。假设一个游戏捕捉keydown/up/press操作。输入法组字显然和操作游戏的按键是两码事。所以在输入法组字时触发keydown/up/press是很诡异的事情。

考虑mobile系统就更清楚了,在mobile系统里,输入法几乎就等同于modal dialog,所有键盘操作应该是被完全接管的。

唯一我们可以接受的是它发出一组特定的键值,例如过去的惯例是keydown 229加上keyup实际按键。


其实更加烦人的是value change的问题。见此贴:
http://www.cnblogs.com/cathsfz/archive/2011/05/29/2062382.html#2145980

相比发出keypress事件(实际上现在没人这么做),更不能接受的是发出input/textinput/change事件。


2011/8/12 Kang-Hao (Kenny) Lu <kennyluck@w3.org>

> **
> 從 Web App 工作組轉來的信,大意是說輸入法在組字的時候不應該觸發鍵盤事件(keydown、keyup 及
> keypress)的一些論述,我沒有仔細消化,不過除了 2. 的邏輯看起來很怪應該是對的。
>
> 就算沒有反對意見我們也可以直接說「支持」,大家怎麼想?
>
> 原文的庫存位於[1],在@個郵件列表上相關的討論還有:
> * 用輸入法打字時 input.value 被更改的情形[2]
> * Google Japan 的輸入法 API[3] — 裡面文檔關於 IME 的介紹有圖,還蠻值得看的
>
> [1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0749
> [2] http://lists.w3.org/Archives/Public/public-html-ig-zh/2011Feb/0030
> [3] http://lists.w3.org/Archives/Public/public-html-ig-zh/2011Feb/0021
>
>
> Kenny
>
>
>
> -------- Original Message --------  Subject: Re: ISSUE-137 (IME-keypress):
> Should keypress events fire when using an IME? [DOM3 Events]  Resent-Date:
> Tue, 09 Aug 2011 08:58:20 +0000  Resent-From: public-webapps@w3.org  Date:
> Tue, 09 Aug 2011 17:57:22 +0900  From: Masayuki Nakano
> <masayuki@d-toybox.com> <masayuki@d-toybox.com>  To: Web Applications
> Working Group WG <public-webapps@w3.org> <public-webapps@w3.org>
>
> Hello.
>
> Currently, Firefox doesn't fire any key events (keydown, keyup and
> keypress) during IME composition.  There are some reasons:
>
> 1. Most firefox code handles key events without IME composition state
> check. (This is our internal reason, though) Therefore, if we would fire
> key events during composition, we would need to fix very many code.
>
> 2. Web application developers cannot check IME composition state
> directly.  If they needed to check it, they needed to listen
> compositionstart and compositionend events and make a bool variable.
> Therefore, if web developers handled key events without IME state check,
> IME users couldn't use some web applications.
>
> 3. Some web developers may not know well about IME behavior. Their web
> applications might break IME behavior by handling key events.
>
> I'd like to *suggest* that key events shouldn't be fired during IME
> composition, especially for #3.  If web developers want to know the
> timing of updating composition string, they can use compositionupdate or
> textinput. I think that these events are better for the purpose since
> IME composition string can be updated by clicking on candidate window,
> i.e., it doesn't cause key events.
>
> thanks,
>
> On 2010/10/06 15:16, Web Applications Working Group Issue Tracker wrote:
> >
> > ISSUE-137 (IME-keypress): Should keypress events fire when using an IME? [DOM3 Events]
> >
> > http://www.w3.org/2008/webapps/track/issues/137
> >
> > Raised by: Doug Schepers
> > On product: DOM3 Events
> >
> > Hallvord R. M. Steen<http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0176.html> <http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0176.html>:
> > [[
> > current spec text says about the keypress event:
> >
> >> This event type shall be generated after the keyboard mapping
> >> but before the processing of an input method editor, normally
> >> associated with the dispatching of a compositionstart, compositionupdate,
> >> or compositionend event.
> >
> > I think this is wrong, if an IME is actively processing the input no
> > keypress event should fire.
> > ]]
>
> --
> Masayuki Nakano <masayuki@d-toybox.com> <masayuki@d-toybox.com>
> Manager, Internationalization, Mozilla Japan.
>
>
>
Received on Friday, 12 August 2011 06:13:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:49 UTC