CSS3-UIの新ドラフトではime-modeプロパティが廃止に 115
ストーリー by hylom
CSSで制御すべきことじゃないわな 部門より
CSSで制御すべきことじゃないわな 部門より
あるAnonymous Coward 曰く、
CSS Basic User Interface Module Level 3 (CSS3 UI)（Working Draft 2015-02-24）で、「ime-mode」プロパティが廃止となった（「水底の血」ブログ、参考訳）。
ime-modeは、HTMLのinput要素でIMEの状態を設定するCSSプロパティ。IMEを使った日本語入力を禁止したり、入力時の初期状態を制御するといった用途を想定しているようだ。Internet Explorer 5.0の独自仕様として登場し、他のWebブラウザでも一部実装された。たとえばFirefoxでは多くの議論の結果、ベンダプレフィックスなし、デフォルトで有効として実装され、その上でWebデザイナに対しては一般のサイトで使用しないようにアナウンスし、IMEの状態を制御されたくないユーザーに対してはユーザスタイルシートによる上書きを案内した（MozillaのBugzilla、Mozilla Japanブログ）。
今回のドラフトでは、実装をできるだけ早く止めるべきとされた。仕様に関する議論の進行・結果やWebデザイナからの要求、そしてユーザースタイルシートを使用しない多くのユーザーの意見などを踏まえ、ブラウザベンダーは実装をどうするべきか判断を迫られることになるだろう。
IMEの制御 (スコア:2, すばらしい洞察)
なんだか「日本語を知らない人たちが勝手に決めた」みたいな話になってますけど、本当ですかね？
確か、そもそもIMEのオン／オフって、Windows限定の話だったと思います。
Mac OSXではオン／オフの概念がない（入力モードの切り替えでしかない）、Linuxではそもそも制御できない、みたいな話は見たことがあります。
Re: 入力モード (inputmode) について [w3.org](W3Cメーリングリスト、2010年)
そのうえ、近年ではタブレット機からの入力に、何らかの文字入力ソフトウェアを介在させざるを得ないわけで……。
（こっちは禁止されたらそもそも文字入力できなくなってしまう）
Windows上のソフトでも、最近はそうした非IMEの文字入力環境をひっくるめたText Services Frameworkに移行しつつありますから、「IMEのオン／オフ」みたいな単純な制御では解決できなくなってきているんじゃないかと。
活用例 (スコア:1)
俺はブラウザのロケーションバーのIMEを無効にするために使ってる。
どうか実装がなくなりませんように(-人-)
Re: (スコア:0)
私もFirefoxで使用しています。
#urlbar *|input {
ime-mode: inactive !important;
}
電話番号は半角で入力してください (スコア:1)
いちいち指定しているのにIME制御をしてなくて、
入力後に電話番号が間違っていますとかいってくる。
イラつく。
そっちで直せ！
Re: (スコア:0)
というか、サーバで数字やハイフンの全角/半角変換くらいいくらでも変換できようものなのに、なんでしないんでしょうね。
Re: (スコア:0)
前にどっかで見たフォームを何の疑問も持たずにコピーしているケースが多いと思う。
Re: (スコア:0)
住所表現とかに漢数字入れる人いるから、値妥当性検証がやっかいになる。壱とか参拾壱みたいな。
土地買ったとき、登記時だったかで「どういう表記にしますか」とか聞かれたし。
住所コードで管理して表記統一しろよと言いたい。
地名変更に対応できんだろうが。
Re: (スコア:0)
ならないだろ。
壱とか参拾壱とかは、今の全て全角を求めるやり方、半角を求めるやり方どちらでもチェックできないのだから。
登記時に、アラビア数字の全角半角を聞かれたのか？
HTML5のフォーム機能 (スコア:1)
例えばGoogle Chromeだと<input type="search">は自動的にIMEオンになるし、<input type="number">はオフになります。
それではダメなの？
ずるはやめましょう、なのか (スコア:0)
例えば、「日本語入力されたくなければちゃんと入力内容を見てエラーにしろ」ということなのか。
つい先だって仕事で使ってたのだがなぁ。
Re:ずるはやめましょう、なのか (スコア:1)
ドラフトですがHTML5.1で inputmode(キーボード種別の指定)という要素が入っています。
で英字入力になる予定です。
ブラウザに実装されるのはいつになるのやら。。。
Re: (スコア:0)
＜input type="text" inputmode="latin"＞ って半角で書いたら削除されちゃいました＞＜
Re:ずるはやめましょう、なのか (スコア:1)
日本だと両方で使うことの方が多いような。
「必ず全角で入れさせたいのでIMEをＯＮにする」
住所やなんかで。
「必ず半角で入れさせたいのでIMEをＯＦＦ強制にする」
電話番号なんかで。
どちらにしろ、サーバーサイドのチェックやサニタイズはいるけれどもさ。
IMEを普段使いしない（する必要のない半角文字圏）の人間がime絡みの仕様の要、不要を決めてほしくないなぁ。
Re:ずるはやめましょう、なのか (スコア:1)
意地でも半角カナでの入力を求める銀行のWebサービスとか、非常にややこしいというか気持ち悪い。
※ 個人的には全角英数字なんて消滅してほしいと思う
-- やさいはけんこうにいちば〜ん！
全角英数字などの正規化 (スコア:1)
オフトピだけど、いろいろな場面で全角英数字とか半角にそろえたいなぁッて思う時がある。
（そもそも全角半角という呼称がもう古いのだけど。）
そういうのって、Unicodeの正規化でやるのが王道なのかねぇ？
独自のマッピングとか作っても汎用性なさそうだし。
屍体メモ [windy.cx]
Re:全角英数字などの正規化 (スコア:2)
入力はIMEの機能で調整してるものの、各種の情報登録のサイトなどで
* 住所の番地などは全角英数字で
* 電話番号と郵便番号は半角英数字で
とか狂気の沙汰かよ、という気分です。正規化をそっちでやってよという気分になるんだよね…
-- やさいはけんこうにいちば〜ん！
Re: (スコア:0)
（そもそも全角半角という呼称がもう古いのだけど。）
Unicodeで、HalfwidthとFullwidthですよ。
http://www.unicode.org/charts/PDF/UFF00.pdf [unicode.org]
Re:全角英数字などの正規化 (スコア:1)
角がダメなら飛車があるじゃない。
屍体メモ [windy.cx]
Re:ずるはやめましょう、なのか (スコア:1)
「全角」と指定してあっても、タイ語やアラビア語も余裕で入るフォームが結構多い件について。
あれ、「全角」なん？
#Unicodeの世界では、漢字も「全角」じゃなくて、「FULLWIDTH-*」がついてるのだけが全角じゃないの？
Re: (スコア:0)
あれとIE、ATOKの相性がどこか悪くて、なぜかカナ入力モードに切り替わるページがいくつかあった。
いちいちメモ帳に入力したものをコピペすることになってめんどくさかった。
後に調べたら、ATOK側で制御を無視する設定が出来るというのがあっさり見つかったけど。
Re:ずるはやめましょう、なのか (スコア:2)
Internet Explorer 11 で ATOK 使用時、ime-mode: active 指定でカナ入力モードになる [microsoft.com]っていう、IE11のバグですね。
対応方法が、Webサイト側で「IE8 標準モード以下のドキュメント モード」に落とすか、利用者側でATOK側で制御されないように設定を変える [justsystems.com]か、どっちかしかないという…
ちゃんとIE11を直して欲しいなぁもう…
Re:ずるはやめましょう、なのか (スコア:1)
古いATOK(ATOK2011から、ATOK2013ぐらいまで?)が、TSF対応といいつつ対応が中途半端だったのは確かですが、
IE11問題については、マイクロソフト自ら「本現象は、Internet Explorer 11 が Conversion Mode のフラグ値を適切に保持できていないために発生します。 [microsoft.com]」と述べてるんですが…
それでもこの問題はATOK側のバグであるといえる根拠は何かあるのでしょうか?
Re: (スコア:0)
そういう用途なんだろうけど、「サニタイズ」しないと、SQLインジェクションの温床なんじゃなないの？
Re: (スコア:0)
ime-modeの有無がSQLインジェクションと何の関係があるんでしょう
Re: (スコア:0)
ime-modeの有無にかかわらずサーバサイドでの入力チェックはやっているでしょという意味では？
入力チェックしてエラーを返すのとサニタイズは別物ですが。
Re: (スコア:0)
CSSオフにされたりユーザスタイルシートで上書きされたら日本語入力できるわけだから、どの道入力内容は見なきゃダメなんじゃないかな。
Re: (スコア:0)
そもそも送られてくるものを無条件で信用するのは論外ですよね。
IME制御は困る (スコア:0)
ブラウザがIMEを制御するのはやめて欲しい
パスワード入力欄は (スコア:0)
いつでもIME強制オフになっているように思える。
これは問題ないのかな。
Re: (スコア:0)
確かにパスワード入力欄にはIME経由で入れてはならないってのも押しつけだとは思うな。
もちろんいろいろIMEが覚えちゃうので悪影響はあるんだけど、パスワードに仮名漢字使用可能にするだけで随分強度は増すという効果もある。
あと個人的にはコピペ禁止機能はごっそり削って欲しいな。特にペースト禁止formなんかが鬱陶しい限り。
Re: (スコア:0)
変換候補が画面に出れば横から見えてしまうし、見えなければ学習で誤変換になっても分からないし。
漢直でもない限り、かえって混乱の元のような気が。
Re: (スコア:0)
本当にパスワードは画面に表示されてはいけないのか？
というのは感情的なものを排してもう一度最初から考えるべきだと自分は思っている。
どうしても衆人環視の元でパスワードを入力するものはパスワードをマスク（し、英数記号を前提として）運用するべきかもしれないが、そうでないようなものも多数あるわけで、であれば強度と覚えやすさを鑑みるに日本語がパスワードに使えてもいいだろうと思うのだが。
Re:パスワード入力欄は (スコア:2)
> 本当にパスワードは画面に表示されてはいけないのか？
タッチタイプが出来ない上司に相談しに行った時に、上司がユーザー名の欄にパスワード丸出しで
入力してる時は横に居てかなり気まずい感じになったな…。
自分にあらぬ疑いを掛けられる可能性も無くはないから、絶対誰にも見られないっていう前提じゃないと
何かあったときに困るね。
Re: (スコア:0)
IEとかinput passwordは可視に出来るボタンあるでしょ
なかなか広まらないけど。
Re: (スコア:0)
> どうしても衆人環視の元でパスワードを入力するものはパスワードをマスク（し、英数記号を前提として）運用するべきかもしれないが、
> そうでないようなものも多数あるわけで、であれば強度と覚えやすさを鑑みるに日本語がパスワードに使えてもいいだろうと思うのだが。
前者のような場合が在り得る限り、初期状態ではマスクすべき。
だってwebサイト作る側は、殆どの場合それがどんな環境で利用されるか分からない。
電車の中でスマホからアクセスする場合もあるだろう。
今は社内からしかアクセスできないwebサイトが、
ある日出張者用に社外からアクセスできるようになるかも知れない。
マスクをするかしないかは、ユーザ側で選択するべきだと思う。
Re:パスワード入力欄は (スコア:1)
> 表示させた状態なら日本語も打てるだろうし、サーバー側はそのままハッシュ化するだけだろうから、マルチバイトパスワードできるかもね。
<input type="password"> でも、クリップボードからペーストすれば、マルチバイトのパスワードが入力できますよ。
その結果は「問題無くマルチバイトパスワードが使える」「入力可能文字種エラーで怒られる」「一見登録に成功するが、認証時にエラーになる」のどれかですが…最後のだけは勘弁してほしい。
ユーザービリティ (スコア:0)
業務アプリケーションなんかでは、入力項目に応じてＩＭＥの制御をすることは普通なので、
Ｗｅｂの入力フォームでＩＭＥの制御がされていないと手抜きだと感じることが多いです。
Re:ユーザービリティ (スコア:3, すばらしい洞察)
WEBでの入力は業務じゃないのでそんなに同じことを繰り返すわけじゃないから，
なるべく標準状態を保つ=余計なことをしないのがユーザビリティを考慮した結果だと思うんですが．
ブラウザなんてIME入れたり切ったりしまくるんだから，
しばらく入力してないとオンだかオフだかいちいち覚えてないんですよ．
で，ふと開いたページで電話番号入力したときにIMEオフになってたら
「あ，今IMEオフだな」
って思うでしょ．
んでタブキーで次の項目いって住所入れるときには，
IMEがオフになってること覚えてるんだから，
「IMEをオンにして・・・」
って半角全角キー押すでしょ．
そしたらIMEオフになるとか狂気の沙汰．
何度も同じフォームに入力を繰り返すことを前提としてるなら，そういう制御をしてしかるべきでしょうが，
それはユーザが何度も入力しながら学習するからであって，
一度しか入力しないユーザ登録画面などでそんなことをするのは想像力の欠如．
作ってる側は作りながら確認のため何度も入力するから便利なように感じてしまうかもしれないけど，
作る側の都合で使う側の気持ちを考えられないものづくりはだめ．
Re: (スコア:0)
単語登録で住所やメールアドレスを短縮入力してる人間にとっては余計なことすんなボケとしか思えん。
内部で半角と全角の変換もしてない手抜きアプリの都合に無理やり付き合わせることの何がユーザビリティなのか。
Re: (スコア:0)
思想というか仕様というか、web/htmlと業務アプリは相容れない部分が多いと思う。
解像度指定とか固定幅表示とか通信とか今回のIMEとか。
で、基盤側のweb側を無視するから変な実装、汎用性が失われるといったことになる。
道具の使い分けの判断に問題あると思うがね。
現実を知らない判断 (スコア:0)
世の中にはWebベースの業務システムっていうものがいっぱいある。
こういうシステムで、定型的な入力作業（たとえば何かの申し込み情報のデータエントリーとか）を最適化するのに、IME制御が有効な場合は多い。
例えば住所氏名を入力する場合、
郵便番号を入力→（TABで次の欄へ）→住所を入力→（TABで次の欄へ）→氏名を入力→（TABで次の欄へ）→電話番号を入力
っていうのを下手すると一日何100件も繰り返すことになる。こういう場合は、IME制御があるとないとでは入力効率がぜんぜん違う。
この判断は、実務をまったく分かっていない馬鹿エンジンニアが判断したとしか思えない。
Re: (スコア:0)
実務を分かっていないのは確かですが、
馬鹿ではないかと思われます。
IMM32やTSF、ibusなんか追っておくと、
やはりIMEはWebブラウザというよりOSレイヤーの機能に見えます。
なのでそこまで日本語入力に対しての制御を期待するのであれば、
始めから通常のアプリケーションとして開発するか、
Webブラウザのプラグインとして扱う方が設計として保守性が高いかと。
（某銀行では日本語入力の制御をActiveXで実装してましたし。）
Re: (スコア:0)
現状使い物になってる代物を代替案もなく使い物にならなくする規格立案は十分に馬鹿だと思うよ。
IME on/offってゆーより、コンピュータを使う上で入力モードを頻繁に変更する必要がある言語が
存在していて入力モード変更を補助してやる事で利便性が向上するのが明白であり、それが
すで実用化されているにも関わらず、それを規格盛り込めないって終わってるなーって感じだわ。
Re:現実を知らない判断 (スコア:1)
https://office.live.com/start/Excel.aspx [live.com]
みたいな使い方はずいぶん前からできるようになっていたと思います。
Firefoxで閲覧したのでMicrosoft Internet Explorerがサポートしていなかったらごめんなさい。
Re: (スコア:0)
そういうのをたまにしか使わないユーザーからすると、
郵便番号を入力→（TABで次の欄へ）→(日本語ONのつもり)→住所を入力したら英語→(BS)→(日本語ON)→住所を入力→…
となって面倒なのです。ユーザーを驚かせないというのがUIの基本です。
その一日何100件も入れる方が普通の使い方なら別ですが…
Re:現実を知らない判断 (スコア:1)
> →(日本語ONのつもり)→
こういう操作をする人はたぶん少数派。大多数の人は「IMEはオンにしっぱなし」。
アルファベットや数字を入力する所も、IMEオンの状態のままで入力。
で、「半角変換操作するのが面倒」という改善要望が来るんです
「IMEをいちいちオフにするのが面倒」という改善要望は来ない…
Re: (スコア:0)
> その一日何100件も入れる方が普通の使い方なら別ですが…
元コメは業務用途を想定しておられるようなので「一日何100件も入れる方が普通」の状況のお話でしょう。
別のコメントにあった次の言葉が私にはしっくりときます。
> 思想というか仕様というか、web/htmlと業務アプリは相容れない部分が多いと思う。
多様なプラットフォームへの迅速な対応と言うことで業務システムがWebアプリケーション化する流れは止まらないと思います。
標準から落とすにしてもベンダープリフィックスつけての実装は残して欲しい気がします。
Re: (スコア:0)
その一日何100件も入れる業務システムが既にいっぱい存在していて、日常的に使用されているという話をしてるのよ。
Re: (スコア:0)
そこまで大変なら、受け付けた後で自動変換すりゃええやん。
一般ユーザ向けについては、「ユーザ様がご入力された文字列に手を加えるなんてまかり成らん」という暗黙のルールがあるから無理でも、
仕事対仕事なら、「仕様です」で済む話やん。
Re:現実を知らない判断 (スコア:1)
douiukizyunndezidouhennkannsurunoyo?
という入力を、
どういう基準で自動変換するのよ？
ってサーバー側で変換するのって結構大変だと思います…。
勘違いされている方が多いですけど、入力を受け付けるプログラム側でのIME制御は「入力内容を制限する機能」ではなく「ユーザーの手間を減らす便利機能」なんですよ。
Web画面上でIME制御をしていたって、Webサーバー側のチェック機能はひとつも減らないんです。
ただ、定型的な入力処理を100回も200回も行うような入力画面（それがネイティブアプリであろうとWebアプリであろうと）ではユーザビリティが大きく向上する便利機能になるわけです。
コールセンターなどの対応時間の短縮を要求されるような現場などでも「全角／半角」の切り替えをユーザー側に委ねずシステム側で制御することが要求されたりもします（例えば、次々に来る問い合わせ内容を画面入力していくのに一々切り替えをしてられない、という感じ）。
逆に、（オレは）その画面は1度しか使わないんだから制御は不要だ、というユースケースもあるわけで、こちらの意見にも一理あるとは思うんです。
結局これはユーザーの好みの話であって、
a. IMEは全てプログラム側で適切に制御されることを望む人（非対応アプリも許さん！）
b. IME制御は完全にユーザー側にハンドリングさせるべきと考える人（アプリケーション側での制御は全て禁止だ！）
c. どっちでもいい（おそらく大多数）
という感じに分かれるとは思うんですが、現実には、非対応のアプリも存在するし、上記のようにアプリ側で制御したい現場もあるわけで、a. と b. を「OSレベル／プラットホームレベル」両立させることは難しいのではないかという気がします。
そうなると、全ての「非対応アプリ」を対応アプリにさせていくのは非現実的なので、b. の、制御されたくない側の人が利用できる機能として「アプリ側からの制御を無視する」という機能を、IMEそのものやプラットホーム側（OS／Webブラウザ）の機能として用意するのがベターなのではないかと考えますね。