W3C home > Mailing lists > Public > www-style@w3.org > February 2012

Re: [css3-ui] 'ime-mode' feedback

From: Masayuki Nakano <masayuki@d-toybox.com>
Date: Mon, 20 Feb 2012 13:02:36 +0900
Message-ID: <4F41C5DC.8050704@d-toybox.com>
To: "Kang-Hao (Kenny) Lu" <kennyluck@csail.mit.edu>
CC: WWW Style <www-style@w3.org>
Hi, I'm the person who implemented ime-mode on Gecko.

First of all, I think that the property should NOT be standardized by 
CSS3-UI. The reason is, it's really Windows specific behavior, it 
doesn't work well on Mac, Linux and mobile platforms.

Then, you must be unsure, why did I implement it? The answer is simple, 
it's for compatibility with IE, especially on some intranet applications 
of enterprise.

A lot of company had developed their own internal system by Window 
application in 90's. At that time, I heard some companies require 
changing IME state automatically when every editor gets focus.

So, I thought that if such companies want to move their system from 
Windows native applications to Web applications, and they don't want to 
change the usability, the IME state controlling feature is needed.

For such situation, I thought the property was needed for Firefox. 
Actually, after implementing it, I saw some blog posts by developers who 
are requested by such requirement from such clients.

On the other hand, I'm not sure whether ime-mode is required on such 
systems nowadays since I've been working on Mozilla for 7 years, so, I 
don't know the current trend of such systems.

Anyway, if www-style wants to make a standard for controlling input 
mode, we should make another property and better values. Currently, some 
web sites are using Flash Player only for controlling IME mode since it 
can do it. It's very disappointing fact for us.

On 2012/02/17 3:03, Kang-Hao (Kenny) Lu wrote:
>    # Applies to:	text fields
> In IE9, 'ime-mode' applies to elements with @contenteditable too
> although that's not the case for Firefox 10. I think this is a bug in
> Firefox.

No, it's intentional. When I tested it at implementing the property, IE 
(I forget the actual version number) did ignore the property on 
contenteditable editor and designMode editor.

I didn't realize that IE9 changed the behavior.

> The definition of "text fields", which would include elements with
> @contenteditable, is missing either here or in the HTML spec. I'll note
> that 'ime-mode' doesn't apply to all focusable elements[2] as defined in
> the HTML spec since neither IE9 nor Firefox 10 apply 'ime-mode' to
> <button>,<input type="checkbox">,<a>  or<span tabindex="1">  and the like.

Yes, e.g., if IME is enabled on such elements, space key cannot be 
usable while IME is turned on since space key events are consumed by IME.

>    # auto
>    # No change is made to the current input method editor state. This is
>    # the default.
>    #
>    # normal
>    # The IME state should be normal; this value can be used in a user
>    # style sheet to override the page setting.
> I couldn't make sense of the definitions of these two before I did the
> testing. Example 13 uses 'auto' instead of 'normal' in a user style
> sheet, which is even more confusing because that doesn't match what the
> definition explains. I think the right definitions are probably

It's made for a workaround of our product's historical issue. Before I 
implemented IME control management on Gecko, IME was always usable even 
if password field or non-text-ediable element has focus. However, after 
that, non-ASCII keyboard layouts became unusable while IME is disabled.

So, non-ASCII language users had been able to use non-ASCII languages' 
keyboard layout like Cyrillic, Arabic and Hebrew for password field. If 
they had used such characters for password in some web sites actually, 
the IME state controlling mechanism would have hurt their a11y.

So, the "normal" value is a workaround for such users. Fortunately, I 
have never heard it's actually used.

Masayuki Nakano <masayuki@d-toybox.com>
Manager, Internationalization, Mozilla Japan.
Received on Monday, 20 February 2012 04:03:09 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:11 UTC