<a >轉(zhuǎn)載說明</a>

一、介紹

瀏覽器可以被認為是使用最廣泛的軟件，本文將介紹瀏覽器的工作原理，我們將看到，從你在地址欄輸入google.com到你看到google主頁過程中都發(fā)生了什么。

將討論的瀏覽器

今天，有五種主流瀏覽器——IE、Firefox、Safari、Chrome及Opera。
　　本文將基于一些開源瀏覽器的例子——Firefox、Chrome及Safari，Safari是部分開源的。
　　根據(jù)W3C（World Wide Web Consortium萬維網(wǎng)聯(lián)盟）的瀏覽器統(tǒng)計數(shù)據(jù)，當前（2011年5月），F(xiàn)irefox、Safari及Chrome的市場占有率綜合已接近60％。（原文為2009年10月，數(shù)據(jù)沒有太大變化）因此，可以說開源瀏覽器已經(jīng)占據(jù)了瀏覽器市場的半壁江山。

瀏覽器的主要功能

瀏覽器的主要功能是將用戶選擇的web資源呈現(xiàn)出來，它需要從服務器請求資源，并將其顯示在瀏覽器窗口中，資源的格式通常是HTML，也包括PDF、image及其他格式。用戶用URI（Uniform Resource Identifier統(tǒng)一資源標識符）來指定所請求資源的位置，在網(wǎng)絡一章有更多討論。
　　HTML和CSS規(guī)范中規(guī)定了瀏覽器解釋html文檔的方式，由W3C組織對這些規(guī)范進行維護，W3C是負責制定web標準的組織。
　　HTML規(guī)范的最新版本是HTML4(http://www.w3.org/TR/html401/)，HTML5還在制定中（譯注：兩年前），最新的CSS規(guī)范版本是2（http://www.w3.org/TR/CSS2），CSS3也還正在制定中（譯注：同樣兩年前）。
　　這些年來，瀏覽器廠商紛紛開發(fā)自己的擴展，對規(guī)范的遵循并不完善，這為web開發(fā)者帶來了嚴重的兼容性問題。
　　但是，瀏覽器的用戶界面則差不多，常見的用戶界面元素包括：
<li>用來輸入URI的地址欄</li>
<li>前進、后退按鈕</li>
<li>書簽選項</li>
<li>用于刷新及暫停當前加載文檔的刷新、暫停按鈕</li>
<li>用于到達主頁的主頁按鈕</li>
　　奇怪的是，并沒有哪個正式公布的規(guī)范對用戶界面做出規(guī)定，這些是多年來各瀏覽器廠商之間相互模仿和不斷改進的結果。
　　HTML5并沒有規(guī)定瀏覽器必須具有的UI元素，但列出了一些常用元素，包括地址欄、狀態(tài)欄及工具欄。還有一些瀏覽器有自己專有的功能，比如Firefox的下載管理。更多相關內(nèi)容將在后面討論用戶界面時介紹。

瀏覽器的主要構成（High Level Structure）

瀏覽器的主要組件包括：
　　1. 用戶界面 － 包括地址欄、后退/前進按鈕、書簽目錄等，也就是你所看到的除了用來顯示你所請求頁面的主窗口之外的其他部分。
　　2. 瀏覽器引擎 － 用來查詢及操作渲染引擎的接口。
　　3. 渲染引擎 － 用來顯示請求的內(nèi)容，例如，如果請求內(nèi)容為html，它負責解析html及css，并將解析后的結果顯示出來。
　　4. 網(wǎng)絡 － 用來完成網(wǎng)絡調(diào)用，例如http請求，它具有平臺無關的接口，可以在不同平臺上工作。
　　5. UI后端 － 用來繪制類似組合選擇框及對話框等基本組件，具有不特定于某個平臺的通用接口，底層使用操作系統(tǒng)的用戶接口。
　　6. JS解釋器 － 用來解釋執(zhí)行JS代碼。
　　7. 數(shù)據(jù)存儲 － 屬于持久層，瀏覽器需要在硬盤中保存類似cookie的各種數(shù)據(jù)，HTML5定義了web database技術，這是一種輕量級完整的客戶端存儲技術

瀏覽器主要組件

　　需要注意的是，不同于大部分瀏覽器，Chrome為每個Tab分配了各自的渲染引擎實例，每個Tab就是一個獨立的進程。
　　對于構成瀏覽器的這些組件，后面會逐一詳細討論。

二、渲染引擎（The rendering engine）

渲染引擎的職責就是渲染，即在瀏覽器窗口中顯示所請求的內(nèi)容。
　　默認情況下，渲染引擎可以顯示html、xml文檔及圖片，它也可以借助插件（一種瀏覽器擴展）顯示其他類型數(shù)據(jù)，例如使用PDF閱讀器插件，可以顯示PDF格式。

渲染引擎簡介

本文所討論的瀏覽器——Firefox、Chrome和Safari是基于兩種渲染引擎構建的，F(xiàn)irefox使用Geoko——Mozilla自主研發(fā)的渲染引擎，Safari和Chrome都使用webkit。
　　Webkit是一款開源渲染引擎，它本來是為Linux平臺研發(fā)的，后來由Apple移植到Mac及Windows上，相關內(nèi)容請參考http://webkit.org。

渲染主流程（The main flow）

渲染引擎首先通過網(wǎng)絡獲得所請求文檔的內(nèi)容，通常以8K分塊的方式完成。
　　下面是渲染引擎在取得內(nèi)容之后的基本流程：
　　解析html以構建dom樹 -> 構建render樹 -> 布局render樹 -> 繪制render樹

圖2:渲染引擎基本流程

　　渲染引擎開始解析html，并將標簽轉(zhuǎn)化為內(nèi)容樹中的dom節(jié)點。接著，它解析外部CSS文件及style標簽中的樣式信息。這些樣式信息以及html中的可見性指令將被用來構建另一棵樹——render樹。
　　Render樹由一些包含有顏色和大小等屬性的矩形組成，它們將被按照正確的順序顯示到屏幕上。
　　Render樹構建好了之后，將會執(zhí)行布局過程，它將確定每個節(jié)點在屏幕上的確切坐標。再下一步就是繪制，即遍歷render樹，并使用UI后端層繪制每個節(jié)點。
　　值得注意的是，這個過程是逐步完成的，為了更好的用戶體驗，渲染引擎將會盡可能早的將內(nèi)容呈現(xiàn)到屏幕上，并不會等到所有的html都解析完成之后再去構建和布局render樹。它是解析完一部分內(nèi)容就顯示一部分內(nèi)容，同時，可能還在通過網(wǎng)絡下載其余內(nèi)容。

圖3:webkit主流程

圖4：Mozilla的Geoko渲染引擎主流程

　　從圖3和4中可以看出，盡管webkit和Gecko使用的術語稍有不同，他們的主要流程基本相同。Gecko稱可見的格式化元素組成的樹為frame樹，每個元素都是一個frame，webkit則使用render樹這個名詞來命名由渲染對象組成的樹。Webkit中元素的定位稱為布局，而Gecko中稱為回流。Webkit稱利用dom節(jié)點及樣式信息去構建render樹的過程為attachment，Gecko在html和dom樹之間附加了一層，這層稱為內(nèi)容接收器，相當制造dom元素的工廠。下面將討論流程中的各個階段。

三、解析與DOM樹構建（Parsing and DOM tree construction）

解析（Parsing－general）
　　既然解析是渲染引擎中一個非常重要的過程，我們將稍微深入的研究它。首先簡要介紹一下解析。
　　解析一個文檔即將其轉(zhuǎn)換為具有一定意義的結構——編碼可以理解和使用的東西。解析的結果通常是表達文檔結構的節(jié)點樹，稱為解析樹或語法樹。
　　例如，解析“2＋3－1”這個表達式，可能返回這樣一棵樹。

圖5：數(shù)學表達式樹節(jié)點

圖5：數(shù)學表達式樹節(jié)點
　　文法（Grammars）
　　解析基于文檔依據(jù)的語法規(guī)則——文檔的語言或格式。每種可被解析的格式必須具有由詞匯及語法規(guī)則組成的特定的文法，稱為上下文無關文法。人類語言不具有這一特性，因此不能被一般的解析技術所解析。
　　解析器－詞法分析器（Parser－Lexer combination）
　　解析可以分為兩個子過程——語法分析及詞法分析
　　詞法分析就是將輸入分解為符號，符號是語言的詞匯表——基本有效單元的集合。對于人類語言來說，它相當于我們字典中出現(xiàn)的所有單詞。
　　語法分析指對語言應用語法規(guī)則。
　　解析器一般將工作分配給兩個組件——詞法分析器（有時也叫分詞器）負責將輸入分解為合法的符號，解析器則根據(jù)語言的語法規(guī)則分析文檔結構，從而構建解析樹，詞法分析器知道怎么跳過空白和換行之類的無關字符。

圖6：從源文檔到解析樹

圖7：編譯流程

圖7：編譯流程
　　解析實例Parsing example
　　圖5中，我們從一個數(shù)學表達式構建了一個解析樹，這里定義一個簡單的數(shù)學語言來看下解析過程。
　　詞匯表：我們的語言包括整數(shù)、加號及減號。

語法：

1. 該語言的語法基本單元包括表達式、term及操作符
　　2. 該語言可以包括多個表達式
　　3. 一個表達式定義為兩個term通過一個操作符連接
　　4. 操作符可以是加號或減號
　　5. term可以是一個整數(shù)或一個表達式

現(xiàn)在來分析一下“2＋3－1”這個輸入
　　第一個匹配規(guī)則的子字符串是“2”，根據(jù)規(guī)則5，它是一個term，第二個匹配的是“2+3”，它符合第2條規(guī)則——一個操作符連接兩個term，下一次匹配發(fā)生在輸入的結束處。“2+3-1”是一個表達式，因為我們已經(jīng)知道“2+3”是一個term，所以我們有了一個term緊跟著一個操作符及另一個term。“2++”將不會匹配任何規(guī)則，因此是一個無效輸入。
　　詞匯表及語法的定義
　　詞匯表通常利用正則表達式來定義。
　　例如上面的語言可以定義為：

INTEGER：0｜［1－9］［0－9］＊
　　PLUS：+
　　MINUS：－

正如看到的，這里用正則表達式定義整數(shù)。
　　語法通常用BNF格式定義，我們的語言可以定義為：

expression :＝ term operation term
　　operation := PLUS | MINUS
　　term := INTEGER | expression

如果一個語言的文法是上下文無關的，則它可以用正則解析器來解析。對上下文無關文法的一個直觀的定義是，該文法可以用BNF來完整的表達。可查看http://en.wikipedia.org/wiki/Context-free_grammar。

解析器類型（Types of parsers）

有兩種基本的解析器——自頂向下解析及自底向上解析。比較直觀的解釋是，自頂向下解析，查看語法的最高層結構并試著匹配其中一個；自底向上解析則從輸入開始，逐步將其轉(zhuǎn)換為語法規(guī)則，從底層規(guī)則開始直到匹配高層規(guī)則。
　　來看一下這兩種解析器如何解析上面的例子：
　　自頂向下解析器從最高層規(guī)則開始——它先識別出“2+3“，將其視為一個表達式，然后識別出”2+3-1“為一個表達式（識別表達式的過程中匹配了其他規(guī)則，但出發(fā)點是最高層規(guī)則）。
　　自底向上解析會掃描輸入直到匹配了一條規(guī)則，然后用該規(guī)則取代匹配的輸入，直到解析完所有輸入。部分匹配的表達式被放置在解析堆棧中。

自底向上解析器稱為shift reduce解析器，因為輸入向右移動（想象一個指針首先指向輸入開始處，并向右移動），并逐漸簡化為語法規(guī)則。

自動化解析（Generating parsers automatically）

解析器生成器這個工具可以自動生成解析器，只需要指定語言的文法——詞匯表及語法規(guī)則，它就可以生成一個解析器。創(chuàng)建一個解析器需要對解析有深入的理解，而且手動的創(chuàng)建一個由較好性能的解析器并不容易，所以解析生成器很有用。Webkit使用兩個知名的解析生成器——用于創(chuàng)建語法分析器的Flex及創(chuàng)建解析器的Bison（你可能接觸過Lex和Yacc）。Flex的輸入是一個包含了符號定義的正則表達式，Bison的輸入是用BNF格式表示的語法規(guī)則。
　　HTML解析器（HTML Parser）
　　HTML解析器的工作是將html標識解析為解析樹。

HTML文法定義（The HTML grammar definition）

W3C組織制定規(guī)范定義了HTML的詞匯表和語法。

非上下文無關文法（Not a context free grammar）

正如在解析簡介中提到的，上下文無關文法的語法可以用類似BNF的格式來定義。
　　不幸的是，所有的傳統(tǒng)解析方式都不適用于html（當然我提出它們并不只是因為好玩，它們將用來解析css和js），html不能簡單的用解析所需的上下文無關文法來定義。
　　Html有一個正式的格式定義——DTD（Document Type Definition文檔類型定義）——但它并不是上下文無關文法，html更接近于xml，現(xiàn)在有很多可用的xml解析器，html有個xml的變體——xhtml，它們間的不同在于，html更寬容，它允許忽略一些特定標簽，有時可以省略開始或結束標簽。總的來說，它是一種soft語法，不像xml呆板、固執(zhí)。
　　顯然，這個看起來很小的差異卻帶來了很大的不同。一方面，這是html流行的原因——它的寬容使web開發(fā)人員的工作更加輕松，但另一方面，這也使很難去寫一個格式化的文法。所以，html的解析并不簡單，它既不能用傳統(tǒng)的解析器解析，也不能用xml解析器解析。

HTML DTD

Html適用DTD格式進行定義，這一格式是用于定義SGML家族的語言，包括了對所有允許元素及它們的屬性和層次關系的定義。正如前面提到的，html DTD并沒有生成一種上下文無關文法。
　　DTD有一些變種，標準模式只遵守規(guī)范，而其他模式則包含了對瀏覽器過去所使用標簽的支持，這么做是為了兼容以前內(nèi)容。最新的標準DTD在http://www.w3.org/TR/html4/strict.dtd

DOM

輸出的樹，也就是解析樹，是由DOM元素及屬性節(jié)點組成的。DOM是文檔對象模型的縮寫，它是html文檔的對象表示，作為html元素的外部接口供js等調(diào)用。
　　樹的根是“document”對象。
　　DOM和標簽基本是一一對應的關系，例如，如下的標簽：

<code><html>
<body><p>Hello DOM</p><div><img src=”example.png” /></div>
</body>
</html>
</code>

將會被轉(zhuǎn)換為下面的DOM樹：

圖8：示例標簽對應的DOM樹

解析算法（The parsing algorithm）

正如前面章節(jié)中討論的，hmtl不能被一般的自頂向下或自底向上的解析器所解析。
　　原因是：
　　1. 這門語言本身的寬容特性
　　2. 瀏覽器對一些常見的非法html有容錯機制
　　3. 解析過程是往復的，通常源碼不會在解析過程中發(fā)生改變，但在html中，腳本標簽包含的“document.write”可能添加標簽，這說明在解析過程中實際上修改了輸入。
　　不能使用正則解析技術，瀏覽器為html定制了專屬的解析器。
　　Html5規(guī)范中描述了這個解析算法，算法包括兩個階段——符號化及構建樹。
　　符號化是詞法分析的過程，將輸入解析為符號，html的符號包括開始標簽、結束標簽、屬性名及屬性值。
　　符號識別器識別出符號后，將其傳遞給樹構建器，并讀取下一個字符，以識別下一個符號，這樣直到處理完所有輸入。

圖9：HTML解析流程

圖9：HTML解析流程

符號識別算法（The tokenization algorithm）

算法輸出html符號，該算法用狀態(tài)機表示。每次讀取輸入流中的一個或多個字符，并根據(jù)這些字符轉(zhuǎn)移到下一個狀態(tài)，當前的符號狀態(tài)及構建樹狀態(tài)共同影響結果，這意味著，讀取同樣的字符，可能因為當前狀態(tài)的不同，得到不同的結果以進入下一個正確的狀態(tài)。
　　這個算法很復雜，這里用一個簡單的例子來解釋這個原理。
　　基本示例——符號化下面的html：

<code><html>
<body>
Hello world
</body>
</html></code>

初始狀態(tài)為“Data State”，當遇到“<”字符，狀態(tài)變?yōu)椤癟ag open state”，讀取一個a－z的字符將產(chǎn)生一個開始標簽符號，狀態(tài)相應變?yōu)椤癟ag name state”，一直保持這個狀態(tài)直到讀取到“>”，每個字符都附加到這個符號名上，例子中創(chuàng)建的是一個html符號。
　　當讀取到“>”，當前的符號就完成了，此時，狀態(tài)回到“Data state”，“<body>”重復這一處理過程。到這里，html和body標簽都識別出來了。現(xiàn)在，回到“Data state”，讀取“Hello world”中的字符“H”將創(chuàng)建并識別出一個字符符號，這里會為“Hello world”中的每個字符生成一個字符符號。
　　這樣直到遇到“</body>”中的“<”。現(xiàn)在，又回到了“Tag open state”，讀取下一個字符“/”將創(chuàng)建一個閉合標簽符號，并且狀態(tài)轉(zhuǎn)移到“Tag name state”，還是保持這一狀態(tài)，直到遇到“>”。然后，產(chǎn)生一個新的標簽符號并回到“Data state”。后面的“</html>”將和“</body>”一樣處理。

圖10：符號化示例輸入

圖10：符號化示例輸入

樹的構建算法（Tree construction algorithm）

在樹的構建階段，將修改以Document為根的DOM樹，將元素附加到樹上。每個由符號識別器識別生成的節(jié)點將會被樹構造器進行處理，規(guī)范中定義了每個符號相對應的Dom元素，對應的Dom元素將會被創(chuàng)建。這些元素除了會被添加到Dom樹上，還將被添加到開放元素堆棧中。這個堆棧用來糾正嵌套的未匹配和未閉合標簽，這個算法也是用狀態(tài)機來描述，所有的狀態(tài)采用插入模式。
　　來看一下示例中樹的創(chuàng)建過程：

<code><html>
<body>
Hello world
</body>
</html></code>

構建樹這一階段的輸入是符號識別階段生成的符號序列。
　　首先是“initial mode”，接收到html符號后將轉(zhuǎn)換為“before html”模式，在這個模式中對這個符號進行再處理。此時，創(chuàng)建了一個HTMLHtmlElement元素，并將其附加到根Document對象上。
　　狀態(tài)此時變?yōu)椤癰efore head”，接收到body符號時，即使這里沒有head符號，也將自動創(chuàng)建一個HTMLHeadElement元素并附加到樹上。
　　現(xiàn)在，轉(zhuǎn)到“in head”模式，然后是“after head”。到這里，body符號會被再次處理，將創(chuàng)建一個HTMLBodyElement并插入到樹中，同時，轉(zhuǎn)移到“in body”模式。
　　然后，接收到字符串“Hello world”的字符符號，第一個字符將導致創(chuàng)建并插入一個text節(jié)點，其他字符將附加到該節(jié)點。
　　接收到body結束符號時，轉(zhuǎn)移到“after body”模式，接著接收到html結束符號，這個符號意味著轉(zhuǎn)移到了“after after body”模式，當接收到文件結束符時，整個解析過程結束。

圖11：示例html樹的構建過程

圖11：示例html樹的構建過程

解析結束時的處理（Action when the parsing is finished）

在這個階段，瀏覽器將文檔標記為可交互的，并開始解析處于延時模式中的腳本——這些腳本在文檔解析后執(zhí)行。
　　文檔狀態(tài)將被設置為完成，同時觸發(fā)一個load事件。
　　Html5規(guī)范中有符號化及構建樹的完整算法(http://www.w3.org/TR/html5/syntax.html#html-parser)。

瀏覽器容錯（Browsers error tolerance）

你從來不會在一個html頁面上看到“無效語法”這樣的錯誤，瀏覽器修復了無效內(nèi)容并繼續(xù)工作。
　　以下面這段html為例：

<code>
<html>
<mytag>
</mytag>
<div>
<p>
</div>Really lousy HTML</p>
</html></code>

這段html違反了很多規(guī)則（mytag不是合法的標簽，p及div錯誤的嵌套等等），但是瀏覽器仍然可以沒有任何怨言的繼續(xù)顯示，它在解析的過程中修復了html作者的錯誤。
　　瀏覽器都具有錯誤處理的能力，但是，另人驚訝的是，這并不是html最新規(guī)范的內(nèi)容，就像書簽及前進后退按鈕一樣，它只是瀏覽器長期發(fā)展的結果。一些比較知名的非法html結構，在許多站點中出現(xiàn)過，瀏覽器都試著以一種和其他瀏覽器一致的方式去修復。
　　Html5規(guī)范定義了這方面的需求，webkit在html解析類開始部分的注釋中做了很好的總結。
　　解析器將符號化的輸入解析為文檔并創(chuàng)建文檔，但不幸的是，我們必須處理很多沒有很好格式化的html文檔，至少要小心下面幾種錯誤情況。
　　1. 在未閉合的標簽中添加明確禁止的元素。這種情況下，應該先將前一標簽閉合
　　2. 不能直接添加元素。有些人在寫文檔的時候會忘了中間一些標簽（或者中間標簽是可選的），比如HTML HEAD BODY TR TD LI等
　　3. 想在一個行內(nèi)元素中添加塊狀元素。關閉所有的行內(nèi)元素，直到下一個更高的塊狀元素
　　4. 如果這些都不行，就閉合當前標簽直到可以添加該元素。
　　下面來看一些webkit容錯的例子：

</ br>替代< br>
　　一些網(wǎng)站使用</ br>替代< br>，為了兼容IE和Firefox，webkit將其看作< br>。
　　代碼：
if (t->isCloseTag(brTag) && m_document->inCompatMode()) {reportError(MalformedBRError);t->beginTag = true;}

Note －這里的錯誤處理在內(nèi)部進行，用戶看不到。
　　迷路的表格
　　這指一個表格嵌套在另一個表格中，但不在它的某個單元格內(nèi)。
　　比如下面這個例子：
<pre><table><table><tr><td>inner table</td></tr></table><tr><td>outer table</td></tr></table></pre>

webkit將會將嵌套的表格變?yōu)閮蓚€兄弟表格：
<pre><table><tr><td>outer table</td></tr></table><table><tr><td>inner table</td></tr></table></pre>

代碼：
<pre>if (m_inStrayTableContent && localName == tableTag)popBlock(tableTag);</pre>

webkit使用堆棧存放當前的元素內(nèi)容，它將從外部表格的堆棧中彈出內(nèi)部的表格，則它們變?yōu)榱诵值鼙砀瘛?br> 　　嵌套的表單元素
　　用戶將一個表單嵌套到另一個表單中，則第二個表單將被忽略。
　　代碼：
<pre>if (!m_currentFormElement) {m_currentFormElement = new HTMLFormElement(formTag,m_document);}</pre>

太深的標簽繼承
　　www.liceo.edu.mx是一個由嵌套層次的站點的例子，最多只允許20個相同類型的標簽嵌套，多出來的將被忽略。
　　代碼：
<pre>bool HTMLParser::allowNestedRedundantTag(const AtomicString& tagName){unsigned i = 0;for (HTMLStackElem* curr = m_blockStack;i < cMaxRedundantTagDepth && curr && curr->tagName == tagName;curr = curr->next, i++) { }return i != cMaxRedundantTagDepth;}</pre>

放錯了地方的html、body閉合標簽
　　又一次不言自明。
　　支持不完整的html。我們從來不閉合body，因為一些愚蠢的網(wǎng)頁總是在還未真正結束時就閉合它。我們依賴調(diào)用end方法去執(zhí)行關閉的處理。
　　代碼：
<pre>if (t->tagName == htmlTag || t->tagName == bodyTag )return;</pre>

所以，web開發(fā)者要小心了，除非你想成為webkit容錯代碼的范例，否則還是寫格式良好的html吧。

CSS解析（CSS parsing）

還記得簡介中提到的解析的概念嗎，不同于html，css屬于上下文無關文法，可以用前面所描述的解析器來解析。Css規(guī)范定義了css的詞法及語法文法。
　　看一些例子：
　　每個符號都由正則表達式定義了詞法文法（詞匯表）：
<code>comment///[^]/+([^/*][]/+)//num[0-9]+|[0-9]"."[0-9]+nonascii[/200-/377]nmstart[_a-z]|{nonascii}|{escape}nmchar[_a-z0-9-]|{nonascii}|{escape}name{nmchar}+ident{nmstart}{nmchar}</code>

“ident”是識別器的縮寫，相當于一個class名，“name”是一個元素id（用“＃”引用）。
　　語法用BNF進行描述：

ruleset: selector [ ',' S* selector ]'{' S declaration [ ';' S* declaration ]* '}' S;selector: simple_selector [ combinator selector | S+ [ combinator selector ] ];simple_selector: element_name [ HASH | class | attrib | pseudo ]| [ HASH | class | attrib | pseudo ]+;class: '.' IDENT;element_name: IDENT | '';attrib: '[' S IDENT S* [ [ '=' | INCLUDES | DASHMATCH ] S[ IDENT | STRING ] S ] ']';pseudo: ':' [ IDENT | FUNCTION S* [IDENT S] ')' ];說明：一個規(guī)則集合有這樣的結構div.error , a.error {color:red;font-weight:bold;}div.error和a.error時選擇器，大括號中的內(nèi)容包含了這條規(guī)則集合中的規(guī)則，這個結構在下面的定義中正式的定義了：ruleset: selector [ ',' S selector ]'{' S declaration [ ';' S* declaration ]* '}' S*;

這說明，一個規(guī)則集合具有一個或是可選個數(shù)的多個選擇器，這些選擇器以逗號和空格（S表示空格）進行分隔。每個規(guī)則集合包含大括號及大括號中的一條或多條以分號隔開的聲明。聲明和選擇器在后面進行定義。

Webkit CSS解析器（Webkit CSS parser）

Webkit使用Flex和Bison解析生成器從CSS語法文件中自動生成解析器。回憶一下解析器的介紹，Bison創(chuàng)建一個自底向上的解析器，F(xiàn)irefox使用自頂向下解析器。它們都是將每個css文件解析為樣式表對象，每個對象包含css規(guī)則，css規(guī)則對象包含選擇器和聲明對象，以及其他一些符合css語法的對象。

圖12：解析css

圖12：解析css

處理腳本及樣式表的順序（The order of processing scripts and style sheets）

腳本
　　web的模式是同步的，開發(fā)者希望解析到一個script標簽時立即解析執(zhí)行腳本，并阻塞文檔的解析直到腳本執(zhí)行完。如果腳本是外引的，則網(wǎng)絡必須先請求到這個資源——這個過程也是同步的，會阻塞文檔的解析直到資源被請求到。這個模式保持了很多年，并且在html4及html5中都特別指定了。開發(fā)者可以將腳本標識為defer，以使其不阻塞文檔解析，并在文檔解析結束后執(zhí)行。Html5增加了標記腳本為異步的選項，以使腳本的解析執(zhí)行使用另一個線程。

預解析（Speculative parsing）

Webkit和Firefox都做了這個優(yōu)化，當執(zhí)行腳本時，另一個線程解析剩下的文檔，并加載后面需要通過網(wǎng)絡加載的資源。這種方式可以使資源并行加載從而使整體速度更快。需要注意的是，預解析并不改變Dom樹，它將這個工作留給主解析過程，自己只解析外部資源的引用，比如外部腳本、樣式表及圖片。

樣式表（Style sheets）

樣式表采用另一種不同的模式。理論上，既然樣式表不改變Dom樹，也就沒有必要停下文檔的解析等待它們，然而，存在一個問題，腳本可能在文檔的解析過程中請求樣式信息，如果樣式還沒有加載和解析，腳本將得到錯誤的值，顯然這將會導致很多問題，這看起來是個邊緣情況，但確實很常見。Firefox在存在樣式表還在加載和解析時阻塞所有的腳本，而Chrome只在當腳本試圖訪問某些可能被未加載的樣式表所影響的特定的樣式屬性時才阻塞這些腳本。

四、渲染樹構建（Render tree construction）

當Dom樹構建完成時，瀏覽器開始構建另一棵樹——渲染樹。渲染樹由元素顯示序列中的可見元素組成，它是文檔的可視化表示，構建這棵樹是為了以正確的順序繪制文檔內(nèi)容。
　　Firefox將渲染樹中的元素稱為frames，WebKit則用renderer或渲染對象來描述這些元素。
　　一個渲染對象知道怎么布局及繪制自己及它的children。
　　RenderObject是Webkit的渲染對象基類，它的定義如下：
<code>class RenderObject{virtual void layout();virtual void paint(PaintInfo);virtual void rect repaintRect();Node* node;//the DOM nodeRenderStyle* style;// the computed styleRenderLayer* containgLayer; //the containing z-index layer}</code>

每個渲染對象用一個和該節(jié)點的css盒模型相對應的矩形區(qū)域來表示，正如css2所描述的那樣，它包含諸如寬、高和位置之類的幾何信息。盒模型的類型受該節(jié)點相關的display樣式屬性的影響（參考樣式計算章節(jié)）。下面的webkit代碼說明了如何根據(jù)display屬性決定某個節(jié)點創(chuàng)建何種類型的渲染對象。
<code>RenderObject* RenderObject::createObject(Node* node, RenderStyle* style){Document* doc = node->document();RenderArena* arena = doc->renderArena();...RenderObject* o = 0;switch (style->display()) {case NONE:break;case INLINE:o = new (arena) RenderInline(node);break;case BLOCK:o = new (arena) RenderBlock(node);break;case INLINE_BLOCK:o = new (arena) RenderBlock(node);break;case LIST_ITEM:o = new (arena) RenderListItem(node);break;...}return o;}</code>

元素的類型也需要考慮，例如，表單控件和表格帶有特殊的框架。
　　在Webkit中，如果一個元素想創(chuàng)建一個特殊的渲染對象，它需要重寫“createRenderer”方法，使渲染對象指向不包含幾何信息的樣式對象。

渲染樹和Dom樹的關系（The render tree relation to the DOM tree）

渲染對象和Dom元素相對應，但這種對應關系不是一對一的，不可見的Dom元素不會被插入渲染樹，例如head元素。另外，display屬性為none的元素也不會在渲染樹中出現(xiàn)（visibility屬性為hidden的元素將出現(xiàn)在渲染樹中）。
　　還有一些Dom元素對應幾個可見對象，它們一般是一些具有復雜結構的元素，無法用一個矩形來描述。例如，select元素有三個渲染對象——一個顯示區(qū)域、一個下拉列表及一個按鈕。同樣，當文本因為寬度不夠而折行時，新行將作為額外的渲染元素被添加。另一個多個渲染對象的例子是不規(guī)范的html，根據(jù)css規(guī)范，一個行內(nèi)元素只能僅包含行內(nèi)元素或僅包含塊狀元素，在存在混合內(nèi)容時，將會創(chuàng)建匿名的塊狀渲染對象包裹住行內(nèi)元素。
　　一些渲染對象和所對應的Dom節(jié)點不在樹上相同的位置，例如，浮動和絕對定位的元素在文本流之外，在兩棵樹上的位置不同，渲染樹上標識出真實的結構，并用一個占位結構標識出它們原來的位置。

圖13：渲染樹及對應的Dom樹

圖13：渲染樹及對應的Dom樹

創(chuàng)建樹的流程（The flow of constructing the tree）

Firefox中，表述為一個監(jiān)聽Dom更新的監(jiān)聽器，將frame的創(chuàng)建委派給Frame Constructor，這個構建器計算樣式（參看樣式計算）并創(chuàng)建一個frame。
　　Webkit中，計算樣式并生成渲染對象的過程稱為attachment，每個Dom節(jié)點有一個attach方法，attachment的過程是同步的，調(diào)用新節(jié)點的attach方法將節(jié)點插入到Dom樹中。
　　處理html和body標簽將構建渲染樹的根，這個根渲染對象對應被css規(guī)范稱為containing block的元素——包含了其他所有塊元素的頂級塊元素。它的大小就是viewport——瀏覽器窗口的顯示區(qū)域，F(xiàn)irefox稱它為viewPortFrame，webkit稱為RenderView，這個就是文檔所指向的渲染對象，樹中其他的部分都將作為一個插入的Dom節(jié)點被創(chuàng)建。

樣式計算（Style Computation）

創(chuàng)建渲染樹需要計算出每個渲染對象的可視屬性，這可以通過計算每個元素的樣式屬性得到。
　　樣式包括各種來源的樣式表，行內(nèi)樣式元素及html中的可視化屬性（例如bgcolor），可視化屬性轉(zhuǎn)化為css樣式屬性。
　　樣式表來源于瀏覽器默認樣式表，及頁面作者和用戶提供的樣式表——有些樣式是瀏覽器用戶提供的（瀏覽器允許用戶定義喜歡的樣式，例如，在Firefox中，可以通過在Firefox Profile目錄下放置樣式表實現(xiàn)）。
　　計算樣式的一些困難：
　　1. 樣式數(shù)據(jù)是非常大的結構，保存大量的樣式屬性會帶來內(nèi)存問題。
　　2. 如果不進行優(yōu)化，找到每個元素匹配的規(guī)則會導致性能問題，為每個元素查找匹配的規(guī)則都需要遍歷整個規(guī)則表，這個過程有很大的工作量。選擇符可能有復雜的結構，匹配過程如果沿著一條開始看似正確，后來卻被證明是無用的路徑，則必須去嘗試另一條路徑。
　　例如，下面這個復雜選擇符
　　div div div div｛…｝
　　這意味著規(guī)則應用到三個div的后代div元素，選擇樹上一條特定的路徑去檢查，這可能需要遍歷節(jié)點樹，最后卻發(fā)現(xiàn)它只是兩個div的后代，并不使用該規(guī)則，然后則需要沿著另一條路徑去嘗試
　　3. 應用規(guī)則涉及非常復雜的級聯(lián)，它們定義了規(guī)則的層次
　　我們來看一下瀏覽器如何處理這些問題：

共享樣式數(shù)據(jù)（Sharing style data）

WebkKit節(jié)點引用樣式對象（渲染樣式），某些情況下，這些對象可以被節(jié)點間共享，這些節(jié)點需要是兄弟或是表兄弟節(jié)點，并且：
　　1. 這些元素必須處于相同的鼠標狀態(tài)（比如不能一個處于hover，而另一個不是）
　　2. 不能有元素具有id
　　3. 標簽名必須匹配
　　4. class屬性必須匹配
　　5. 對應的屬性必須相同
　　6. 鏈接狀態(tài)必須匹配
　　7. 焦點狀態(tài)必須匹配
　　8. 不能有元素被屬性選擇器影響
　　9. 元素不能有行內(nèi)樣式屬性
　　10. 不能有生效的兄弟選擇器，webcore在任何兄弟選擇器相遇時只是簡單的拋出一個全局轉(zhuǎn)換，并且在它們顯示時使整個文檔的樣式共享失效，這些包括＋選擇器和類似:first-child和:last-child這樣的選擇器。

Firefox規(guī)則樹（Firefox rule tree）

Firefox用兩個樹用來簡化樣式計算－規(guī)則樹和樣式上下文樹，WebKit也有樣式對象，但它們并沒有存儲在類似樣式上下文樹這樣的樹中，只是由Dom節(jié)點指向其相關的樣式。

圖14：Firefox樣式上下文樹

　　樣式上下文包含最終值，這些值是通過以正確順序應用所有匹配的規(guī)則，并將它們由邏輯值轉(zhuǎn)換為具體的值，例如，如果邏輯值為屏幕的百分比，則通過計算將其轉(zhuǎn)化為絕對單位。樣式樹的使用確實很巧妙，它使得在節(jié)點中共享的這些值不需要被多次計算，同時也節(jié)省了存儲空間。
　　所有匹配的規(guī)則都存儲在規(guī)則樹中，一條路徑中的底層節(jié)點擁有最高的優(yōu)先級，這棵樹包含了所找到的所有規(guī)則匹配的路徑（譯注：可以取巧理解為每條路徑對應一個節(jié)點，路徑上包含了該節(jié)點所匹配的所有規(guī)則）。規(guī)則樹并不是一開始就為所有節(jié)點進行計算，而是在某個節(jié)點需要計算樣式時，才進行相應的計算并將計算后的路徑添加到樹中。
　　我們將樹上的路徑看成辭典中的單詞，假如已經(jīng)計算出了如下的規(guī)則樹：

結構化

樣式上下文按結構劃分，這些結構包括類似border或color這樣的特定分類的樣式信息。一個結構中的所有特性不是繼承的就是非繼承的，對繼承的特性，除非元素自身有定義，否則就從它的parent繼承。非繼承的特性（稱為reset特性）如果沒有定義，則使用默認的值。
　　樣式上下文樹緩存完整的結構（包括計算后的值），這樣，如果底層節(jié)點沒有為一個結構提供定義，則使用上層節(jié)點緩存的結構。
　　使用規(guī)則樹計算樣式上下文
　　當為一個特定的元素計算樣式時，首先計算出規(guī)則樹中的一條路徑，或是使用已經(jīng)存在的一條，然后使用路徑中的規(guī)則去填充新的樣式上下文，從樣式的底層節(jié)點開始，它具有最高優(yōu)先級（通常是最特定的選擇器），遍歷規(guī)則樹，直到填滿結構。如果在那個規(guī)則節(jié)點沒有定義所需的結構規(guī)則，則沿著路徑向上，直到找到該結構規(guī)則。
　　如果最終沒有找到該結構的任何規(guī)則定義，那么如果這個結構是繼承型的，則找到其在內(nèi)容樹中的parent的結構，這種情況下，我們也成功的共享了結構；如果這個結構是reset型的，則使用默認的值。
　　如果特定的節(jié)點添加了值，那么需要做一些額外的計算以將其轉(zhuǎn)換為實際值，然后在樹上的節(jié)點緩存該值，使它的children可以使用。
　　當一個元素和它的一個兄弟元素指向同一個樹節(jié)點時，完整的樣式上下文可以被它們共享。
　　來看一個例子：假設有下面這段html
<code><html><body><div class="err" id="div1"><p>this is a<span class="big"> big error </span>this is also a<span class="big"> verybigerror</span>error</p></div><div class="err" id="div2">another error</div></body></html></code>

以及下面這些規(guī)則
<code>1.div {margin:5px;color:black}
2.err {color:red}
3.big {margin-top:3px}
4.div span {margin-bottom:4px}
5.#div1 {color:blue}
6.#div2 {color:green}</code>

簡化下問題，我們只填充兩個結構——color和margin，color結構只包含一個成員－顏色，margin結構包含四邊。
　　生成的規(guī)則樹如下（節(jié)點名：指向的規(guī)則）

　　上下文樹如下（節(jié)點名：指向的規(guī)則節(jié)點）

　　現(xiàn)在我們需要填充這個樣式上下文，先從填充margin結構開始，既然最后一個規(guī)則節(jié)點沒有添加margin結構，沿著路徑向上，直到找到緩存的前面插入節(jié)點計算出的結構，我們發(fā)現(xiàn)B是最近的指定margin值的節(jié)點。因為已經(jīng)有了color結構的定義，所以不能使用緩存的結構，既然color只有一個屬性，也就不需要沿著路徑向上填充其他屬性。計算出最終值（將字符串轉(zhuǎn)換為RGB等），并緩存計算后的結構。
　　第二個span元素更簡單，進行規(guī)則匹配后發(fā)現(xiàn)它指向規(guī)則G，和前一個span一樣，既然有兄弟節(jié)點指向同一個節(jié)點，就可以共享完整的樣式上下文，只需指向前一個span的上下文。
　　因為結構中包含繼承自parent的規(guī)則，上下文樹做了緩存（color特性是繼承來的，但Firefox將其視為reset并在規(guī)則樹中緩存）。
　　例如，如果我們?yōu)橐粋€paragraph的文字添加規(guī)則：
　　p {font-family:Verdana;font size:10px;font-weight:bold}
　　那么這個p在內(nèi)容樹中的子節(jié)點div，會共享和它parent一樣的font結構，這種情況發(fā)生在沒有為這個div指定font規(guī)則時。
　　Webkit中，并沒有規(guī)則樹，匹配的聲明會被遍歷四次，先是應用非important的高優(yōu)先級屬性（之所以先應用這些屬性，是因為其他的依賴于它們－比如display），其次是高優(yōu)先級important的，接著是一般優(yōu)先級非important的，最后是一般優(yōu)先級important的規(guī)則。這樣，出現(xiàn)多次的屬性將被按照正確的級聯(lián)順序進行處理，最后一個生效。
　　總結一下，共享樣式對象（結構中完整或部分內(nèi)容）解決了問題1和3，F(xiàn)irefox的規(guī)則樹幫助以正確的順序應用規(guī)則。

對規(guī)則進行處理以簡化匹配過程

樣式規(guī)則有幾個來源：
外部樣式表或style標簽內(nèi)的css規(guī)則
行內(nèi)樣式屬性
html可視化屬性（映射為相應的樣式規(guī)則）

后面兩個很容易匹配到元素，因為它們所擁有的樣式屬性和html屬性可以將元素作為key進行映射。
　　就像前面問題2所提到的，css的規(guī)則匹配可能很狡猾，為了解決這個問題，可以先對規(guī)則進行處理，以使其更容易被訪問。
　　解析完樣式表之后，規(guī)則會根據(jù)選擇符添加一些hash映射，映射可以是根據(jù)id、class、標簽名或是任何不屬于這些分類的綜合映射。如果選擇符為id，規(guī)則將被添加到id映射，如果是class，則被添加到class映射，等等。
　　這個處理是匹配規(guī)則更容易，不需要查看每個聲明，我們能從映射中找到一個元素的相關規(guī)則，這個優(yōu)化使在進行規(guī)則匹配時減少了95+%的工作量。
　　來看下面的樣式規(guī)則：
<code>p.error {color:red}#messageDiv {height:50px}div {margin:5px}</code>

第一條規(guī)則將被插入class映射，第二條插入id映射，第三條是標簽映射。
　　下面這個html片段：
<code><p class="error">an error occurred </p><div id=" messageDiv">this is a message</div></code>

我們首先找到p元素對應的規(guī)則，class映射將包含一個“error”的key，找到p.error的規(guī)則，div在id映射和標簽映射中都有相關的規(guī)則，剩下的工作就是找出這些由key對應的規(guī)則中哪些確實是正確匹配的。
　　例如，如果div的規(guī)則是
<code>table div {margin:5px}</code>

這也是標簽映射產(chǎn)生的，因為key是最右邊的選擇符，但它并不匹配這里的div元素，因為這里的div沒有table祖先。
　　Webkit和Firefox都會做這個處理。

以正確的級聯(lián)順序應用規(guī)則

樣式對象擁有對應所有可見屬性的屬性，如果特性沒有被任何匹配的規(guī)則所定義，那么一些特性可以從parent的樣式對象中繼承，另外一些使用默認值。
　　這個問題的產(chǎn)生是因為存在不止一處的定義，這里用級聯(lián)順序解決這個問題。
　　樣式表的級聯(lián)順序
　　一個樣式屬性的聲明可能在幾個樣式表中出現(xiàn)，或是在一個樣式表中出現(xiàn)多次，因此，應用規(guī)則的順序至關重要，這個順序就是級聯(lián)順序。根據(jù)css2的規(guī)范，級聯(lián)順序為（從低到高）：
　　1. 瀏覽器聲明
　　2. 用戶聲明
　　3. 作者的一般聲明
　　4. 作者的important聲明
　　5. 用戶important聲明
　　瀏覽器聲明是最不重要的，用戶只有在聲明被標記為important時才會覆蓋作者的聲明。具有同等級別的聲明將根據(jù)specifity以及它們被定義時的順序進行排序。Html可視化屬性將被轉(zhuǎn)換為匹配的css聲明，它們被視為最低優(yōu)先級的作者規(guī)則。
　　Specifity
　　Css2規(guī)范中定義的選擇符specifity如下：
如果聲明來自style屬性，而不是一個選擇器的規(guī)則，則計1，否則計0（＝a）
計算選擇器中id屬性的數(shù)量（＝b）
計算選擇器中class及偽類的數(shù)量（＝c）
計算選擇器中元素名及偽元素的數(shù)量（＝d）

連接a－b－c－d四個數(shù)量（用一個大基數(shù)的計算系統(tǒng)）將得到specifity。這里使用的基數(shù)由分類中最高的基數(shù)定義。例如，如果a為14，可以使用16進制。不同情況下，a為17時，則需要使用阿拉伯數(shù)字17作為基數(shù)，這種情況可能在這個選擇符時發(fā)生html body div div …（選擇符中有17個標簽，一般不太可能）。
　　一些例子：
<code>{}/ a=0 b=0 c=0 d=0 -> specificity = 0,0,0,0 /li{}/ a=0 b=0 c=0 d=1 -> specificity = 0,0,0,1 /li:first-line {}/ a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 /ul li{}/ a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 /ul ol+li{}/ a=0 b=0 c=0 d=3 -> specificity = 0,0,0,3 */h1 + [rel=up]{}/ a=0 b=0 c=1 d=1 -> specificity = 0,0,1,1 /ul ol li.red{}/ a=0 b=0 c=1 d=3 -> specificity = 0,0,1,3 /li.red.level{}/ a=0 b=0 c=2 d=1 -> specificity = 0,0,2,1 /#x34y{}/ a=0 b=1 c=0 d=0 -> specificity = 0,1,0,0 // a=1 b=0 c=0 d=0 -> specificity = 1,0,0,0 */</code>

規(guī)則排序
　　規(guī)則匹配后，需要根據(jù)級聯(lián)順序?qū)σ?guī)則進行排序，WebKit先將小列表用冒泡排序，再將它們合并為一個大列表，WebKit通過為規(guī)則復寫“>”操作來執(zhí)行排序：
<code>static bool operator >(CSSRuleData& r1, CSSRuleData& r2){int spec1 = r1.selector()->specificity();int spec2 = r2.selector()->specificity();return (spec1 == spec2) : r1.position() > r2.position() : spec1 > spec2;}</code>

逐步處理Gradual process

webkit使用一個標志位標識所有頂層樣式表都已加載，如果在attch時樣式?jīng)]有完全加載，則放置占位符，并在文檔中標記，一旦樣式表完成加載就重新進行計算。

五、布局（Layout）

當渲染對象被創(chuàng)建并添加到樹中，它們并沒有位置和大小，計算這些值的過程稱為layout或reflow。
　　Html使用基于流的布局模型，意味著大部分時間，可以以單一的途徑進行幾何計算。流中靠后的元素并不會影響前面元素的幾何特性，所以布局可以在文檔中從右向左、自上而下的進行。也存在一些例外，比如html tables。
　　坐標系統(tǒng)相對于根frame，使用top和left坐標。
　　布局是一個遞歸的過程，由根渲染對象開始，它對應html文檔元素，布局繼續(xù)遞歸的通過一些或所有的frame層級，為每個需要幾何信息的渲染對象進行計算。
　　根渲染對象的位置是0,0，它的大小是viewport－瀏覽器窗口的可見部分。
　　所有的渲染對象都有一個layout或reflow方法，每個渲染對象調(diào)用需要布局的children的layout方法。
　　Dirty bit系統(tǒng)
　　為了不因為每個小變化都全部重新布局，瀏覽器使用一個dirty bit系統(tǒng)，一個渲染對象發(fā)生了變化或是被添加了，就標記它及它的children為dirty——需要layout。存在兩個標識——dirty及children are dirty，children are dirty說明即使這個渲染對象可能沒問題，但它至少有一個child需要layout。
　　全局和增量layout
　　當layout在整棵渲染樹觸發(fā)時，稱為全局layout，這可能在下面這些情況下發(fā)生：
　　1. 一個全局的樣式改變影響所有的渲染對象，比如字號的改變。
　　2. 窗口resize。
　　layout也可以是增量的，這樣只有標志為dirty的渲染對象會重新布局（也將導致一些額外的布局）。增量layout會在渲染對象dirty時異步觸發(fā)，例如，當網(wǎng)絡接收到新的內(nèi)容并添加到Dom樹后，新的渲染對象會添加到渲染樹中。

圖20：增量layout

圖20：增量layout
　　異步和同步layout
　　增量layout的過程是異步的，F(xiàn)irefox為增量layout生成了reflow隊列，以及一個調(diào)度執(zhí)行這些批處理命令。WebKit也有一個計時器用來執(zhí)行增量layout－遍歷樹，為dirty狀態(tài)的渲染對象重新布局。
　　另外，當腳本請求樣式信息時，例如“offsetHeight”，會同步的觸發(fā)增量布局。
　　全局的layout一般都是同步觸發(fā)。
　　有些時候，layout會被作為一個初始layout之后的回調(diào)，比如滑動條的滑動。
　　優(yōu)化
　　當一個layout因為resize或是渲染位置改變（并不是大小改變）而觸發(fā)時，渲染對象的大小將會從緩存中讀取，而不會重新計算。
　　一般情況下，如果只有子樹發(fā)生改變，則layout并不從根開始。這種情況發(fā)生在，變化發(fā)生在元素自身并且不影響它周圍元素，例如，將文本插入文本域（否則，每次擊鍵都將觸發(fā)從根開始的重排）。
　　layout過程
　　layout一般有下面這幾個部分：
　　1. parent渲染對象決定它的寬度
　　2. parent渲染對象讀取chilidren，并：
　　　　a. 放置child渲染對象（設置它的x和y）
　　　　b. 在需要時（它們當前為dirty或是處于全局layout或者其他原因）調(diào)用child渲染對象的layout，這將計算child的高度
　　　　c. parent渲染對象使用child渲染對象的累積高度，以及margin和padding的高度來設置自己的高度－這將被parent渲染對象的parent使用
　　　　d. 將dirty標識設置為false
　　Firefox使用一個“state”對象（nsHTMLReflowState）做為參數(shù)去布局（firefox稱為reflow），state包含parent的寬度及其他內(nèi)容。
　　Firefox布局的輸出是一個“metrics”對象（nsHTMLReflowMetrics）。它包括渲染對象計算出的高度。
　　寬度計算
　　渲染對象的寬度使用容器的寬度、渲染對象樣式中的寬度及margin、border進行計算。例如，下面這個div的寬度：
　　<div />
　　webkit中寬度的計算過程是（RenderBox類的calcWidth方法）：
容器的寬度是容器的可用寬度和0中的最大值，這里的可用寬度為：contentWidth=clientWidth()-paddingLeft()-paddingRight()，clientWidth和clientHeight代表一個對象內(nèi)部的不包括border和滑動條的大小
元素的寬度指樣式屬性width的值，它可以通過計算容器的百分比得到一個絕對值
加上水平方向上的border和padding

到這里是最佳寬度的計算過程，現(xiàn)在計算寬度的最大值和最小值，如果最佳寬度大于最大寬度則使用最大寬度，如果小于最小寬度則使用最小寬度。最后緩存這個值，當需要layout但寬度未改變時使用。
　　Line breaking
　　當一個渲染對象在布局過程中需要折行時，則暫停并告訴它的parent它需要折行，parent將創(chuàng)建額外的渲染對象并調(diào)用它們的layout。
　　六、繪制（Painting）
　　繪制階段，遍歷渲染樹并調(diào)用渲染對象的paint方法將它們的內(nèi)容顯示在屏幕上，繪制使用UI基礎組件，這在UI的章節(jié)有更多的介紹。
　　全局和增量
　　和布局一樣，繪制也可以是全局的——繪制完整的樹——或增量的。在增量的繪制過程中，一些渲染對象以不影響整棵樹的方式改變，改變的渲染對象使其在屏幕上的矩形區(qū)域失效，這將導致操作系統(tǒng)將其看作dirty區(qū)域，并產(chǎn)生一個paint事件，操作系統(tǒng)很巧妙的處理這個過程，并將多個區(qū)域合并為一個。Chrome中，這個過程更復雜些，因為渲染對象在不同的進程中，而不是在主進程中。Chrome在一定程度上模擬操作系統(tǒng)的行為，表現(xiàn)為監(jiān)聽事件并派發(fā)消息給渲染根，在樹中查找到相關的渲染對象，重繪這個對象（往往還包括它的children）。
　　繪制順序
　　css2定義了繪制過程的順序——http://www.w3.org/TR/CSS21/zindex.html。這個就是元素壓入堆棧的順序，這個順序影響著繪制，堆棧從后向前進行繪制。
　　一個塊渲染對象的堆棧順序是：
　　1. 背景色
　　2. 背景圖
　　3. border
　　4. children
　　5. outline
　　Firefox顯示列表
　　Firefox讀取渲染樹并為繪制的矩形創(chuàng)建一個顯示列表，該列表以正確的繪制順序包含這個矩形相關的渲染對象。
　　用這樣的方法，可以使重繪時只需查找一次樹，而不需要多次查找——繪制所有的背景、所有的圖片、所有的border等等。
　　Firefox優(yōu)化了這個過程，它不添加會被隱藏的元素，比如元素完全在其他不透明元素下面。
　　WebKit矩形存儲
　　重繪前，WebKit將舊的矩形保存為位圖，然后只繪制新舊矩形的差集。
　　七、動態(tài)變化
　　瀏覽器總是試著以最小的動作響應一個變化，所以一個元素顏色的變化將只導致該元素的重繪，元素位置的變化將大致元素的布局和重繪，添加一個Dom節(jié)點，也會大致這個元素的布局和重繪。一些主要的變化，比如增加html元素的字號，將會導致緩存失效，從而引起整數(shù)的布局和重繪。
　　八、渲染引擎的線程
　　渲染引擎是單線程的，除了網(wǎng)絡操作以外，幾乎所有的事情都在單一的線程中處理，在Firefox和Safari中，這是瀏覽器的主線程，Chrome中這是tab的主線程。
　　網(wǎng)絡操作由幾個并行線程執(zhí)行，并行連接的個數(shù)是受限的（通常是2－6個）。
　　事件循環(huán)
　　瀏覽器主線程是一個事件循環(huán)，它被設計為無限循環(huán)以保持執(zhí)行過程的可用，等待事件（例如layout和paint事件）并執(zhí)行它們。下面是Firefox的主要事件循環(huán)代碼。
while (!mExiting)NS_ProcessNextEvent(thread);

九、CSS2可視模型（CSS2 visual module）
　　畫布The Canvas
　　根據(jù)CSS2規(guī)范，術語canvas用來描述格式化的結構所渲染的空間——瀏覽器繪制內(nèi)容的地方。畫布對每個維度空間都是無限大的，但瀏覽器基于viewport的大小選擇了一個初始寬度。
　　根據(jù)http://www.w3.org/TR/CSS2/zindex.html的定義，畫布如果是包含在其他畫布內(nèi)則是透明的，否則瀏覽器會指定一個顏色。
　　CSS盒模型
　　CSS盒模型描述了矩形盒，這些矩形盒是為文檔樹中的元素生成的，并根據(jù)可視的格式化模型進行布局。每個box包括內(nèi)容區(qū)域（如圖片、文本等）及可選的四周padding、border和margin區(qū)域。

瀏覽器主要組件

將顯示為：

　　Absolute和Fixed
　　這種情況下的布局完全不顧普通的文檔流，元素不屬于文檔流的一部分，大小取決于容器。Fixed時，容器為viewport（可視區(qū)域）。

　　Layered representation
　　這個由CSS屬性中的z-index指定，表示盒模型的第三個大小，即在z軸上的位置。Box分發(fā)到堆棧中（稱為堆棧上下文），每個堆棧中靠后的元素將被較早繪制，棧頂靠前的元素離用戶最近，當發(fā)生交疊時，將隱藏靠后的元素。堆棧根據(jù)z-index屬性排序，擁有z-index屬性的box形成了一個局部堆棧，viewport有外部堆棧，例如：
<STYLE type="text/css">div {position: absolute;left: 2in;top: 2in;}</STYLE><P><DIV></DIV><DIV></DIV></p>

結果是：

　　雖然綠色div排在紅色div后面，可能在正常流中也已經(jīng)被繪制在后面，但z-index有更高優(yōu)先級，所以在根box的堆棧中更靠前。