問題タブ [reflow]

私は複雑な CSS にかなり慣れていないので、質問があります。ページの下部にフローティング要素を配置するページがあります。Bottom: 0、Position: Absolute を設定することでこれを行います。

ユーザーがブラウザのサイズを非常に小さいサイズに変更すると、この要素がページ上の他のコンテンツを覆い隠します。

理想的には、要素は通常のサイズでも大きいサイズでもブラウザーの下部にフロートし続けますが、ブラウザー ウィンドウを縮小しすぎると、ブラウザーはフロート要素をそれ以上移動する代わりにスクロールバーを強制します。

基本的に、ブラウザに伝えたいのは、ウィンドウがどんなに小さくても、ページを 800x600 より小さくレンダリングしないことです。

どのような種類のアクティビティがDOMを使用したWebページのリフローをトリガーしますか？

いろいろな見方があるようです。http://www.nczonline.net/blog/2009/02/03/speed-up-your-javascript-part-4/によると、それは起こります

• DOMノードを追加または削除するとき。
• スタイルを動的に適用する場合（element.style.width = "10px"など）。
• offsetWidth、clientHeight、または計算されたCSS値（DOM準拠のブラウザーのgetComputedStyle（）またはIEのcurrentStyleを介して）へのアクセスなど、計算する必要のある測定値を取得する場合。

ただし、http：//dev.opera.com/articles/view/efficient-javascript/？page = 3によると、測定を行うと、リフローアクションがすでにキューに入れられている場合にのみリフローがトリガーされます。

誰か他にアイデアはありますか？

DOM要素をページに挿入する関数を呼び出すフォームボタンを押すと、インポートされたjsファイルが再実行されます(ajxコールバック関数のexeへのシミュレーションで)。DOM の挿入により、サーバーからすべてのファイルを再要求するページの更新が発生します。

関数呼び出しに大きな問題はありません:

DOM 更新コードの TARGET DIV は次のとおりです。

このページにアラートを配置し、関数が新しい LI を挿入しようとした後 [奇妙なことに、LI が一瞬表示されてから消える] ページの更新がトリガーされ、ページのアラートが再実行されます。

// おそらく、このコンピューターでブラウザーに問題があるか、スクリプターに慣れていないだけで、// 問題が表示されない...コメントをお待ちしております。

ユーザーがファイルアップロードボックスを動的に追加できるページがあります。ボックスを追加すると、それらが含まれる div の高さが変わりますが、その下の div の特定の要素は同じ場所に留まるため、新しい DOM 要素と重なり始めます。

これは IE8、Firefox、Chrome で正しく動作します。IE7 に新しい DHTML でページをリフローさせるにはどうすればよいですか?

私が解決した最善の解決策はこれでした：

ただし、最大化されたウィンドウでは機能しません (ウィンドウが復元されます)。

を使用して DIV を動的に作成し、document.createElement内部テキストを追加して、その高さと幅を決定したいとします。offsetWidthDIV を DOM ツリーに追加する前は、やなどのプロパティoffsetHeightが 0 であることがわかりますが、これは想定どおりです。プログラムでツリーに追加されたら、それらのプロパティがすぐに「準備完了」になると期待できますか? それとも、再描画/リフローが遅れて後で発生する可能性がある環境はありますか?

答えは、「JavaScript インタープリターはシングルスレッドであり、appendChild によってトリガーされる再描画/リフロー イベントはそのスレッドの一部であり、次のステートメントに進む前に終了する」のようなものになると思いますが、誰かが私の理解を確認できますか?

このOpera の記事には、私が探しているものがたくさんありますが、それがどのように Opera 固有のものであるかは明確ではありません。いずれにせよ、アプリケーション開発者は、offsetWidth にアクセスするなどして測定を行うときに、必要な再描画/リフローが正しく行われると想定できるようです。

スクロールバーをJavascriptでアニメーション化すると、ブラウザーのリフローがトリガーされるのではないかと思います。

異なるブラウザ実装間で何か違いはありますか？

window.pageXOffset＆window.pageYOffset
document.documentElement.scrollLeft＆document.documentElement.scrollTop
document.body.scrollLeft＆document.body.scrollTop

ありがとう！

リフローとリペイントの違いが少しわかりません（違いがある場合）

リフローがさまざまなDOM要素の位置をシフトしているように見えます。ここで、リペイントは新しいオブジェクトをレンダリングしているだけです。たとえば、要素を削除するとリフローが発生し、色を変更すると再ペイントが発生します。

これは本当ですか？

ブラウザがCSSの解析/レンダリングをいつ終了したかを判断するDOMイベントまたはその他の方法があるかどうか、ベンチマークの目的で疑問に思っています。CSS セレクターを最適化しようとしていますが、描画/レンダリング/リフロー時間を測定する方法が必要です。

私が書いたアドオンのウェブページのドキュメント全体に対して重いDOM操作を行う必要があります。すべての操作で1回のリフローのみが発生するように、リフローを最小限に抑えたいと思います。body要素を削除し、操作を行ってから再度挿入することは、すべての<script>要素を再評価するため、オプションではありません。現在、操作前にボディの視認性を設定し'none'、操作後の表示値を復元しています。しかし、これがこれに対処するための最良の方法であるかどうかはわかりません。

もっと良い方法はありますか？もちろん、Firefox固有のコードである可能性もあります。結局のところ、それはFirefoxアドオンです。

2つのdiv要素があり、一方が他方をラップしています。次に、JavaScriptを使用して、実行時に外部divに境界線を追加します。どういうわけか、Webkitベースのブラウザは、外側の境界線が変更されたときにリフローを実行しません。最終結果は醜く見えます-内側のdivが外側をオーバーフローします。HTMLコードは次のとおりです。[divid= "outer] [div id = "inner" style = "border：solid blue; 高さ：50px; "] [/ div] [/ div]

イベントハンドラーも単純です：document.getElementById（ "outer"）。setAttribute（ "style"、 "border：solid green"）

これはとても些細なリフロー作業なので、これを見つけたときは信じられませんでした。それとも私は何かが足りませんでしたか？誰かが同様の問題に遭遇しましたか、回避策は何ですか？ありがとう。