+1、ずっとIBMの標準だと思ってた。TABで移動してENTERでフォームを送信するって。

IBMのグリーンスクリーンを使ったのはずいぶん前だけど、うちのアプリではタブでフィールド間を移動してた気がする。ただ、そのために予約されたファンクションキーもあったと思う。

それ、俺の記憶とも一致してる。タブを使うのは自然だったし、マウスを使うGUIアプリに行くとタブの順番が間違っててイライラした。特にVisual Basicのアプリでね。

ミッドレンジシステムについて気になるな。AS/400は使ったことないけど、「フィールドエグジット」キーが別にあるって知ってるよ。

そうだと思う。無数の動くパーツを持つ組織を管理するのと、ユーザーのために何かを迅速に作るのでは、全然違う懸念があるからね。

今、CAPSLOCKが「次の入力を選択する」ために使われて、TABが文字として使われる世界を想像してる。

もしかしたら、IBMのメインフレームや3270ターミナルエミュレーターと競合するからかな？

個人的には、フィールド変更にタブキーを使うのが好きじゃない。まず、これはDOSからの大きな変更だったから。DOSプログラムではEnterを使ってたし、Enterを押すことで片手で数値データを入力できたんだ。数字キーパッドにはEnterキーがあるから、左手は（紙の）ソースの上に置いたままで、右手でタイピングできた。みんなこれが早くなったんだよね（本当に早かった）。このパターンは今でもいくつかのプログラム（例えばExcel）に残ってる。多くの人（つまり、私の顧客）は、両手をキーボードに使うのが嫌だった。私たちのプログラムの多くは、Enter=タブのマッピングを許可してた。はっきりさせておくけど、重要なのはキーの「名前」じゃなくて、位置なんだ。キーの二重使用はただの厄介なことだよね。時々、キーはナビゲーターとして機能するけど、他の場合ではスペーサーとして機能する。馬鹿げてる。（Enterも同じ問題がある。）最良の解決策は（圧倒的に）キーボードにもう一つキーを追加することだったと思う。できれば数字キーパッドに。あの時代にはたくさんの新しいキーが追加されたから、振り返ると「進む」キーを追加すべきだったね。

私が解釈したのは、完全に「IBM」の理由はなかったってこと。つまり、「IBMの官僚の一人が介入して物事を止めてしまった」ということが、文化的な違いを浮き彫りにしていると読んだんだ。これはその違いについての投稿だからね。

ブラウザ内で動作するテキストエディタを設計するなら、タブキーの機能についてユーザーの期待を完全に壊さないといけないよね。この環境では、タブキーが果たすことができる二つの論理的で直感的な役割が対立してるから。エンターキーでも同じ問題が起こるし、今の時代、ctrl+crlfが改行を引き起こすのか、メッセージ送信になるのか、bare crlfやshift+crlfの動作がどうなるのか、みんな結構複雑なルールを持ってると思う。HNのエディタでは、shift+crlfとbare crlfが改行を作って、ctrl+crlfは何もしないんだけど、ctrl+crlfがフォームやメッセージの送信を引き起こすことも多いし、shift+crlfは生の改行を挿入することが多い（フォームの中でも）。bare crlfはどっちか一方をするかもしれないし、どっちもしないかもしれない！これが一般的なバインディングだけど、shift+crlfがフォーム送信を引き起こしたり、raw newline挿入にはctrl+crlfが必要だったりする例外も見たことある。こういうのは本当に面倒で、ユーザーにストレスを与える原因になるよね。長い間、MSFTのスタイルガイドはベストプラクティスの参考として重要視されてたけど、今の人たちには皮肉に感じられるかも。