[webkit-dev] Fwd: Supporting css ime-mode property

Ryosuke Niwa 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
> names.
>

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
> property.
>

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
other languages.

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...

- Rysouke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101005/ffc56678/attachment.html>


More information about the webkit-dev mailing list