[webkit-dev] Supporting css ime-mode property
ap at webkit.org
Tue Oct 5 09:27:36 PDT 2010
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.
2. Safari forces input method to an ASCII compatible one in password fields to match Mac OS X behavior, and people complained about that in the past. The Mac OS X behavior is reasonable in that there is a clear benefit in not letting hidden state affect invisible typing, but it's a pain when you can't log in because of that!
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.
Even these examples aren't obvious at all.
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.
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.
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.
> And I've never felt that there was platform-specific difference in whether or not IME should be enabled / disabled (I actively use Chinese & Japanese IMEs on Mac & Windows).
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?
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.
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?
- WBR, Alexey Proskuryakov
More information about the webkit-dev