一、介紹
浏覽器可以被認為是使用最廣泛的軟體，本文将介紹浏覽器的工作原理，我們将看到，從你在位址欄輸入google.com到你看到google首頁過程中都發生了什麼。
将讨論的浏覽器
今天，有五種主流浏覽器——IE、Firefox、Safari、Chrome及Opera。
本文将基于一些開源浏覽器的例子——Firefox、Chrome及Safari，Safari是部分開源的。
根據W3C（World Wide Web Consortium網際網路聯盟）的浏覽器統計資料，目前（2011年5月），Firefox、Safari及Chrome的市場占有率綜合已接近60％。（原文為2009年10月，資料沒有太大變化）是以，可以說開源浏覽器已經占據了浏覽器市場的半壁江山。
浏覽器的主要功能
浏覽器的主要功能是将使用者選擇的web資源呈現出來，它需要從伺服器請求資源，并将其顯示在浏覽器視窗中，資源的格式通常是HTML，也包括PDF、image及其他格式。使用者用URI（Uniform Resource Identifier統一資源辨別符）來指定所請求資源的位置，在網絡一章有更多讨論。
HTML和CSS規範中規定了浏覽器解釋html文檔的方式，由W3C組織對這些規範進行維護，W3C是負責制定web标準的組織。
HTML規範的最新版本是HTML4(http://www.w3.org/TR/html401/)，HTML5還在制定中（譯注：兩年前），最新的CSS規範版本是2（http://www.w3.org/TR/CSS2），CSS3也還正在制定中（譯注：同樣兩年前）。
這些年來，浏覽器廠商紛紛開發自己的擴充，對規範的遵循并不完善，這為web開發者帶來了嚴重的相容性問題。
但是，浏覽器的使用者界面則差不多，常見的使用者界面元素包括：
- 用來輸入URI的位址欄
- 前進、後退按鈕
- 書簽選項
- 用于重新整理及暫停目前加載文檔的重新整理、暫停按鈕
- 用于到達首頁的首頁按鈕
奇怪的是，并沒有哪個正式公布的規範對使用者界面做出規定，這些是多年來各浏覽器廠商之間互相模仿和不斷改進的結果。
HTML5并沒有規定浏覽器必須具有的UI元素，但列出了一些常用元素，包括位址欄、狀态欄及工具欄。還有一些浏覽器有自己專有的功能，比如Firefox的下載下傳管理。更多相關内容将在後面讨論使用者界面時介紹。
浏覽器的主要構成（High Level Structure）
浏覽器的主要元件包括：
1. 使用者界面 － 包括位址欄、後退/前進按鈕、書簽目錄等，也就是你所看到的除了用來顯示你所請求頁面的主視窗之外的其他部分。
2. 浏覽器引擎 － 用來查詢及操作渲染引擎的接口。
3. 渲染引擎 － 用來顯示請求的内容，例如，如果請求内容為html，它負責解析html及css，并将解析後的結果顯示出來。
4. 網絡 － 用來完成網絡調用，例如http請求，它具有平台無關的接口，可以在不同平台上工作。
5. UI後端 － 用來繪制類似組合選擇框及對話框等基本元件，具有不特定于某個平台的通用接口，底層使用作業系統的使用者接口。
6. JS解釋器 － 用來解釋執行JS代碼。
7. 資料存儲 － 屬于持久層，浏覽器需要在硬碟中儲存類似cookie的各種資料，HTML5定義了web database技術，這是一種輕量級完整的用戶端存儲技術
圖1：浏覽器主要元件
需要注意的是，不同于大部分浏覽器，Chrome為每個Tab配置設定了各自的渲染引擎執行個體，每個Tab就是一個獨立的程序。
對于構成浏覽器的這些元件，後面會逐一詳細讨論。
二、渲染引擎（The rendering engine）
渲染引擎的職責就是渲染，即在浏覽器視窗中顯示所請求的内容。
預設情況下，渲染引擎可以顯示html、xml文檔及圖檔，它也可以借助插件（一種浏覽器擴充）顯示其他類型資料，例如使用PDF閱讀器插件，可以顯示PDF格式，将由專門一章講解插件及擴充，這裡隻讨論渲染引擎最主要的用途——顯示應用了CSS之後的html及圖檔。
渲染引擎簡介
本文所讨論的浏覽器——Firefox、Chrome和Safari是基于兩種渲染引擎建構的，Firefox使用Geoko——Mozilla自主研發的渲染引擎，Safari和Chrome都使用webkit。
Webkit是一款開源渲染引擎，它本來是為Linux平台研發的，後來由Apple移植到Mac及Windows上，相關内容請參考http://webkit.org。
渲染主流程（The main flow）
渲染引擎首先通過網絡獲得所請求文檔的内容，通常以8K分塊的方式完成。
下面是渲染引擎在取得内容之後的基本流程：
解析html以建構dom樹 -> 建構render樹 -> 布局render樹 -> 繪制render樹
圖2：渲染引擎基本流程
渲染引擎開始解析html，并将标簽轉化為内容樹中的dom節點。接着，它解析外部CSS檔案及style标簽中的樣式資訊。這些樣式資訊以及html中的可見性指令将被用來建構另一棵樹——render樹。
Render樹由一些包含有顔色和大小等屬性的矩形組成，它們将被按照正确的順序顯示到螢幕上。
Render樹建構好了之後，将會執行布局過程，它将确定每個節點在螢幕上的确切坐标。再下一步就是繪制，即周遊render樹，并使用UI後端層繪制每個節點。
值得注意的是，這個過程是逐漸完成的，為了更好的使用者體驗，渲染引擎将會盡可能早的将内容呈現到螢幕上，并不會等到所有的html都解析完成之後再去建構和布局render樹。它是解析完一部分内容就顯示一部分内容，同時，可能還在通過網絡下載下傳其餘内容。
圖3：webkit主流程
圖4：Mozilla的Geoko渲染引擎主流程
從圖3和4中可以看出，盡管webkit和Gecko使用的術語稍有不同，他們的主要流程基本相同。Gecko稱可見的格式化元素組成的樹為frame樹，每個元素都是一個frame，webkit則使用render樹這個名詞來命名由渲染對象組成的樹。Webkit中元素的定位稱為布局，而Gecko中稱為回流。Webkit稱利用dom節點及樣式資訊去建構render樹的過程為attachment，Gecko在html和dom樹之間附加了一層，這層稱為内容接收器，相當制造dom元素的工廠。下面将讨論流程中的各個階段。
三、解析與DOM樹建構（Parsing and DOM tree construction）
解析（Parsing－general）
既然解析是渲染引擎中一個非常重要的過程，我們将稍微深入的研究它。首先簡要介紹一下解析。
解析一個文檔即将其轉換為具有一定意義的結構——編碼可以了解和使用的東西。解析的結果通常是表達文檔結構的節點樹，稱為解析樹或文法樹。
例如，解析“2＋3－1”這個表達式，可能傳回這樣一棵樹。
圖5：數學表達式樹節點
文法（Grammars）
解析基于文檔依據的文法規則——文檔的語言或格式。每種可被解析的格式必須具有由詞彙及文法規則組成的特定的文法，稱為上下文無關文法。人類語言不具有這一特性，是以不能被一般的解析技術所解析。
解析器－詞法分析器（Parser－Lexer combination）
解析可以分為兩個子過程——文法分析及詞法分析
詞法分析就是将輸入分解為符号，符号是語言的詞彙表——基本有效單元的集合。對于人類語言來說，它相當于我們字典中出現的所有單詞。
文法分析指對語言應用文法規則。
解析器一般将工作配置設定給兩個元件——詞法分析器（有時也叫分詞器）負責将輸入分解為合法的符号，解析器則根據語言的文法規則分析文檔結構，進而建構解析樹，詞法分析器知道怎麼跳過空白和換行之類的無關字元。
圖6：從源文檔到解析樹
解析過程是疊代的，解析器從詞法分析器處取到一個新的符号，并試着用這個符号比對一條文法規則，如果比對了一條規則，這個符号對應的節點将被添加到解析樹上，然後解析器請求另一個符号。如果沒有比對到規則，解析器将在内部儲存該符号，并從詞法分析器取下一個符号，直到所有内部儲存的符号能夠比對一項文法規則。如果最終沒有找到比對的規則，解析器将抛出一個異常，這意味着文檔無效或是包含文法錯誤。
轉換（Translation）
很多時候，解析樹并不是最終結果。解析一般在轉換中使用——将輸入文檔轉換為另一種格式。編譯就是個例子，編譯器在将一段源碼編譯為機器碼的時候，先将源碼解析為解析樹，然後将該樹轉換為一個機器碼文檔。
圖7：編譯流程
解析執行個體Parsing example
圖5中，我們從一個數學表達式建構了一個解析樹，這裡定義一個簡單的數學語言來看下解析過程。
詞彙表：我們的語言包括整數、加号及減号。
文法：
1. 該語言的文法基本單元包括表達式、term及操作符
2. 該語言可以包括多個表達式
3. 一個表達式定義為兩個term通過一個操作符連接配接
4. 操作符可以是加号或減号
5. term可以是一個整數或一個表達式
現在來分析一下“2＋3－1”這個輸入
第一個比對規則的子字元串是“2”，根據規則5，它是一個term，第二個比對的是“2+3”，它符合第2條規則——一個操作符連接配接兩個term，下一次比對發生在輸入的結束處。“2+3-1”是一個表達式，因為我們已經知道“2+3”是一個term，是以我們有了一個term緊跟着一個操作符及另一個term。“2++”将不會比對任何規則，是以是一個無效輸入。
詞彙表及文法的定義
詞彙表通常利用正規表達式來定義。
例如上面的語言可以定義為：
INTEGER：0｜［1－9］［0－9］＊
PLUS：+
MINUS：－
正如看到的，這裡用正規表達式定義整數。
文法通常用BNF格式定義，我們的語言可以定義為：
expression :＝ term operation term
operation := PLUS | MINUS
term := INTEGER | expression
如果一個語言的文法是上下文無關的，則它可以用正則解析器來解析。對上下文無關文法的一個直覺的定義是，該文法可以用BNF來完整的表達。可檢視http://en.wikipedia.org/wiki/Context-free_grammar。
解析器類型（Types of parsers）
有兩種基本的解析器——自頂向下解析及自底向上解析。比較直覺的解釋是，自頂向下解析，檢視文法的最高層結構并試着比對其中一個；自底向上解析則從輸入開始，逐漸将其轉換為文法規則，從底層規則開始直到比對高層規則。
來看一下這兩種解析器如何解析上面的例子：
自頂向下解析器從最高層規則開始——它先識别出“2+3“，将其視為一個表達式，然後識别出”2+3-1“為一個表達式（識别表達式的過程中比對了其他規則，但出發點是最高層規則）。
自底向上解析會掃描輸入直到比對了一條規則，然後用該規則取代比對的輸入，直到解析完所有輸入。部分比對的表達式被放置在解析堆棧中。
| Stack | Input |
| 2 + 3 – 1 | |
| term | + 3 - 1 |
| term operation | 3 – 1 |
| expression | - 1 |
| expression operation | 1 |
| expression |
自底向上解析器稱為shift reduce解析器，因為輸入向右移動（想象一個指針首先指向輸入開始處，并向右移動），并逐漸簡化為文法規則。
自動化解析（Generating parsers automatically）
解析器生成器這個工具可以自動生成解析器，隻需要指定語言的文法——詞彙表及文法規則，它就可以生成一個解析器。建立一個解析器需要對解析有深入的了解，而且手動的建立一個由較好性能的解析器并不容易，是以解析生成器很有用。Webkit使用兩個知名的解析生成器——用于建立文法分析器的Flex及建立解析器的Bison（你可能接觸過Lex和Yacc）。Flex的輸入是一個包含了符号定義的正規表達式，Bison的輸入是用BNF格式表示的文法規則。
HTML解析器（HTML Parser）
HTML解析器的工作是将html辨別解析為解析樹。
HTML文法定義（The HTML grammar definition）
W3C組織制定規範定義了HTML的詞彙表和文法。
非上下文無關文法（Not a context free grammar）
正如在解析簡介中提到的，上下文無關文法的文法可以用類似BNF的格式來定義。
不幸的是，所有的傳統解析方式都不适用于html（當然我提出它們并不隻是因為好玩，它們将用來解析css和js），html不能簡單的用解析所需的上下文無關文法來定義。
Html有一個正式的格式定義——DTD（Document Type Definition文檔類型定義）——但它并不是上下文無關文法，html更接近于xml，現在有很多可用的xml解析器，html有個xml的變體——xhtml，它們間的不同在于，html更寬容，它允許忽略一些特定标簽，有時可以省略開始或結束标簽。總的來說，它是一種soft文法，不像xml呆闆、固執。
顯然，這個看起來很小的差異卻帶來了很大的不同。一方面，這是html流行的原因——它的寬容使web開發人員的工作更加輕松，但另一方面，這也使很難去寫一個格式化的文法。是以，html的解析并不簡單，它既不能用傳統的解析器解析，也不能用xml解析器解析。
HTML DTD
Html适用DTD格式進行定義，這一格式是用于定義SGML家族的語言，包括了對所有允許元素及它們的屬性和層次關系的定義。正如前面提到的，html DTD并沒有生成一種上下文無關文法。
DTD有一些變種，标準模式隻遵守規範，而其他模式則包含了對浏覽器過去所使用标簽的支援，這麼做是為了相容以前内容。最新的标準DTD在http://www.w3.org/TR/html4/strict.dtd
DOM
輸出的樹，也就是解析樹，是由DOM元素及屬性節點組成的。DOM是文檔對象模型的縮寫，它是html文檔的對象表示，作為html元素的外部接口供js等調用。
樹的根是“document”對象。
DOM和标簽基本是一一對應的關系，例如，如下的标簽：
<html>
<body>
<p>
Hello DOM
</p>
<div><img src=”example.png” /></div>
</body>
</html> 将會被轉換為下面的DOM樹：
圖8：示例标簽對應的DOM樹
和html一樣，DOM的規範也是由W3C組織制定的。通路http://www.w3.org/DOM/DOMTR，這是使用文檔的一般規範。一個模型描述一種特定的html元素，可以在http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/idl-definitions.htm檢視html定義。
這裡所謂的樹包含了DOM節點是說樹是由實作了DOM接口的元素建構而成的，浏覽器使用已被浏覽器内部使用的其他屬性的具體實作。
解析算法（The parsing algorithm）
正如前面章節中讨論的，hmtl不能被一般的自頂向下或自底向上的解析器所解析。
原因是：
1. 這門語言本身的寬容特性
2. 浏覽器對一些常見的非法html有容錯機制
3. 解析過程是往複的，通常源碼不會在解析過程中發生改變，但在html中，腳本标簽包含的“document.write”可能添加标簽，這說明在解析過程中實際上修改了輸入。
不能使用正則解析技術，浏覽器為html定制了專屬的解析器。
Html5規範中描述了這個解析算法，算法包括兩個階段——符号化及建構樹。
符号化是詞法分析的過程，将輸入解析為符号，html的符号包括開始标簽、結束标簽、屬性名及屬性值。
符号識别器識别出符号後，将其傳遞給樹建構器，并讀取下一個字元，以識别下一個符号，這樣直到處理完所有輸入。
圖9：HTML解析流程
符号識别算法（The tokenization algorithm）
算法輸出html符号，該算法用狀态機表示。每次讀取輸入流中的一個或多個字元，并根據這些字元轉移到下一個狀态，目前的符号狀态及建構樹狀态共同影響結果，這意味着，讀取同樣的字元，可能因為目前狀态的不同，得到不同的結果以進入下一個正确的狀态。
這個算法很複雜，這裡用一個簡單的例子來解釋這個原理。
基本示例——符号化下面的html：
<html>
<body>
Hello world
</body>
</html> 初始狀态為“Data State”，當遇到“<”字元，狀态變為“Tag open state”，讀取一個a－z的字元将産生一個開始标簽符号，狀态相應變為“Tag name state”，一直保持這個狀态直到讀取到“>”，每個字元都附加到這個符号名上，例子中建立的是一個html符号。
當讀取到“>”，目前的符号就完成了，此時，狀态回到“Data state”，“<body>”重複這一處理過程。到這裡，html和body标簽都識别出來了。現在，回到“Data state”，讀取“Hello world”中的字元“H”将建立并識别出一個字元符号，這裡會為“Hello world”中的每個字元生成一個字元符号。
這樣直到遇到“</body>”中的“<”。現在，又回到了“Tag open state”，讀取下一個字元“/”将建立一個閉合标簽符号，并且狀态轉移到“Tag name state”，還是保持這一狀态，直到遇到“>”。然後，産生一個新的标簽符号并回到“Data state”。後面的“</html>”将和“</body>”一樣處理。
圖10：符号化示例輸入
樹的建構算法（Tree construction algorithm）
在樹的建構階段，将修改以Document為根的DOM樹，将元素附加到樹上。每個由符号識别器識别生成的節點将會被樹構造器進行處理，規範中定義了每個符号相對應的Dom元素，對應的Dom元素将會被建立。這些元素除了會被添加到Dom樹上，還将被添加到開放元素堆棧中。這個堆棧用來糾正嵌套的未比對和未閉合标簽，這個算法也是用狀态機來描述，所有的狀态采用插入模式。
來看一下示例中樹的建立過程：
<html>
<body>
Hello world
</body>
</html> 建構樹這一階段的輸入是符号識别階段生成的符号序列。
首先是“initial mode”，接收到html符号後将轉換為“before html”模式，在這個模式中對這個符号進行再處理。此時，建立了一個HTMLHtmlElement元素，并将其附加到根Document對象上。
狀态此時變為“before head”，接收到body符号時，即使這裡沒有head符号，也将自動建立一個HTMLHeadElement元素并附加到樹上。
現在，轉到“in head”模式，然後是“after head”。到這裡，body符号會被再次處理，将建立一個HTMLBodyElement并插入到樹中，同時，轉移到“in body”模式。
然後，接收到字元串“Hello world”的字元符号，第一個字元将導緻建立并插入一個text節點，其他字元将附加到該節點。
接收到body結束符号時，轉移到“after body”模式，接着接收到html結束符号，這個符号意味着轉移到了“after after body”模式，當接收到檔案結束符時，整個解析過程結束。
圖11：示例html樹的建構過程
解析結束時的處理（Action when the parsing is finished）
在這個階段，浏覽器将文檔标記為可互動的，并開始解析處于延時模式中的腳本——這些腳本在文檔解析後執行。
文檔狀态将被設定為完成，同時觸發一個load事件。
Html5規範中有符号化及建構樹的完整算法(http://www.w3.org/TR/html5/syntax.html#html-parser)。
浏覽器容錯（Browsers error tolerance）
你從來不會在一個html頁面上看到“無效文法”這樣的錯誤，浏覽器修複了無效内容并繼續工作。
以下面這段html為例：
<html>
<mytag>
</mytag>
<div>
<p>
</div>
Really lousy HTML
</p>
</html> 這段html違反了很多規則（mytag不是合法的标簽，p及div錯誤的嵌套等等），但是浏覽器仍然可以沒有任何怨言的繼續顯示，它在解析的過程中修複了html作者的錯誤。
浏覽器都具有錯誤處理的能力，但是，另人驚訝的是，這并不是html最新規範的内容，就像書簽及前進後退按鈕一樣，它隻是浏覽器長期發展的結果。一些比較知名的非法html結構，在許多站點中出現過，浏覽器都試着以一種和其他浏覽器一緻的方式去修複。
Html5規範定義了這方面的需求，webkit在html解析類開始部分的注釋中做了很好的總結。
解析器将符号化的輸入解析為文檔并建立文檔，但不幸的是，我們必須處理很多沒有很好格式化的html文檔，至少要小心下面幾種錯誤情況。
1. 在未閉合的标簽中添加明确禁止的元素。這種情況下，應該先将前一标簽閉合
2. 不能直接添加元素。有些人在寫文檔的時候會忘了中間一些标簽（或者中間标簽是可選的），比如HTML HEAD BODY TR TD LI等
3. 想在一個行内元素中添加塊狀元素。關閉所有的行内元素，直到下一個更高的塊狀元素
4. 如果這些都不行，就閉合目前标簽直到可以添加該元素。
下面來看一些webkit容錯的例子：
</br>替代<br>
一些網站使用</br>替代<br>，為了相容IE和Firefox，webkit将其看作<br>。
代碼：
if (t->isCloseTag(brTag) && m_document->inCompatMode()) {
reportError(MalformedBRError);
t->beginTag = true;
} Note －這裡的錯誤處理在内部進行，使用者看不到。
迷路的表格
這指一個表格嵌套在另一個表格中，但不在它的某個單元格内。
比如下面這個例子：
<table>
<table>
<tr><td>inner table</td></tr>
</table>
<tr><td>outer table</td></tr>
</table> webkit将會将嵌套的表格變為兩個兄弟表格：
<table>
<tr><td>outer table</td></tr>
</table>
<table>
<tr><td>inner table</td></tr>
</table> 代碼：
if (m_inStrayTableContent && localName == tableTag)
popBlock(tableTag); webkit使用堆棧存放目前的元素内容，它将從外部表格的堆棧中彈出内部的表格，則它們變為了兄弟表格。
嵌套的表單元素
使用者将一個表單嵌套到另一個表單中，則第二個表單将被忽略。
代碼：
if (!m_currentFormElement) {
m_currentFormElement = new HTMLFormElement(formTag,m_document);
} 太深的标簽繼承
www.liceo.edu.mx是一個由嵌套層次的站點的例子，最多隻允許20個相同類型的标簽嵌套，多出來的将被忽略。
代碼：
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;
} 放錯了地方的html、body閉合标簽
又一次不言自明。
支援不完整的html。我們從來不閉合body，因為一些愚蠢的網頁總是在還未真正結束時就閉合它。我們依賴調用end方法去執行關閉的處理。
代碼：
if (t->tagName == htmlTag || t->tagName == bodyTag )
return; 是以，web開發者要小心了，除非你想成為webkit容錯代碼的範例，否則還是寫格式良好的html吧。
CSS解析（CSS parsing）
還記得簡介中提到的解析的概念嗎，不同于html，css屬于上下文無關文法，可以用前面所描述的解析器來解析。Css規範定義了css的詞法及文法文法。
看一些例子：
每個符号都由正規表達式定義了詞法文法（詞彙表）：
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}* “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*] ')' ]
;
說明：一個規則集合有這樣的結構
div.error , a.error {
color:red;
font-weight:bold;
}
div.error和a.error時選擇器，大括号中的内容包含了這條規則集合中的規則，這個結構在下面的定義中正式的定義了：
ruleset
: selector [ ',' S* selector ]*
'{' S* declaration [ ';' S* declaration ]* '}' S*
; 這說明，一個規則集合具有一個或是可選個數的多個選擇器，這些選擇器以逗号和空格（S表示空格）進行分隔。每個規則集合包含大括号及大括号中的一條或多條以分号隔開的聲明。聲明和選擇器在後面進行定義。
Webkit CSS解析器（Webkit CSS parser）
Webkit使用Flex和Bison解析生成器從CSS文法檔案中自動生成解析器。回憶一下解析器的介紹，Bison建立一個自底向上的解析器，Firefox使用自頂向下解析器。它們都是将每個css檔案解析為樣式表對象，每個對象包含css規則，css規則對象包含選擇器和聲明對象，以及其他一些符合css文法的對象。
圖12：解析css
處理腳本及樣式表的順序（The order of processing scripts and style sheets）
腳本
web的模式是同步的，開發者希望解析到一個script标簽時立即解析執行腳本，并阻塞文檔的解析直到腳本執行完。如果腳本是外引的，則網絡必須先請求到這個資源——這個過程也是同步的，會阻塞文檔的解析直到資源被請求到。這個模式保持了很多年，并且在html4及html5中都特别指定了。開發者可以将腳本辨別為defer，以使其不阻塞文檔解析，并在文檔解析結束後執行。Html5增加了标記腳本為異步的選項，以使腳本的解析執行使用另一個線程。
預解析（Speculative parsing）
Webkit和Firefox都做了這個優化，當執行腳本時，另一個線程解析剩下的文檔，并加載後面需要通過網絡加載的資源。這種方式可以使資源并行加載進而使整體速度更快。需要注意的是，預解析并不改變Dom樹，它将這個工作留給主解析過程，自己隻解析外部資源的引用，比如外部腳本、樣式表及圖檔。
樣式表（Style sheets）
樣式表采用另一種不同的模式。理論上，既然樣式表不改變Dom樹，也就沒有必要停下文檔的解析等待它們，然而，存在一個問題，腳本可能在文檔的解析過程中請求樣式資訊，如果樣式還沒有加載和解析，腳本将得到錯誤的值，顯然這将會導緻很多問題，這看起來是個邊緣情況，但确實很常見。Firefox在存在樣式表還在加載和解析時阻塞所有的腳本，而Chrome隻在當腳本試圖通路某些可能被未加載的樣式表所影響的特定的樣式屬性時才阻塞這些腳本。
四、渲染樹建構（Render tree construction）
當Dom樹建構完成時，浏覽器開始建構另一棵樹——渲染樹。渲染樹由元素顯示序列中的可見元素組成，它是文檔的可視化表示，建構這棵樹是為了以正确的順序繪制文檔内容。
Firefox将渲染樹中的元素稱為frames，WebKit則用renderer或渲染對象來描述這些元素。
一個渲染對象知道怎麼布局及繪制自己及它的children。
RenderObject是Webkit的渲染對象基類，它的定義如下：
class RenderObject{
virtual void layout();
virtual void paint(PaintInfo);
virtual void rect repaintRect();
Node* node;//the DOM node
RenderStyle* style;// the computed style
RenderLayer* containgLayer; //the containing z-index layer
} 每個渲染對象用一個和該節點的css盒模型相對應的矩形區域來表示，正如css2所描述的那樣，它包含諸如寬、高和位置之類的幾何資訊。盒模型的類型受該節點相關的display樣式屬性的影響（參考樣式計算章節）。下面的webkit代碼說明了如何根據display屬性決定某個節點建立何種類型的渲染對象。
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;
} 元素的類型也需要考慮，例如，表單控件和表格帶有特殊的架構。
在Webkit中，如果一個元素想建立一個特殊的渲染對象，它需要重寫“createRenderer”方法，使渲染對象指向不包含幾何資訊的樣式對象。
渲染樹和Dom樹的關系（The render tree relation to the DOM tree）
渲染對象和Dom元素相對應，但這種對應關系不是一對一的，不可見的Dom元素不會被插入渲染樹，例如head元素。另外，display屬性為none的元素也不會在渲染樹中出現（visibility屬性為hidden的元素将出現在渲染樹中）。
還有一些Dom元素對應幾個可見對象，它們一般是一些具有複雜結構的元素，無法用一個矩形來描述。例如，select元素有三個渲染對象——一個顯示區域、一個下拉清單及一個按鈕。同樣，當文本因為寬度不夠而折行時，新行将作為額外的渲染元素被添加。另一個多個渲染對象的例子是不規範的html，根據css規範，一個行内元素隻能僅包含行内元素或僅包含塊狀元素，在存在混合内容時，将會建立匿名的塊狀渲染對象包裹住行内元素。
一些渲染對象和所對應的Dom節點不在樹上相同的位置，例如，浮動和絕對定位的元素在文本流之外，在兩棵樹上的位置不同，渲染樹上辨別出真實的結構，并用一個占位結構辨別出它們原來的位置。
圖13：渲染樹及對應的Dom樹
建立樹的流程（The flow of constructing the tree）
Firefox中，表述為一個監聽Dom更新的監聽器，将frame的建立委派給Frame Constructor，這個建構器計算樣式（參看樣式計算）并建立一個frame。
Webkit中，計算樣式并生成渲染對象的過程稱為attachment，每個Dom節點有一個attach方法，attachment的過程是同步的，調用新節點的attach方法将節點插入到Dom樹中。
處理html和body标簽将建構渲染樹的根，這個根渲染對象對應被css規範稱為containing block的元素——包含了其他所有塊元素的頂級塊元素。它的大小就是viewport——浏覽器視窗的顯示區域，Firefox稱它為viewPortFrame，webkit稱為RenderView，這個就是文檔所指向的渲染對象，樹中其他的部分都将作為一個插入的Dom節點被建立。
樣式計算（Style Computation）
建立渲染樹需要計算出每個渲染對象的可視屬性，這可以通過計算每個元素的樣式屬性得到。
樣式包括各種來源的樣式表，行内樣式元素及html中的可視化屬性（例如bgcolor），可視化屬性轉化為css樣式屬性。
樣式表來源于浏覽器預設樣式表，及頁面作者和使用者提供的樣式表——有些樣式是浏覽器使用者提供的（浏覽器允許使用者定義喜歡的樣式，例如，在Firefox中，可以通過在Firefox Profile目錄下放置樣式表實作）。
計算樣式的一些困難：
1. 樣式資料是非常大的結構，儲存大量的樣式屬性會帶來記憶體問題。
2. 如果不進行優化，找到每個元素比對的規則會導緻性能問題，為每個元素查找比對的規則都需要周遊整個規則表，這個過程有很大的工作量。選擇符可能有複雜的結構，比對過程如果沿着一條開始看似正确，後來卻被證明是無用的路徑，則必須去嘗試另一條路徑。
例如，下面這個複雜選擇符
div div div div｛…｝
這意味着規則應用到三個div的後代div元素，選擇樹上一條特定的路徑去檢查，這可能需要周遊節點樹，最後卻發現它隻是兩個div的後代，并不使用該規則，然後則需要沿着另一條路徑去嘗試
3. 應用規則涉及非常複雜的級聯，它們定義了規則的層次
我們來看一下浏覽器如何處理這些問題：
共享樣式資料（Sharing style data）
WebkKit節點引用樣式對象（渲染樣式），某些情況下，這些對象可以被節點間共享，這些節點需要是兄弟或是表兄弟節點，并且：
1. 這些元素必須處于相同的滑鼠狀态（比如不能一個處于hover，而另一個不是）
2. 不能有元素具有id
3. 标簽名必須比對
4. class屬性必須比對
5. 對應的屬性必須相同
6. 連結狀态必須比對
7. 焦點狀态必須比對
8. 不能有元素被屬性選擇器影響
9. 元素不能有行内樣式屬性
10. 不能有生效的兄弟選擇器，webcore在任何兄弟選擇器相遇時隻是簡單的抛出一個全局轉換，并且在它們顯示時使整個文檔的樣式共享失效，這些包括＋選擇器和類似:first-child和:last-child這樣的選擇器。
Firefox規則樹（Firefox rule tree）
Firefox用兩個樹用來簡化樣式計算－規則樹和樣式上下文樹，WebKit也有樣式對象，但它們并沒有存儲在類似樣式上下文樹這樣的樹中，隻是由Dom節點指向其相關的樣式。
圖14：Firefox樣式上下文樹
樣式上下文包含最終值，這些值是通過以正确順序應用所有比對的規則，并将它們由邏輯值轉換為具體的值，例如，如果邏輯值為螢幕的百分比，則通過計算将其轉化為絕對機關。樣式樹的使用确實很巧妙，它使得在節點中共享的這些值不需要被多次計算，同時也節省了存儲空間。
所有比對的規則都存儲在規則樹中，一條路徑中的底層節點擁有最高的優先級，這棵樹包含了所找到的所有規則比對的路徑（譯注：可以取巧了解為每條路徑對應一個節點，路徑上包含了該節點所比對的所有規則）。規則樹并不是一開始就為所有節點進行計算，而是在某個節點需要計算樣式時，才進行相應的計算并将計算後的路徑添加到樹中。
我們将樹上的路徑看成辭典中的單詞，假如已經計算出了如下的規則樹：
假如需要為内容樹中的另一個節點比對規則，現在知道比對的規則（以正确的順序）為B-E-I，因為我們已經計算出了路徑A-B-E-I-L，是以樹上已經存在了這條路徑，剩下的工作就很少了。
現在來看一下樹如何儲存。
結構化
樣式上下文按結構劃分，這些結構包括類似border或color這樣的特定分類的樣式資訊。一個結構中的所有特性不是繼承的就是非繼承的，對繼承的特性，除非元素自身有定義，否則就從它的parent繼承。非繼承的特性（稱為reset特性）如果沒有定義，則使用預設的值。
樣式上下文樹緩存完整的結構（包括計算後的值），這樣，如果底層節點沒有為一個結構提供定義，則使用上層節點緩存的結構。
使用規則樹計算樣式上下文
當為一個特定的元素計算樣式時，首先計算出規則樹中的一條路徑，或是使用已經存在的一條，然後使用路徑中的規則去填充新的樣式上下文，從樣式的底層節點開始，它具有最高優先級（通常是最特定的選擇器），周遊規則樹，直到填滿結構。如果在那個規則節點沒有定義所需的結構規則，則沿着路徑向上，直到找到該結構規則。
如果最終沒有找到該結構的任何規則定義，那麼如果這個結構是繼承型的，則找到其在内容樹中的parent的結構，這種情況下，我們也成功的共享了結構；如果這個結構是reset型的，則使用預設的值。
如果特定的節點添加了值，那麼需要做一些額外的計算以将其轉換為實際值，然後在樹上的節點緩存該值，使它的children可以使用。
當一個元素和它的一個兄弟元素指向同一個樹節點時，完整的樣式上下文可以被它們共享。
來看一個例子：假設有下面這段html
<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> 以及下面這些規則
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} 簡化下問題，我們隻填充兩個結構——color和margin，color結構隻包含一個成員－顔色，margin結構包含四邊。
生成的規則樹如下（節點名：指向的規則）
上下文樹如下（節點名：指向的規則節點）
假設我們解析html，遇到第二個div标簽，我們需要為這個節點建立樣式上下文，并填充它的樣式結構。
我們進行規則比對，找到這個div比對的規則為1、2、6，我們發現規則樹上已經存在了一條我們可以使用的路徑1、2，我們隻需為規則6新增一個節點添加到下面（就是規則樹中的F）。
然後建立一個樣式上下文并将其放到上下文樹中，新的樣式上下文将指向規則樹中的節點F。
現在我們需要填充這個樣式上下文，先從填充margin結構開始，既然最後一個規則節點沒有添加margin結構，沿着路徑向上，直到找到緩存的前面插入節點計算出的結構，我們發現B是最近的指定margin值的節點。因為已經有了color結構的定義，是以不能使用緩存的結構，既然color隻有一個屬性，也就不需要沿着路徑向上填充其他屬性。計算出最終值（将字元串轉換為RGB等），并緩存計算後的結構。
第二個span元素更簡單，進行規則比對後發現它指向規則G，和前一個span一樣，既然有兄弟節點指向同一個節點，就可以共享完整的樣式上下文，隻需指向前一個span的上下文。
因為結構中包含繼承自parent的規則，上下文樹做了緩存（color特性是繼承來的，但Firefox将其視為reset并在規則樹中緩存）。
例如，如果我們為一個paragraph的文字添加規則：
p {font-family:Verdana;font size:10px;font-weight:bold}
那麼這個p在内容樹中的子節點div，會共享和它parent一樣的font結構，這種情況發生在沒有為這個div指定font規則時。
Webkit中，并沒有規則樹，比對的聲明會被周遊四次，先是應用非important的高優先級屬性（之是以先應用這些屬性，是因為其他的依賴于它們－比如display），其次是高優先級important的，接着是一般優先級非important的，最後是一般優先級important的規則。這樣，出現多次的屬性将被按照正确的級聯順序進行處理，最後一個生效。
總結一下，共享樣式對象（結構中完整或部分内容）解決了問題1和3，Firefox的規則樹幫助以正确的順序應用規則。
對規則進行處理以簡化比對過程
樣式規則有幾個來源：
- 外部樣式表或style标簽内的css規則
- 行内樣式屬性
- html可視化屬性（映射為相應的樣式規則）
後面兩個很容易比對到元素，因為它們所擁有的樣式屬性和html屬性可以将元素作為key進行映射。
就像前面問題2所提到的，css的規則比對可能很狡猾，為了解決這個問題，可以先對規則進行處理，以使其更容易被通路。
解析完樣式表之後，規則會根據選擇符添加一些hash映射，映射可以是根據id、class、标簽名或是任何不屬于這些分類的綜合映射。如果選擇符為id，規則将被添加到id映射，如果是class，則被添加到class映射，等等。
這個處理是比對規則更容易，不需要檢視每個聲明，我們能從映射中找到一個元素的相關規則，這個優化使在進行規則比對時減少了95+%的工作量。
來看下面的樣式規則：
p.error {color:red}
#messageDiv {height:50px}
div {margin:5px} 第一條規則将被插入class映射，第二條插入id映射，第三條是标簽映射。
下面這個html片段：
<p class="error">an error occurred </p>
<div id=" messageDiv">this is a message</div> 我們首先找到p元素對應的規則，class映射将包含一個“error”的key，找到p.error的規則，div在id映射和标簽映射中都有相關的規則，剩下的工作就是找出這些由key對應的規則中哪些确實是正确比對的。
例如，如果div的規則是
table div {margin:5px} 這也是标簽映射産生的，因為key是最右邊的選擇符，但它并不比對這裡的div元素，因為這裡的div沒有table祖先。
Webkit和Firefox都會做這個處理。
以正确的級聯順序應用規則
樣式對象擁有對應所有可見屬性的屬性，如果特性沒有被任何比對的規則所定義，那麼一些特性可以從parent的樣式對象中繼承，另外一些使用預設值。
這個問題的産生是因為存在不止一處的定義，這裡用級聯順序解決這個問題。
樣式表的級聯順序
一個樣式屬性的聲明可能在幾個樣式表中出現，或是在一個樣式表中出現多次，是以，應用規則的順序至關重要，這個順序就是級聯順序。根據css2的規範，級聯順序為（從低到高）：
1. 浏覽器聲明
2. 使用者聲明
3. 作者的一般聲明
4. 作者的important聲明
5. 使用者important聲明
浏覽器聲明是最不重要的，使用者隻有在聲明被标記為important時才會覆寫作者的聲明。具有同等級别的聲明将根據specifity以及它們被定義時的順序進行排序。Html可視化屬性将被轉換為比對的css聲明，它們被視為最低優先級的作者規則。
Specifity
Css2規範中定義的選擇符specifity如下：
- 如果聲明來自style屬性，而不是一個選擇器的規則，則計1，否則計0（＝a）
- 計算選擇器中id屬性的數量（＝b）
- 計算選擇器中class及僞類的數量（＝c）
- 計算選擇器中元素名及僞元素的數量（＝d）
連接配接a－b－c－d四個數量（用一個大基數的計算系統）将得到specifity。這裡使用的基數由分類中最高的基數定義。例如，如果a為14，可以使用16進制。不同情況下，a為17時，則需要使用阿拉伯數字17作為基數，這種情況可能在這個選擇符時發生html body div div …（選擇符中有17個标簽，一般不太可能）。
一些例子：
*{}/* 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 */ 規則排序
規則比對後，需要根據級聯順序對規則進行排序，WebKit先将小清單用冒泡排序，再将它們合并為一個大清單，WebKit通過為規則複寫“>”操作來執行排序：
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;
} 逐漸處理Gradual process
webkit使用一個标志位辨別所有頂層樣式表都已加載，如果在attch時樣式沒有完全加載，則放置占位符，并在文檔中标記，一旦樣式表完成加載就重新進行計算。
五、布局（Layout）
當渲染對象被建立并添加到樹中，它們并沒有位置和大小，計算這些值的過程稱為layout或reflow。
Html使用基于流的布局模型，意味着大部分時間，可以以單一的途徑進行幾何計算。流中靠後的元素并不會影響前面元素的幾何特性，是以布局可以在文檔中從右向左、自上而下的進行。也存在一些例外，比如html tables。
坐标系統相對于根frame，使用top和left坐标。
布局是一個遞歸的過程，由根渲染對象開始，它對應html文檔元素，布局繼續遞歸的通過一些或所有的frame層級，為每個需要幾何資訊的渲染對象進行計算。
根渲染對象的位置是0,0，它的大小是viewport－浏覽器視窗的可見部分。
所有的渲染對象都有一個layout或reflow方法，每個渲染對象調用需要布局的children的layout方法。
Dirty bit系統
為了不因為每個小變化都全部重新布局，浏覽器使用一個dirty bit系統，一個渲染對象發生了變化或是被添加了，就标記它及它的children為dirty——需要layout。存在兩個辨別——dirty及children are dirty，children are dirty說明即使這個渲染對象可能沒問題，但它至少有一個child需要layout。
全局和增量layout
當layout在整棵渲染樹觸發時，稱為全局layout，這可能在下面這些情況下發生：
1. 一個全局的樣式改變影響所有的渲染對象，比如字号的改變。
2. 視窗resize。
layout也可以是增量的，這樣隻有标志為dirty的渲染對象會重新布局（也将導緻一些額外的布局）。增量layout會在渲染對象dirty時異步觸發，例如，當網絡接收到新的内容并添加到Dom樹後，新的渲染對象會添加到渲染樹中。
圖20：增量layout
異步和同步layout
增量layout的過程是異步的，Firefox為增量layout生成了reflow隊列，以及一個排程執行這些批處理指令。WebKit也有一個計時器用來執行增量layout－周遊樹，為dirty狀态的渲染對象重新布局。
另外，當腳本請求樣式資訊時，例如“offsetHeight”，會同步的觸發增量布局。
全局的layout一般都是同步觸發。
有些時候，layout會被作為一個初始layout之後的回調，比如滑動條的滑動。
優化
當一個layout因為resize或是渲染位置改變（并不是大小改變）而觸發時，渲染對象的大小将會從緩存中讀取，而不會重新計算。
一般情況下，如果隻有子樹發生改變，則layout并不從根開始。這種情況發生在，變化發生在元素自身并且不影響它周圍元素，例如，将文本插入文本域（否則，每次擊鍵都将觸發從根開始的重排）。
layout過程
layout一般有下面這幾個部分：
1. parent渲染對象決定它的寬度
2. parent渲染對象讀取chilidren，并：
a. 放置child渲染對象（設定它的x和y）
b. 在需要時（它們目前為dirty或是處于全局layout或者其他原因）調用child渲染對象的layout，這将計算child的高度
c. parent渲染對象使用child渲染對象的累積高度，以及margin和padding的高度來設定自己的高度－這将被parent渲染對象的parent使用
d. 将dirty辨別設定為false
Firefox使用一個“state”對象（nsHTMLReflowState）做為參數去布局（firefox稱為reflow），state包含parent的寬度及其他内容。
Firefox布局的輸出是一個“metrics”對象（nsHTMLReflowMetrics）。它包括渲染對象計算出的高度。
寬度計算
渲染對象的寬度使用容器的寬度、渲染對象樣式中的寬度及margin、border進行計算。例如，下面這個div的寬度：
<div />
webkit中寬度的計算過程是（RenderBox類的calcWidth方法）：
- 容器的寬度是容器的可用寬度和0中的最大值，這裡的可用寬度為：contentWidth=clientWidth()-paddingLeft()-paddingRight()，clientWidth和clientHeight代表一個對象内部的不包括border和滑動條的大小
- 元素的寬度指樣式屬性width的值，它可以通過計算容器的百分比得到一個絕對值
- 加上水準方向上的border和padding
到這裡是最佳寬度的計算過程，現在計算寬度的最大值和最小值，如果最佳寬度大于最大寬度則使用最大寬度，如果小于最小寬度則使用最小寬度。最後緩存這個值，當需要layout但寬度未改變時使用。
Line breaking
當一個渲染對象在布局過程中需要折行時，則暫停并告訴它的parent它需要折行，parent将建立額外的渲染對象并調用它們的layout。
六、繪制（Painting）
繪制階段，周遊渲染樹并調用渲染對象的paint方法将它們的内容顯示在螢幕上，繪制使用UI基礎元件，這在UI的章節有更多的介紹。
全局和增量
和布局一樣，繪制也可以是全局的——繪制完整的樹——或增量的。在增量的繪制過程中，一些渲染對象以不影響整棵樹的方式改變，改變的渲染對象使其在螢幕上的矩形區域失效，這将導緻作業系統将其看作dirty區域，并産生一個paint事件，作業系統很巧妙的處理這個過程，并将多個區域合并為一個。Chrome中，這個過程更複雜些，因為渲染對象在不同的程序中，而不是在主程序中。Chrome在一定程度上模拟作業系統的行為，表現為監聽事件并派發消息給渲染根，在樹中查找到相關的渲染對象，重繪這個對象（往往還包括它的children）。
繪制順序
css2定義了繪制過程的順序——http://www.w3.org/TR/CSS21/zindex.html。這個就是元素壓入堆棧的順序，這個順序影響着繪制，堆棧從後向前進行繪制。
一個塊渲染對象的堆棧順序是：
1. 背景色
2. 背景圖
3. border
4. children
5. outline
Firefox顯示清單
Firefox讀取渲染樹并為繪制的矩形建立一個顯示清單，該清單以正确的繪制順序包含這個矩形相關的渲染對象。
用這樣的方法，可以使重繪時隻需查找一次樹，而不需要多次查找——繪制所有的背景、所有的圖檔、所有的border等等。
Firefox優化了這個過程，它不添加會被隐藏的元素，比如元素完全在其他不透明元素下面。
WebKit矩形存儲
重繪前，WebKit将舊的矩形儲存為位圖，然後隻繪制新舊矩形的差集。
七、動态變化
浏覽器總是試着以最小的動作響應一個變化，是以一個元素顔色的變化将隻導緻該元素的重繪，元素位置的變化将大緻元素的布局和重繪，添加一個Dom節點，也會大緻這個元素的布局和重繪。一些主要的變化，比如增加html元素的字号，将會導緻緩存失效，進而引起整數的布局和重繪。
八、渲染引擎的線程
渲染引擎是單線程的，除了網絡操作以外，幾乎所有的事情都在單一的線程中處理，在Firefox和Safari中，這是浏覽器的主線程，Chrome中這是tab的主線程。
網絡操作由幾個并行線程執行，并行連接配接的個數是受限的（通常是2－6個）。
事件循環
浏覽器主線程是一個事件循環，它被設計為無限循環以保持執行過程的可用，等待事件（例如layout和paint事件）并執行它們。下面是Firefox的主要事件循環代碼。
while (!mExiting)
NS_ProcessNextEvent(thread); 九、CSS2可視模型（CSS2 visual module）
畫布The Canvas
根據CSS2規範，術語canvas用來描述格式化的結構所渲染的空間——浏覽器繪制内容的地方。畫布對每個次元空間都是無限大的，但浏覽器基于viewport的大小選擇了一個初始寬度。
根據http://www.w3.org/TR/CSS2/zindex.html的定義，畫布如果是包含在其他畫布内則是透明的，否則浏覽器會指定一個顔色。
CSS盒模型
CSS盒模型描述了矩形盒，這些矩形盒是為文檔樹中的元素生成的，并根據可視的格式化模型進行布局。每個box包括内容區域（如圖檔、文本等）及可選的四周padding、border和margin區域。
每個節點生成0－n個這樣的box。
所有的元素都有一個display屬性，用來決定它們生成box的類型，例如：
block －生成塊狀box
inline －生成一個或多個行内box
none －不生成box
預設的是inline，但浏覽器樣式表設定了其他預設值，例如，div元素預設為block。可以通路http://www.w3.org/TR/CSS2/sample.html檢視更多的預設樣式表示例。
定位政策Position scheme
這裡有三種政策：
1. normal －對象根據它在文檔的中位置定位，這意味着它在渲染樹和在Dom樹中位置一緻，并根據它的盒模型和大小進行布局。
2. float －對象先像普通流一樣布局，然後盡可能的向左或是向右移動。
3. absolute －對象在渲染樹中的位置和Dom樹中位置無關。
static和relative是normal，absolute和fixed屬于absolute。
在static定位中，不定義位置而使用預設的位置。其他政策中，作者指定位置——top、bottom、left、right。
Box布局的方式由這幾項決定：box的類型、box的大小、定位政策及擴充資訊（比如圖檔大小和螢幕尺寸）。
Box類型
Block box：構成一個塊，即在浏覽器視窗上有自己的矩形
Inline box：并沒有自己的塊狀區域，但包含在一個塊狀區域内
block一個挨着一個垂直格式化，inline則在水準方向上格式化。
Inline盒模型放置在行内或是line box中，每行至少和最高的box一樣高，當box以baseline對齊時——即一個元素的底部和另一個box上除底部以外的某點對齊，行高可以比最高的box高。當容器寬度不夠時，行内元素将被放到多行中，這在一個p元素中經常發生。
定位Position
Relative
相對定位——先按照一般的定位，然後按所要求的內插補點移動。
Floats
一個浮動的box移動到一行的最左邊或是最右邊，其餘的box圍繞在它周圍。下面這段html：
<p>
<img src="images/image.gif" width="100" height="100">Lorem ipsum dolor sit amet, consectetuer...
</p> 将顯示為：
Absolute和Fixed
這種情況下的布局完全不顧普通的文檔流，元素不屬于文檔流的一部分，大小取決于容器。Fixed時，容器為viewport（可視區域）。
圖17：fixed
注意－fixed即使在文檔流滾動時也不會移動。
Layered representation
這個由CSS屬性中的z-index指定，表示盒模型的第三個大小，即在z軸上的位置。Box分發到堆棧中（稱為堆棧上下文），每個堆棧中靠後的元素将被較早繪制，棧頂靠前的元素離使用者最近，當發生交疊時，将隐藏靠後的元素。堆棧根據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後面，可能在正常流中也已經被繪制在後面，但z-index有更高優先級，是以在根box的堆棧中更靠前。