[webkit-dev] Fwd: Supporting css ime-mode property
rniwa at webkit.org
Tue Oct 5 10:52:27 PDT 2010
---------- Forwarded message ----------
From: Ryosuke Niwa <ryosuke.niwa at gmail.com>
Date: Tue, Oct 5, 2010 at 10:45 AM
Subject: Re: [webkit-dev] Supporting css ime-mode property
To: Alexey Proskuryakov <ap at webkit.org>
Cc: Kenichi Ishibashi <bashi at google.com>, webkit-dev at lists.webkit.org
On Tue, Oct 5, 2010 at 9:27 AM, Alexey Proskuryakov <ap at webkit.org> wrote:
> 05.10.2010, в 02:29, Ryosuke Niwa написал(а):
> > I highly doubt that people will misuse ime-mode because whether or not
> IME should be active is usually obvious from the context (e.g. username &
> password, telephone number, etc...).
> 1. I sometimes use Cyrillic characters in user names, and I'm pretty sure
> that some people use CJK. There is no inherent problem with non-ASCII user
I don't think there are popular CJK websites that lets you use CJK
characters in usernames. If a website allows non-ASCII, then they can
choose not to use ime-mode property. But in either case, we need to let
websites make such decisions.
> 3. A phone number can contain letters, too ('P' for pause, or part of the
> number encoded as numbers, e.g. 1-800-COMCAST). In any case, there is <input
> type=tel> for us to implement the best platform specific behavior.
We never use Japanese letters in phone numbers, or at least I've never seen
one in my life. But you're right that the website should be using type=tel
in such cases.
Another example that might seem obvious to a Web designer is numeric input.
> People who only use English and Chinese or Japanese usually aren't aware of
> the fact that punctuation characters can be at different locations on a
> non-U.S. keyboard layout. These layouts are also often different between Mac
> and PC. So, if you force a particular keyboard layout in some input fields,
> users will be inconvenienced by switching to a different location for '.'
> and ',' at your whim.
I was never aware that turning on/off IME changes the keyboard layout but I
can't think of a good usage of ime-mode: inactive / disabled in CJK where
users need to type in those special characters.
Another example was given in bug 21279, and that was URL fields. Whatever
> the best input method behavior for these could be (one can argue that we
> should switch to an ASCII capable input source by default, but let the user
> change it later), we should deduce it from input type=url, not from a CSS
I agree. In general, whenever we have an input type for it, ime-mode isn't
so useful or that it shouldn't be used.
So far, the only accurate use case that I've seen was developing a UI for a
> back-end that doesn't support non-ASCII characters in some fields. I don't
> think we should extend the Web platform just to support apps that aren't
> i18n-aware. And anyway, you can always paste into any field, so css-mode
> doesn't protect you from getting non-ASCII characters in these fields.
+1 to Tony's response.
I wasn't even talking about Mac vs. Windows. When you specify "ime-mode:
> disabled", do you also want to disable T9 on phones? Or to somehow affect
> what iPhone does?
What I'd expect to happen in iPhone is to switch CJK input pad or any other
languages's IME to English input pad but I think this can be considered as
an implementation detail. In general, ime-mode property is probably only
useful in CJK websites. If website is targeted towards global users, then
it can not to use ime-mode. If website is big enough that it is localized
for different languages, it can use ime-mode only in CJK and do no harm in
But there are indeed dramatic differences in actual behavior between Mac and
> Windows. In IE, "ime-mode: disabled" disables input methods, while in
> Firefox on Mac, it disables non-ASCII capable input sources. The patch
> proposed for WebKit implements the latter. You can't meaningfully use that
> in a cross-platform manner.
The latter makes sense at least for CJK.
Please also consider that there are 3rd party input methods for English,
> Russian and other languages on Mac, even if there aren't on Windows. Why
> would you ever want to disable an English input method, and force the user
> to use a plain keyboard?
I agree that it doesn't makes any sense to disable English input method.
Nonetheless, this feature is useful for things like credit card number,
postal code, age, etc...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev