フィールド成長の道

少し金曜日の楽しみ。

入力フィールドTextareaは 、何もしないときに沈黙しているため、実際に成長を望んでいます。 入力テキストの量がそのサイズを超えると、デザイナーやレイアウトデザイナーはその秘密の欲求を常に聞いているとは限りません。 ユーザーの指先に耳を傾けると、マウスのスクロールがうっとうしいほど動きます。



入力フィールドのサイズがほぼ満足のいくものである場合、それを忘れることがあります。 5つのうち3つのブラウザには、サイズ変更のための場所さえあります。レイアウトデザイナーは、上からの指示に驚いて、時々切断します( textarea {resize:none} )。 ユーザーの生活を困難にする他の方法があります。 そして、彼は去り、スクリプトとスタイルを取り上げます。



入力フィールドを増やすには、モデレートが必要になる場合があります。 たとえば、ウィンドウまたはページレイアウトの論理ブロックの高さの80%に達した場合。 この極端な場合にも注意が必要ですが、多くの場合、最初の問題が発生します-フィールドは小さいです。



物語

有名なニュースサイトX(名前が変更され、偶然の一致はランダムです)では、入力フィールドの変動は政治と同じくらい厳しく抑制されています。 抑制は多面的で、まるで彼らがバリケードの反対側で、クリープが簡単な手段でそれを修正するのを困難にしようとしたかのようです。



入力フィールドの高さは6〜7行でしたが、フィールドの高さが変わらない理由について誰も考えませんでした。 しかし、Safari、そしてChromeは、悪い例を設定しました-彼らは、ユーザーが引っ張ってコメントに多くのテキストを入力し始めることができるコーナーを手に入れました。 生活を悪化させるために何かをする必要がありました。そうすれば、これらの群衆は必要な場所をクリックし、そうすべきではない場所には書きません。 最後のストローは約1年前のFirefoxでした。 入力フィールドのサイズを変更し始めたとき、彼は緊急に何かをする必要がありました。 そして、 サイズ変更について覚えていました:none



質問と回答に3つの入力行を設定することから始め、すぐにサイズ変更を禁止しました(サイズ変更:なし)。 しかし、ユーザーは、 サイズ変更ごとに使い古されているわけではありません。 設計者は 、入力フィールドを使用しユーザーを完全に勝利するという気持ちはありませんでした。



そして、文字セクションでテストされた発見(レイアウトデザイナー-デザイナーはそれについても夢見ていませんでした)がありました。

textarea {height: 120px!important};
      
      





-ブラボー! -ビッグボスをレイアウトデザイナーに言った-よくやった、兄弟、助けて! 今、彼らは120ピクセル以内で私たちと踊ります! 今では、スタイルだけで入力フィールドを角の周りにドラッグして、好きなだけサイズを変更することはできません。 今、彼らは6行で手紙を書き、3行でいつものように答えようとします。 400ピクセルもかかる記事を書かない方法を示します。 (なぜ800ではなく、一般に入力フィールドの自動増加がないのですか?SEOがこれを説明します。)



そして、ユーザーはスクリプトを取り上げました。 彼ら自身はカットしたくなく、一般的に平和な人々でした。 しかし、私はしなければなりませんでした。 スタイルを備えたスクリプトの小さな魔法-そしてフィールドは再び手動でサイズ変更され始めました。 しかし、これは十分ではないようでした。 さて、闘争への渇望と勝利の味に酔ったユーザーの欲望に、著者は再び迫りました。



Autostoreは、ブラウザによっても提供されない入力フィールドのプロパティです(そうでなければ、なぜプログラマが必要なのでしょうか?)。 通常のブロックにテキストを追加すると、その境界線はスクリプトなしで高さ(下)に拡大します。 入力フィールドにはこれはありません。 入力フィールドの成長を支援するのはスクリプト松葉杖だけであり、この成長がブロック要素(たとえばDIVタグなど)が本来持っているピクセルに対して理想的で、クロスブラウザで、正確であることを確認できるのは非常にエレガントです。 確かに、高さの自動減少を提供する必要がなく、自動増加のみを提供する必要がある場合、問題は大幅に軽減されます。



実装

HabrAjaxスクリプトは 、テキストコンテンツが大きくなるにつれて入力フィールドを自動的に増やす機能で補完されました。 自動縮小は意識的に行われませんでした。右下隅を超えて移動することで入力フィールドの高さを手動で調整できるためです(そのような機能はありませんが、自動縮小があるOperaを除く)。



理論的には、フィールドの限られた範囲を見るのではなく、1行のスタイルで不便が解決される場合は20行のスクリプトを書くのではなく、これを長時間実行したかったのです。 そのため、1.5〜2年でスタイルとハンドのサイズを変更しました。 したがって、現在の追加は20行ではなく、約7行であり、残りは他の効果のために切り刻まれています-最大高さとスクロールが不要な場合のDOMの現実。 (コードは、ユーザースクリプトの正確なコピーではなく、読み取りに適合しています。)

 var dQ = function(q){return document.querySelector(q);}; var win = typeof unsafeWindow !='undefined'? unsafeWindow: window; var tAGrow = function(tA){ //- if(!tA) return; var tSHPrev =0, tAInh, tATout maxH = Math.floor(win.innerHeight *0.8), tAF = function(ev){ if(tSHPrev < maxH && tAInh) clearTimeout(tATout), tA.style.overflow ='hidden', tAInh =0; var tSH = tA.scrollHeight - (isChrome?6:!isFx?win.opera?2:6:0); //  if(win.opera){ //   tA.blur(); tA.style.height = 0; tA.style.marginBottom = tSH +'px'; tSH = tA.scrollHeight -2; tA.style.height = tSH +'px'; tA.style.marginBottom = 0; tA.focus(); } if(tSHPrev <= tSH && tSHPrev < maxH){ tA.style.height = tSH +'px'; if(tSHPrev < maxH && tAInh) clearTimeout(tATout), tA.style.overflow ='hidden', tAInh =0; }else if(!tAInh) clearTimeout(tATout), tATout = setTimeout(function(){tA.style.overflow ='inherit'; tAInh =1}, 230); tSHPrev = tSH; }; tA.addEventListener('keypress',tAF,!1); //     tA.addEventListener('keyup',tAF,!1); tA.style.resize ='vertical'; //   (Fx, Chrome, Safari) tA.style.maxHeight = maxH +'px'; }; tAGrow(dQ('.editor #comment_text')||dQ('.editor #answer_text')||dQ('.editor #text_textarea') ); tAGrow(dQ('.editor #text') );
      
      





Firefox / Chrome / Safariで正しいテキストの高さを取得するために入力フィールドを非表示の場所に複製しない場合、入力フィールドの高さの減少のみではなく増加のみに気付くことが知られています。 入力フィールドを縮小する必要はほとんどありません。これは、角をドラッグすることで実行できます。 したがって、ソリューションは可能な限り怠laですが、おそらく非常に便利です。 いずれの場合でも、変更または無効にすることができます。



実用面では、最大限の単純さの原則を遵守するために困難に陥りたくありませんでした。 そのため、手動フィールドのサイズ変更に関する問題分析を瞑想するときに、啓発が減少し、autostatのタオが学習されました。



Habrajaxユーザースクリプトバージョン 0.87以降をインストールすることで、作者のアクションを実際に見てサイトで使用できます



autostat機能は、他のスクリプト機能の保存中は無効になっています-設定で。 デフォルトはオンです。 Fx、Chromeでテストされましたが、他の2つのブラウザーは動作するはずです。Operaでは、角を引っ張る必要なしに高さを下げる必要があります(そのような可能性はありません)。 多くの異なるウェブサイトのレイアウトのため、文字の入力の開始時にフィールドの高さに小さな不快なジャンプがあるかもしれませんが、これはスタイルによって少し後で決定されます。 成長の他の副作用が生じる可能性があります-すべてが実際の作業でテストされます。



UPD 02:00:Operaでチェック済み-まだ高さを自動的に下げていませんが、これは次のアップデートで決定されます。 Operaはしばらくの間(たとえば、11.62で観測されました)、scrollHeightを使用するIEを除く他のすべてのユーザーと同じように動作しました-現在、テキストの高さはわかりません!



UPD 06:00:-バージョン0.872-スクリプトの最小負荷としてOperaの自動縮小テキストエリアを挿入しました。 habrahabr.ru/post/132872で説明されている方法で作成されます 。 スクリプトやDOMを読み込むため、ちらつき効果などが発生する可能性があるため、他のブラウザーでは自動縮小が有効になっいません (ちなみに、HabrAjax Quotation Correctorで実装されている2 textareaメソッドを使用して自動縮小を実行することをお勧めします)コンテキストコメントを入力するための幅と高さ)。



Safari 5.1.4 Win + NinjaKitでチェックされます-大きな重大なバグがあります-スペースを入力しない、Enter、設定やその他の欠点を保存しないため、まだお勧めできません。 一般的に、NinjaKitはこのスクリプトをサポートするのに十分ではなく、最適なソリューションは、少数のユーザー(2〜3人の可能性がある)のために不当な個別のアドオンです。



All Articles