3

hasLayoutInternet Explorer の Web サイトで作業している多くの開発者と同様に、悪名高いフラグが原因である多くのバグに遭遇したようです。

このフラグが何をするのか、どのように機能するのか (ほとんどの場合) を理解しています。先日読んだ良い説明 (ソースは見つかりませんが) はhasLayout、IE では基本的に「この要素を四角形にする」という意味です。

それは明らかにそれよりも複雑ですが、それでかなりうまく要約されています (私の意見では)。

私が理解できないのは、ブラウザがこのフラグを使用する理由です。答えを探していたところ、論理的に聞こえるものを見つけました。

Internet Explorer は、CSS が本格的に普及する前の非常に古いレガシ コードを処理する必要がありました。ブラウザに CSS を簡単に追加できるようにするためのアーキテクチャ上の決定として、hasLayoutフラグを使用して特定の CSS プロパティをトリガーし、ページが正しくレンダリングされるようにしました。これは IE4 の頃にさかのぼります。

これは、Firefox (当時は Netscape) が同じ問題に対処しなければならないことに気付くまで、私にはほとんど意味がありました。Netscape は Internet Explorer とほぼ同じくらい長い間存在していますがhasLayout、私の知る限り、内部フラグなどは必要ありません。

このhasLayoutフラグが Internet Explorer の非常に多くのバグの原因であることを考えると、なぜ IE にこのフラグがあり、他のブラウザはそれを必要としないのか知っている人はいますか?

これは純粋に好奇心から知りたいことです。もし誰かが理論を持っているか、たまたま答えを知っているなら. このフラグが役立つ理由 (またはそうでない理由) について詳しく知りたいです。

4

2 に答える 2

11

Netscape レンダラーは、NS4 以降に完全に書き直されました。IE の "Trident" レンダリング エンジンは、それほど愛されていませんでした。これはビジネス上、非常に理にかなっています。IE は、NS が書き直されている間も段階的に改善を続け、部分的にはこれが原因で (そして部分的には配布の取り決めが原因で...) 市場の巨大なシェアを獲得することができました...

しかし、最終的には古くて粗悪なコードベースとなり、開発者にとっては地獄のようなものになり、開発者は実装の詳細を隠す必要があることを痛感しなければなりません。

ここで、最後の点が重要です。ブラウザーのレンダラーは抽象化されているため、数百行または数千行の低レベルのレンダリングおよびイベント処理コードを必要とするものを、数行のマークアップで作成できます。そして、すべてのプログラミングの抽象化と同様に、少しリークします... これは、IE、Netscape、Firefox、Opera、Webkit に当てはまります...そして、各ブラウザには、抽象化のリークをプラグインするために熱心に取り組んでいる開発者がいます。ただし、5 年間、IE はそうではありませんでした。他のリークは塞がれましたが、レンダリング エンジンはますますふるいのようになりました。

一緒に、これらの要因は共謀して次のようなものを公開しhasLayoutます。

于 2009-07-22T01:44:13.013 に答える
2

それらのソースコードを見ることができなければ、それを知ることは非常に困難です.

次のリンクは、これまでに見つけた中で最も有益なものです。

最初のものは、非常に興味深い文を含む時代遅れの文書を引用しています。

内部的には、レイアウトを持つということは、要素が独自のコンテンツを描画する責任があることを意味します。

そして二番目はこう言います。

Explorer 内のオブジェクト モデルは、ドキュメント モデルと従来のアプリケーション モデルのハイブリッドのようです。

両方をまとめると、 の要素hasLayoutは実際には Win32 API の意味でのウィンドウであると思います。つまり、物事がCreateWindow処理します。それ以外の要素にhasLayoutは独自の「ウィンドウ」はありませんが、hasLayout何らかのレイアウト コード (Qt のレイアウト クラスのようなもの) を使用して、最も近い - を持つ祖先によって描画されます。真の「ウィンドウ」だけがレイアウト コード (レイアウトのない子孫を描画する) を持っているため、それらは「レイアウトを持っている」ものhasLayoutです。

その場合、2 つの異なるコード パス レイアウト コードが存在することになります (1 つはhasLayout、「ウィンドウ」を配置して、後で通常のウィンドウ描画システムを使用して描画できるようにする必要があるため、もう 1 つは の子を描画します)。hasLayout「窓」を描きながら手で「窓」を描く）。すべてのコードにはバグがあるため (そして、IE<=6 には平均以上のバグがあるという逸話的な証拠がある)、両方のコード パスに異なるバグがあり、追加または削除hasLayout(事実上、他のコード パスに切り替える) によってバグのセットが変更される理由が説明されます。問題の要素。それだけでなく、同じドキュメント内で 2 つのコード パスが機能しているため、両方のコード パスの反復は、微妙なバグの別の豊富なソースになります。

他のブラウザは、このようなデュアル レイアウト パスを持たないアーキテクチャを使用するだけで、おそらく問題を回避できました。

私の推測が正しければ、ブラウザーが使用しているすべての子ウィンドウを表示するツールを使用した場合、表示されているすべてのhasLayout要素には子ウィンドウがあり、レイアウトのない要素には子ウィンドウがないことがわかります。

于 2009-07-22T02:55:54.437 に答える