CSSの解析原理
2563 ワード
1、HTMLは解析を経てDOM Treeを生成する(これはよく知られている).CSS解析が完了すると、解析の結果をDOM Treeの内容とともに分析してRender Treeを作成し、最終的に図面を描くために使用する必要があります.Render Treeの要素(WebKitでは「renderers」、Firefoxでは「frames」)はDOM要素に対応していますが、一つ一つ対応していません.1つのDOM要素は複数のrendererに対応する可能性があります.テキストが折れると、異なる「行」はrender tree種の異なるrendererになります.ディスプレイ:noneのようなDOM要素はRender Treeに完全に無視されているものもあります.
2、Render Treeを作成するとき(WebKitの「Attachment」プロセス)、ブラウザはDOM Treeの要素ごとにCSSの解析結果(Style Rules)に基づいてどのようなrendererを生成するかを決定します.各DOM要素については、すべてのStyle Rulesで該当するselectorを見つけ、対応するルールをマージする必要があります.セレクタの「解析」は実際にここで実行され,DOM Treeを巡る際にStyle Rulesから対応するselectorを探す.
3、すべてのスタイルルールは数が多い可能性があり、現在のDOM要素にほとんど一致しない(数が多いためルールインデックスツリーが一般的に確立される)ため、「このselectorは現在の要素に一致しない」と判断する迅速な方法が極めて重要である.
4、順方向解析、例えば「div div pem」であれば、まず現在の要素からhtmlまでのパス全体をチェックし、最上位のdivを見つけてから探し、不一致に遭遇したら最上位のdivに戻らなければならない.次にセレクタの最初のdivにマッチングし、何度か遡ってマッチングの有無を確定し、効率が低い.
5、逆マッチングは異なり、現在のDOM要素がselectorの最後のemではなくdivである場合、一歩で排除できます.親ノードの検証は、一致する場合にのみ継続的に検索されます.
6、しかし、マッチングの場合は不マッチングの場合よりはるかに低いため、逆マッチングがもたらす優位性は大きい.また、セレクタの最後に「*」を付けると、このような利点が大幅に低下することがわかります.これは、多くの最適化原則が、セレクタの最後にワイルドカードを追加することをできるだけ避ける理由です.
簡単に言えば、ブラウザが右から左に検索するメリットは、関係のないスタイルルールや要素をできるだけ早くフィルタリングすることです.
CSSセレクタ
左から右に検索すると、次のようになります.
1、すべてのdivノードを先に見つける
2、最初のdivノード内にすべてのサブdivが見つかり、class="Aaron"である
3、それからもう一度p spanをマッチングする.red等の場合
4、一致しない場合は、最初に検索したdivまたはpノードに遡って、次のノードを検索し、このようなプロセスを繰り返す必要があります.このような探索プロセスは,マッチングが少ないノードのみをマッチングするセレクタにとって,マッチングが規則的でないノードを遡及するのに多くの時間を費やしたため,効率が極めて低い.
考えを変えれば,最初にターゲットノードに最も適合する集合をフィルタリングし,この集合で検索を行うことで,検索空間を大幅に低減する.
右から左にセレクタを解析します.
1、まずはの要素を探します.Firefoxはこの検索方式をkey selector(キーワードクエリー)と呼び、キーワードとはスタイルルールの最後(右端)のルールであり、上のkeyはspanである.red.
2、次に、これらのノードの元兄弟ノードがpというルールに合致しているかどうかを判断すると、集合の要素が減少し、現在のサブルールに合致してこそ、前のサブルールに一致する.
3、DOMツリーがどのような構造であるかを知るには、1つの要素にはいくつかのサブ要素がある可能性があります.もしそれぞれが明らかに性能が悪いと判断したら.サブエレメントは親エレメントが1つしかないので、探しやすいです.CSSのセレクタの設計を見ると、完全にサブエレメントから親エレメントを探すのを最適化するために決定されます.
4、例えばp spanを打つ.showing、1つのp要素の下からすべてのspan要素を見つけてclass showingが速いかどうかを判断しますか?それともすべてのspan要素を見つけてclass showingがあるかどうかを判断し、p親要素を含むのが速いと思いますか?
だからブラウザがCSSを解析するエンジンはこのようなアルゴリズムを使います.
2、Render Treeを作成するとき(WebKitの「Attachment」プロセス)、ブラウザはDOM Treeの要素ごとにCSSの解析結果(Style Rules)に基づいてどのようなrendererを生成するかを決定します.各DOM要素については、すべてのStyle Rulesで該当するselectorを見つけ、対応するルールをマージする必要があります.セレクタの「解析」は実際にここで実行され,DOM Treeを巡る際にStyle Rulesから対応するselectorを探す.
3、すべてのスタイルルールは数が多い可能性があり、現在のDOM要素にほとんど一致しない(数が多いためルールインデックスツリーが一般的に確立される)ため、「このselectorは現在の要素に一致しない」と判断する迅速な方法が極めて重要である.
4、順方向解析、例えば「div div pem」であれば、まず現在の要素からhtmlまでのパス全体をチェックし、最上位のdivを見つけてから探し、不一致に遭遇したら最上位のdivに戻らなければならない.次にセレクタの最初のdivにマッチングし、何度か遡ってマッチングの有無を確定し、効率が低い.
5、逆マッチングは異なり、現在のDOM要素がselectorの最後のemではなくdivである場合、一歩で排除できます.親ノードの検証は、一致する場合にのみ継続的に検索されます.
6、しかし、マッチングの場合は不マッチングの場合よりはるかに低いため、逆マッチングがもたらす優位性は大きい.また、セレクタの最後に「*」を付けると、このような利点が大幅に低下することがわかります.これは、多くの最適化原則が、セレクタの最後にワイルドカードを追加することをできるだけ避ける理由です.
簡単に言えば、ブラウザが右から左に検索するメリットは、関係のないスタイルルールや要素をできるだけ早くフィルタリングすることです.
<div>
<div class="Aaron">
<p><span>s1</span></p>
<p><span>s2</span></p>
<p><span>s3</span></p>
<p><span class='red'>s4</span></p>
</div>
</div>CSSセレクタ
div > div.Aaron p span.red{
color:red;
}左から右に検索すると、次のようになります.
1、すべてのdivノードを先に見つける
2、最初のdivノード内にすべてのサブdivが見つかり、class="Aaron"である
3、それからもう一度p spanをマッチングする.red等の場合
4、一致しない場合は、最初に検索したdivまたはpノードに遡って、次のノードを検索し、このようなプロセスを繰り返す必要があります.このような探索プロセスは,マッチングが少ないノードのみをマッチングするセレクタにとって,マッチングが規則的でないノードを遡及するのに多くの時間を費やしたため,効率が極めて低い.
考えを変えれば,最初にターゲットノードに最も適合する集合をフィルタリングし,この集合で検索を行うことで,検索空間を大幅に低減する.
右から左にセレクタを解析します.
1、まずはの要素を探します.Firefoxはこの検索方式をkey selector(キーワードクエリー)と呼び、キーワードとはスタイルルールの最後(右端)のルールであり、上のkeyはspanである.red.
2、次に、これらのノードの元兄弟ノードがpというルールに合致しているかどうかを判断すると、集合の要素が減少し、現在のサブルールに合致してこそ、前のサブルールに一致する.
3、DOMツリーがどのような構造であるかを知るには、1つの要素にはいくつかのサブ要素がある可能性があります.もしそれぞれが明らかに性能が悪いと判断したら.サブエレメントは親エレメントが1つしかないので、探しやすいです.CSSのセレクタの設計を見ると、完全にサブエレメントから親エレメントを探すのを最適化するために決定されます.
4、例えばp spanを打つ.showing、1つのp要素の下からすべてのspan要素を見つけてclass showingが速いかどうかを判断しますか?それともすべてのspan要素を見つけてclass showingがあるかどうかを判断し、p親要素を含むのが速いと思いますか?
だからブラウザがCSSを解析するエンジンはこのようなアルゴリズムを使います.