アカウント名:
パスワード:
世の中にはWebベースの業務システムっていうものがいっぱいある。こういうシステムで、定型的な入力作業（たとえば何かの申し込み情報のデータエントリーとか）を最適化するのに、IME制御が有効な場合は多い。
例えば住所氏名を入力する場合、
郵便番号を入力→（TABで次の欄へ）→住所を入力→（TABで次の欄へ）→氏名を入力→（TABで次の欄へ）→電話番号を入力
っていうのを下手すると一日何100件も繰り返すことになる。こういう場合は、IME制御があるとないとでは入力効率がぜんぜん違う。
この判断は、実務をまったく分かっていない馬鹿エンジンニアが判断したとしか思えない。
実務を分かっていないのは確かですが、馬鹿ではないかと思われます。
IMM32やTSF、ibusなんか追っておくと、やはりIMEはWebブラウザというよりOSレイヤーの機能に見えます。
なのでそこまで日本語入力に対しての制御を期待するのであれば、始めから通常のアプリケーションとして開発するか、Webブラウザのプラグインとして扱う方が設計として保守性が高いかと。（某銀行では日本語入力の制御をActiveXで実装してましたし。）
現状使い物になってる代物を代替案もなく使い物にならなくする規格立案は十分に馬鹿だと思うよ。IME on/offってゆーより、コンピュータを使う上で入力モードを頻繁に変更する必要がある言語が存在していて入力モード変更を補助してやる事で利便性が向上するのが明白であり、それがすで実用化されているにも関わらず、それを規格盛り込めないって終わってるなーって感じだわ。
excelやaccess、flashやacrobatなどでもできますよ。代替案はいっぱいあります。
excelがiEの上で動くようになったんですか？
https://office.live.com/start/Excel.aspx [live.com]みたいな使い方はずいぶん前からできるようになっていたと思います。Firefoxで閲覧したのでMicrosoft Internet Explorerがサポートしていなかったらごめんなさい。
Excelがオンラインサービスとして動くからといって、その上でアプリケーションを展開せよというのは十分に傲慢だと思います。それに、Excelがオンラインサービスで動いてもIMを制御する手段がなければWeb上のオフィススイートもIMを制御不能になりますよね。
オンラインで使いたかったらaccessなりflashなり.netなりなんなり、適切なものを使いましょう。
なのでそこまで日本語入力に対しての制御を期待するのであれば、始めから通常のアプリケーションとして開発するか、Webブラウザのプラグインとして扱う方が設計として保守性が高いかと。
そういうのをたまにしか使わないユーザーからすると、
郵便番号を入力→（TABで次の欄へ）→(日本語ONのつもり)→住所を入力したら英語→(BS)→(日本語ON)→住所を入力→…
となって面倒なのです。ユーザーを驚かせないというのがUIの基本です。その一日何100件も入れる方が普通の使い方なら別ですが…
> →(日本語ONのつもり)→
こういう操作をする人はたぶん少数派。大多数の人は「IMEはオンにしっぱなし」。アルファベットや数字を入力する所も、IMEオンの状態のままで入力。
で、「半角変換操作するのが面倒」という改善要望が来るんです「IMEをいちいちオフにするのが面倒」という改善要望は来ない…
それ、マカーだけや
> その一日何100件も入れる方が普通の使い方なら別ですが…元コメは業務用途を想定しておられるようなので「一日何100件も入れる方が普通」の状況のお話でしょう。
別のコメントにあった次の言葉が私にはしっくりときます。> 思想というか仕様というか、web/htmlと業務アプリは相容れない部分が多いと思う。
多様なプラットフォームへの迅速な対応と言うことで業務システムがWebアプリケーション化する流れは止まらないと思います。標準から落とすにしてもベンダープリフィックスつけての実装は残して欲しい気がします。
その一日何100件も入れる業務システムが既にいっぱい存在していて、日常的に使用されているという話をしてるのよ。
その業務システムの作りが悪いだけに聞こえる。業務システムならOSもブラウザもIMEもほぼ固定か事前に想定できるどれかだけだろう。常にIMEオンを想定して、全角数字を半角に自動変換すればいいだけじゃん。
自動変換したとしても、タブキーで次の入力欄に移る前にエンターキーを押して確定する必要があるので、その分効率が下がります。そのため、ime-modeは標準仕様にする必要があるのです。実装しないブラウザーベンダーは馬鹿です。
1, 2, いっぱい みたいなくくり？いっぱいっつっても、一般のwebアプリケーションの数と比べたら少数派でしょう。たとえ一万件そんな使用例があったとしても、世の中のwebサイトはさらに数百倍はある。そんな少数派のために気遣って標準を作るなんていうのはそもそも頭おかしい。
いやいや、利用者は一般のwebアプリケーションの方が多いけど、システム数だと業務システムの方が多いんだよ。業務システムはその業種や会社に特化して作成されるから、表に出てないだけで膨大に存在してるのよ。
そんな業務が現実に存在しているというのが恐怖だ
そこまで大変なら、受け付けた後で自動変換すりゃええやん。一般ユーザ向けについては、「ユーザ様がご入力された文字列に手を加えるなんてまかり成らん」という暗黙のルールがあるから無理でも、仕事対仕事なら、「仕様です」で済む話やん。
受け付けた後で自動変換すりゃええやん。
douiukizyunndezidouhennkannsurunoyo?という入力を、どういう基準で自動変換するのよ？
ってサーバー側で変換するのって結構大変だと思います…。
勘違いされている方が多いですけど、入力を受け付けるプログラム側でのIME制御は「入力内容を制限する機能」ではなく「ユーザーの手間を減らす便利機能」なんですよ。Web画面上でIME制御をしていたって、Webサーバー側のチェック機能はひとつも減らないんです。ただ、定型的な入力処理を100回も200回も行うような入力画面（それがネイティブアプリであろうとWebアプリであろうと）ではユーザビリティが大きく向上する便利機能になるわけです。コールセンターなどの対応時間の短縮を要求されるような現場などでも「全角／半角」の切り替えをユーザー側に委ねずシステム側で制御することが要求されたりもします（例えば、次々に来る問い合わせ内容を画面入力していくのに一々切り替えをしてられない、という感じ）。
逆に、（オレは）その画面は1度しか使わないんだから制御は不要だ、というユースケースもあるわけで、こちらの意見にも一理あるとは思うんです。結局これはユーザーの好みの話であって、
a. IMEは全てプログラム側で適切に制御されることを望む人（非対応アプリも許さん！） b. IME制御は完全にユーザー側にハンドリングさせるべきと考える人（アプリケーション側での制御は全て禁止だ！） c. どっちでもいい（おそらく大多数）
という感じに分かれるとは思うんですが、現実には、非対応のアプリも存在するし、上記のようにアプリ側で制御したい現場もあるわけで、a. と b. を「OSレベル／プラットホームレベル」両立させることは難しいのではないかという気がします。そうなると、全ての「非対応アプリ」を対応アプリにさせていくのは非現実的なので、b. の、制御されたくない側の人が利用できる機能として「アプリ側からの制御を無視する」という機能を、IMEそのものやプラットホーム側（OS／Webブラウザ）の機能として用意するのがベターなのではないかと考えますね。
まあ、私もそこが本質的には落としどころだろうと思います。馬鹿かどうかは置いておくとしても、現実問題として現実の問題の解決策が提示されないのは問題だと思うし。W3Cに意見を送れば解決するとも思われない。こういうものが出てくる時点で違う文化を無理やり展開しているように思える。
えーと、そもそも、アクセシビリティの話なんだと思うよ。
IMEの定義が「アルファベット→漢字」変換な人には言っても無駄だけど、タッチパッドで仮想キーボードがせりあがってくるのもIMEの一種なんだから、IMEを禁止するとアルファベットすら打てなくなって、入力フォームそのものが死んでしまう。音声入力だってIMEだし、もう、ウェブサイトにアクセスしてくる機器に必ずキーボードがついているという幻想は捨てなければいけない。ただし、入力装置自体が何もないというところまでは想定しなくてもよいから、IMEの制限は余計なお世話ってことなんだろう。
だから、やるとすれば、input要素のtype属性の値に"ascii"を追加して、asciiをどうやって入力するかはIMEが決めればいい。
君がばかなことはよくわかったのでもう書き込みしないでほしい
サーバー側でIME呼び出して、候補に対して学習ベースで評価値を得てソートすればいいだけでは...どちらかというとそのほうがサーバー側で変換精度をカスタムできるし、より優れていそう。
まあ学習アルゴリズムとか書いたことがなければ仕方ないかもね。まともにCSやってないってことだし。
>> 受け付けた後で自動変換すりゃええやん。>douiukizyunndezidouhennkannsurunoyo?>という入力を、>どういう基準で自動変換するのよ？
同じローマ字文字列や、同じひらがな文字列で区切り位置が違うので別の文字列に変換されるのなんていくらでもあるわけで。
どうやってそこを”入力者の意図にそって正しく区切るの？”（今はＩＭＥを矢印などで操作してるわけだが）「橋を架ける（はしをかけるーhasiwokakeru）」と「橋を駆ける（はしをかけるーhasiwokakeru）」とかサーバーサイドでどうするつもり？
日本語理解してないでしょ、あなた。
さらに英字の「hasiwokakeru」のままが正解な場合もありえますからね。サーバ側でどうにか出来る問題じゃないです。
実はタイプミスで二つ目は 「端を駆ける」を入れるつもりだったり。
「花と鼻をなんとなく使い分ける」なんてのも、花が先か、鼻がさきか。 「なんとなく」か「何となく」か「何と無く」か。
鼻と花が同音意義、なんとなくが区切りの問題。どうやってサーバーサイドでやるのやら。
変換候補返すだけでも、文字列の長さによっちゃ数十から数百いきますね、数百のリストから選べとでもいうのかね？
住所はまぁデータベース引っ張れば一発で収束しますが、氏名とかどこに収束するんでしょうね？元コメを引用したのは評価しますけど、そんなに全力で私は哀れな馬鹿です宣言しないでください。笑っちゃった自分が言うのもなんですが、ギャグとしてもそれはどうかと思います。
学習したところで、一番使われてるのが正解とは限らないんだから、サーバーサイドで決めようがないって話なんだがな。
「ほんとに日本語理解してないんだね」「バカは自分がバカと理解できないって本トだね」
>douiukizyunndezidouhennkannsurunoyo?>という入力を、>どういう基準で自動変換するのよ？
なんでそっちに寄せるのよ。仕事中は、IMEはONのままにしとけ、と社内教育して、
どういう基準で自動変換するのよ？＃２７６８６５４
の2行目を、#2768654に自動変換すりゃええやん。
まあ、個人的に、何も考えていない善意のお節介に迷惑をかけられることを極端に忌避する原理主義に偏ってるんだけど。許してしまうと、昔のWindowsの、「電源を切る/再起動ダイアログ」の「開いたときのデフォルトが前回押したボタン」仕様とか、(電源は毎晩切るけど、再起動は滅多にや
単純にime-mode自体は実装して、指定されてなければ制御なし、指定されていればそれなりに制御するというので十分ではないかな？
それとも、スマートフォンの影響かなあ。スマートフォンでなんかを前提に、タッチパネルの仮想キーボードとIMEを同一視するなら、文字入力時に必ず使うのだから、ime-modeなんか実装する必要がないという割り切りなのかなあ。
もっとも、VBベースの業務アプリでできていたＩＭＥ制御と同じレベルのものを要求されて困ったことは何回もある。
Web”ブラウザ”なので、見るのが主体の道具がaの尻拭いをするのもどうかと思いますがね。Excel方眼紙ほどでは無いにしても、やりきれないなぁ。。
> この判断は、実務をまったく分かっていない馬鹿エンジンニアが判断したとしか思えない。そこまでIMEの制御が重要なアプリケーションをWebアプリとして作るエンジニアの方が馬鹿だよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
現実を知らない判断 (スコア:0)
世の中にはWebベースの業務システムっていうものがいっぱいある。
こういうシステムで、定型的な入力作業（たとえば何かの申し込み情報のデータエントリーとか）を最適化するのに、IME制御が有効な場合は多い。
例えば住所氏名を入力する場合、
郵便番号を入力→（TABで次の欄へ）→住所を入力→（TABで次の欄へ）→氏名を入力→（TABで次の欄へ）→電話番号を入力
っていうのを下手すると一日何100件も繰り返すことになる。こういう場合は、IME制御があるとないとでは入力効率がぜんぜん違う。
この判断は、実務をまったく分かっていない馬鹿エンジンニアが判断したとしか思えない。
Re: (スコア:0)
実務を分かっていないのは確かですが、
馬鹿ではないかと思われます。
IMM32やTSF、ibusなんか追っておくと、
やはりIMEはWebブラウザというよりOSレイヤーの機能に見えます。
なのでそこまで日本語入力に対しての制御を期待するのであれば、
始めから通常のアプリケーションとして開発するか、
Webブラウザのプラグインとして扱う方が設計として保守性が高いかと。
（某銀行では日本語入力の制御をActiveXで実装してましたし。）
Re: (スコア:0)
現状使い物になってる代物を代替案もなく使い物にならなくする規格立案は十分に馬鹿だと思うよ。
IME on/offってゆーより、コンピュータを使う上で入力モードを頻繁に変更する必要がある言語が
存在していて入力モード変更を補助してやる事で利便性が向上するのが明白であり、それが
すで実用化されているにも関わらず、それを規格盛り込めないって終わってるなーって感じだわ。
Re: (スコア:0)
excelやaccess、flashやacrobatなどでもできますよ。
代替案はいっぱいあります。
Re: (スコア:0)
excelがiEの上で動くようになったんですか？
Re:現実を知らない判断 (スコア:1)
https://office.live.com/start/Excel.aspx [live.com]
みたいな使い方はずいぶん前からできるようになっていたと思います。
Firefoxで閲覧したのでMicrosoft Internet Explorerがサポートしていなかったらごめんなさい。
Re: (スコア:0)
Excelがオンラインサービスとして動くからといって、その上でアプリケーションを展開せよというのは十分に傲慢だと思います。それに、Excelがオンラインサービスで動いてもIMを制御する手段がなければWeb上のオフィススイートもIMを制御不能になりますよね。
Re: (スコア:0)
オンラインで使いたかったらaccessなりflashなり.netなりなんなり、適切なものを使いましょう。
なのでそこまで日本語入力に対しての制御を期待するのであれば、
始めから通常のアプリケーションとして開発するか、
Webブラウザのプラグインとして扱う方が設計として保守性が高いかと。
Re: (スコア:0)
そういうのをたまにしか使わないユーザーからすると、
郵便番号を入力→（TABで次の欄へ）→(日本語ONのつもり)→住所を入力したら英語→(BS)→(日本語ON)→住所を入力→…
となって面倒なのです。ユーザーを驚かせないというのがUIの基本です。
その一日何100件も入れる方が普通の使い方なら別ですが…
Re:現実を知らない判断 (スコア:1)
> →(日本語ONのつもり)→
こういう操作をする人はたぶん少数派。大多数の人は「IMEはオンにしっぱなし」。
アルファベットや数字を入力する所も、IMEオンの状態のままで入力。
で、「半角変換操作するのが面倒」という改善要望が来るんです
「IMEをいちいちオフにするのが面倒」という改善要望は来ない…
Re: (スコア:0)
それ、マカーだけや
Re: (スコア:0)
> その一日何100件も入れる方が普通の使い方なら別ですが…
元コメは業務用途を想定しておられるようなので「一日何100件も入れる方が普通」の状況のお話でしょう。
別のコメントにあった次の言葉が私にはしっくりときます。
> 思想というか仕様というか、web/htmlと業務アプリは相容れない部分が多いと思う。
多様なプラットフォームへの迅速な対応と言うことで業務システムがWebアプリケーション化する流れは止まらないと思います。
標準から落とすにしてもベンダープリフィックスつけての実装は残して欲しい気がします。
Re: (スコア:0)
その一日何100件も入れる業務システムが既にいっぱい存在していて、日常的に使用されているという話をしてるのよ。
Re: (スコア:0)
その業務システムの作りが悪いだけに聞こえる。
業務システムならOSもブラウザもIMEもほぼ固定か事前に想定できるどれかだけだろう。
常にIMEオンを想定して、全角数字を半角に自動変換すればいいだけじゃん。
Re: (スコア:0)
自動変換したとしても、タブキーで次の入力欄に移る前にエンターキーを押して確定する必要があるので、その分効率が下がります。
そのため、ime-modeは標準仕様にする必要があるのです。実装しないブラウザーベンダーは馬鹿です。
Re: (スコア:0)
1, 2, いっぱい みたいなくくり？
いっぱいっつっても、一般のwebアプリケーションの数と比べたら少数派でしょう。
たとえ一万件そんな使用例があったとしても、世の中のwebサイトはさらに数百倍はある。
そんな少数派のために気遣って標準を作るなんていうのはそもそも頭おかしい。
Re: (スコア:0)
いやいや、利用者は一般のwebアプリケーションの方が多いけど、システム数だと業務システムの方が多いんだよ。
業務システムはその業種や会社に特化して作成されるから、表に出てないだけで膨大に存在してるのよ。
Re: (スコア:0)
そんな業務が現実に存在しているというのが恐怖だ
Re: (スコア:0)
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ブラウザ）の機能として用意するのがベターなのではないかと考えますね。
Re: (スコア:0)
まあ、私もそこが本質的には落としどころだろうと思います。
馬鹿かどうかは置いておくとしても、現実問題として現実の問題の解決策が提示されないのは問題だと思うし。
W3Cに意見を送れば解決するとも思われない。
こういうものが出てくる時点で違う文化を無理やり展開しているように思える。
Re: (スコア:0)
えーと、そもそも、アクセシビリティの話なんだと思うよ。
IMEの定義が「アルファベット→漢字」変換な人には言っても無駄だけど、タッチパッドで仮想キーボードがせりあがってくるのもIMEの一種なんだから、IMEを禁止するとアルファベットすら打てなくなって、入力フォームそのものが死んでしまう。音声入力だってIMEだし、もう、ウェブサイトにアクセスしてくる機器に必ずキーボードがついているという幻想は捨てなければいけない。ただし、入力装置自体が何もないというところまでは想定しなくてもよいから、IMEの制限は余計なお世話ってことなんだろう。
だから、やるとすれば、input要素のtype属性の値に"ascii"を追加して、asciiをどうやって入力するかはIMEが決めればいい。
Re: (スコア:0)
君がばかなことはよくわかったのでもう書き込みしないでほしい
Re: (スコア:0)
サーバー側でIME呼び出して、
候補に対して学習ベースで評価値を得てソートすればいいだけでは...
どちらかというとそのほうがサーバー側で変換精度をカスタムできるし、より優れていそう。
まあ学習アルゴリズムとか書いたことがなければ仕方ないかもね。まともにCSやってないってことだし。
>> 受け付けた後で自動変換すりゃええやん。
>douiukizyunndezidouhennkannsurunoyo?
>という入力を、
>どういう基準で自動変換するのよ？
Re: (スコア:0)
同じローマ字文字列や、同じひらがな文字列で区切り位置が違うので別の文字列に変換されるのなんていくらでもあるわけで。
どうやってそこを”入力者の意図にそって正しく区切るの？”（今はＩＭＥを矢印などで操作してるわけだが）
「橋を架ける（はしをかけるーhasiwokakeru）」と「橋を駆ける（はしをかけるーhasiwokakeru）」とか
サーバーサイドでどうするつもり？
日本語理解してないでしょ、あなた。
Re: (スコア:0)
さらに英字の「hasiwokakeru」のままが正解な場合もありえますからね。
サーバ側でどうにか出来る問題じゃないです。
Re: (スコア:0)
実はタイプミスで二つ目は 「端を駆ける」を入れるつもりだったり。
「花と鼻をなんとなく使い分ける」
なんてのも、花が先か、鼻がさきか。 「なんとなく」か「何となく」か「何と無く」か。
鼻と花が同音意義、なんとなくが区切りの問題。どうやってサーバーサイドでやるのやら。
変換候補返すだけでも、文字列の長さによっちゃ数十から数百いきますね、
数百のリストから選べとでもいうのかね？
Re: (スコア:0)
そちらはそもそもの問題設定を正しく理解できてないんですから哀れですなあ。
> 郵便番号を入力→（TABで次の欄へ）→住所を入力→（TABで次の欄へ）→氏名を入力→（TABで次の欄へ）→電話番号を入力
特殊用途で、さらにおそらく大量の人間が継続的に使うんだから、
機械学習の収束速度は一般の入力を想定しないといけないIMEよりも簡単なのは当然でしょう。
サーバー側でカスタムとはそういうこと。
住所入力用の欄ならば 「どういう基準で自動変換するのよ？」「はしをかける」 なんて入力を想定する必要はな
Re: (スコア:0)
住所はまぁデータベース引っ張れば一発で収束しますが、氏名とかどこに収束するんでしょうね？
元コメを引用したのは評価しますけど、そんなに全力で私は哀れな馬鹿です宣言しないでください。
笑っちゃった自分が言うのもなんですが、ギャグとしてもそれはどうかと思います。
Re: (スコア:0)
学習したところで、一番使われてるのが正解とは限らないんだから、サーバーサイドで決めようがない
って話なんだがな。
「ほんとに日本語理解してないんだね」「バカは自分がバカと理解できないって本トだね」
Re: (スコア:0)
>douiukizyunndezidouhennkannsurunoyo?
>という入力を、
>どういう基準で自動変換するのよ？
なんでそっちに寄せるのよ。仕事中は、IMEはONのままにしとけ、と社内教育して、
どういう基準で自動変換するのよ？
＃２７６８６５４
の2行目を、#2768654に自動変換すりゃええやん。
まあ、個人的に、何も考えていない善意のお節介に迷惑をかけられることを極端に忌避する原理主義に偏ってるんだけど。
許してしまうと、昔のWindowsの、「電源を切る/再起動ダイアログ」の「開いたときのデフォルトが前回押したボタン」仕様とか、
(電源は毎晩切るけど、再起動は滅多にや
Re: (スコア:0)
単純にime-mode自体は実装して、指定されてなければ制御なし、指定されていればそれなりに制御するというので十分ではないかな？
それとも、スマートフォンの影響かなあ。スマートフォンでなんかを前提に、タッチパネルの仮想キーボードとIMEを同一視するなら、文字入力時に必ず使うのだから、ime-modeなんか実装する必要がないという割り切りなのかなあ。
もっとも、VBベースの業務アプリでできていたＩＭＥ制御と同じレベルのものを要求されて困ったことは何回もある。
Re: (スコア:0)
Web”ブラウザ”なので、見るのが主体の道具がaの尻拭いをするのもどうかと思いますがね。
Excel方眼紙ほどでは無いにしても、やりきれないなぁ。。
Re: (スコア:0)
> この判断は、実務をまったく分かっていない馬鹿エンジンニアが判断したとしか思えない。
そこまでIMEの制御が重要なアプリケーションをWebアプリとして作るエンジニアの方が馬鹿だよ。