[css3-ui] reconsidering ime-mode (Issue 40, and 35 39)

This is Issue 40 of css3-ui, with implications on issue 35 and 39:
https://wiki.csswg.org/spec/css3-ui#issue40
https://wiki.csswg.org/spec/css3-ui#issue35
https://wiki.csswg.org/spec/css3-ui#issue39

A few people have pushed back against standardizing/implementing ime-mode:
James Craig (Apple):         http://lists.w3.org/Archives/Public/www-style/2013May/0075.html
Masayuki Nakano (Mozilla):   http://lists.w3.org/Archives/Public/www-style/2012Feb/0959.html
Alexey Proskuryakov (Apple): https://bugs.webkit.org/show_bug.cgi?id=21279#c17

Kang-Hao Lu has also raised a number of issues, and hinted at the fact that we may not want to support this at all either:
http://lists.w3.org/Archives/Public/www-style/2012Feb/0759.html

I am inclined to agree that ime-mode should not be standardised. I believe it is overall a bad idea, and that a better alternative is already available.

First, note that I am not saying this as an English-centered person ignoring internationalisation. I regularly type in 3 (occasionally in 4) languages including CJK, and I am aware of the importance of well tuned IME use. It is the solution, not the use cases, that I am arguing against.

1)
One of the use cases put forward by the spec is example 12: "This example disables input method support for a field; this might be necessary for fields that enter data into a database that doesn’t support extended character sets, for example."

ime-mode is a poor way of solving this problem:
- It does not prevent copy-pasting arbitrary content
- Various keyboards can natively input "extended characters"
- The back-end code should do input validation anyway
- the front-end should display error messages when the content violates the validation rules

2)
There isn't a fundamental difference between an ime, the autocorrect feature of modern OSes, T9 input, and on screen keyboards of smartphones and tablets. In all cases, a series of user generated input events (key presses or screen touches) will be turned into the text that goes into the text field, with no guarantee that what the text field receives is character for character what the user typed.

Given that, what should ime-mode:disable do on a Japanese smartphone?
- Turn off Japanese input and display an US-ASCII keyboard instead, even though the interaction is essentially the same?
- Turn off text input altogether?
- Do nothing?

How about ime-mode:disable on an american smartphone?
- Disable autocorrect, swipe, and dictionary based suggestions, but otherwise keep the layout the same?
- Turn off text input altogether?
- Do nothing?

In my opinion, other than "do nothing", none of these are good answers. And if we go with "do nothing", why should the same ime-mode:disable prevent Japanese users on a computer, but not those on a phone, from typing Japanese.

3) ime-mode:active is not really appropriate either.
It does not work well in the case where authors would use it for something "please type your full name in Kanji", as it would activate the korean ime on a korea computer, activate nothing on a computer without ime, and would not prevent entry of arbitrary text in any language for example through copy-pasting anyway.

If it is used by the author to say "real text goes here, not passwords and such", it presumes that on computers where an ime is available, users always want to use it when typing text, which is definitely not true for multilingual users, and not even necessarily true of monolingual CJK users either, as it is occasionally desirable to type ascii text.

4) ime-mode is not cross platform and not interoperable. Values supported varie by browser and by OS.
IE/windows:      auto | active | inactive | disabled
Firefox/windows: auto | active | inactive | normal | disabled 
Firefox/linux:   auto                     | normal | disabled
Firefox/OS X:    auto | active | inactive | normal | disabled
Firefox/Android:                                   | disabled*

* on FF/android disabled is the only value which has any effect, and is different from what it means on other systems. If the active input system of the phone is Japanese, it switches to the latin letter submode (but does not prevent switching back to Japanese). If the active input system of the phone is english, it turns off autocapitalization of the first letter.

Note that is generally not possible to support on linux, as there isn't one but many ime-frameworks, and they typically don't let themselves be controlled. Also, the way IMEs work on OS X is fairly different from windows, and attempts at implementing ime-mode end up triggering different behaviour.

see comments by Alexey Proskuryakov in https://bugs.webkit.org/show_bug.cgi?id=21279 for further illustration of the points (1/2/3/4) above

5) The spec makes an attempt to limit the use of ime-mode to "web applications and the like" as opposed to "public web sites", but I don't such a categorisation would hold.

Using the HTML type attribute, together with the pattern attribute (when ime-mode would be used to attempt to restrict the input to a certain character subset) and/or with the inputmode attribute (when ime-mode would be used as a convenience to the user to preselect an appropriate input system), is a more universal, robust and extensible solution (I acknowledge that inputmode needs more work, the fundamental model is sound).

All in all, ime-mode is at its core a desktop only, windows centric feature targeted at monolingual CJK speakers. While arguably useful in some contexts if we didn't have anything else, I don't believe it is a good way forward for the web platform, and I'd rather have spec writers and implementers focus on the alternative highlighted above.

 - Florian

Received on Thursday, 4 December 2014 15:01:47 UTC