16
私は、ユーザーのリサイズテキストエリアコントロールを提供したいと考えています。私はこれを行って、他の多くの実装を見てきましたが、私のすべての要件を満たすものを見つけることはできません。ページが（すなわちないQuirksモードで）標準準拠モードでレンダリングされているWindowsとOS X上究極のリサイズテキストエリアの検索
- のWindowsとFirefox 3のIE6、IE7、IE8で動作し、3.5：具体的に私はそれを制御したいです。
- 元に戻すバッファ/元に戻したスタックを混乱させません。これはIEの特に問題です。ノードの追加、ノードの削除、その他のDOM操作は入力バッファをリセットします。実装がこれらのテクニックに依存する場合、UNDOは標準のテキストエリアコントロールと同じように動作しません。私はthis noteを除き、このバグに関する多くの情報を見つけることができませんでした。 jQuery Auto Growing Pluginのような実装は、この問題を抱えています。IEの変更を元に戻し、これが標準のテキストエリアとどのように作用するかを比較してみてください。この問題を実証するexample pageをJSBinに追加しました。
- コントロールを超えることができない最大の高さです。
- コンテンツが削除されるときに適切に縮小します。
- キーを押したときに奇妙に揺れたり、奇妙に動作したりしません。例えばjQuery Auto Growing Textareaコントロールは、コントロールが初期サイズを超えて成長したときに、少なくともIE7で不思議な動作をします。
- コントロールで固定幅/モノスペースフォントを使用する必要はありません。
Facebookのステータス更新フィールドは、コンテンツの編集可能なdiv要素として実装されていますが、divを使用するとこのような要素の使用に関するいくつかの予約があります。
- 境界線を明示的にスタイルする必要があります。つまり、ネイティブテキスト領域とは異なる境界線になる可能性があります。
- コンテンツを実際のテキストエリアと同期させる必要があります（双方向でも可能でしょうか？）。
- テキストエリアの位置を基準にしてヒントやその他の要素を配置するときに複雑さが増します。
- この方法はFacebookのステータス更新のようなものですが、何百もの標準入力要素を含むフォームではうまくいくでしょうか？
上記で説明したのは、「究極のリサイズテキストエリア」を表しています。既存のアプローチの問題と認識しています。そのようなコントロールは存在しますか？そのようなコントロールを書くことは可能ですか？
"何百もの標準入力要素を含むフォームではどれくらいうまく機能しますか？"同じページにこれらのウーバーテキストエリアがたくさん使用されますか？ – Tom
潜在的に、はい。 Facebook（またはGoogle Docs）のものは、ページ上の1つのcontentEditable要素を扱う必要があるということだけです。これは明らかに20+を扱うよりはるかに簡単です。 –