瀏覽器的工作原理：新式網絡瀏覽器幕後揭祕

本篇文章的英文原版：How Browsers Work: Behind the Scenes of Modern Web Browsers

本文主要參考和更新自下面兩篇譯文：

• CSND：瀏覽器工作原理詳解
• HTML5 Rocks：瀏覽器的工作原理：新式網絡瀏覽器幕後揭祕

序言

這v是一篇全面介紹 WebKit 和 Gecko 內部操作的入門文章，是以色列開發人員塔利·加希爾大量研究的成果。在過去的幾年中，她查閱了所有公開發布的關於瀏覽器內部機制的數據（請參見參考資料），並花了很多時間來研讀網絡瀏覽器的源代碼。她寫道：

在 IE 佔據 90%市場份額的年代，我們除了把瀏覽器當成一個“黑箱”，什麼也做不了。但是現在，開放源代碼的瀏覽器擁有了過半的市場份額，因此，是時候來揭開神祕的面紗，一探網絡瀏覽器的內幕了。呃，裏面只有數以百萬行計的 C++ 代碼…

塔利在她的網站上公佈了自己的研究成果，但是我們覺得它值得讓更多的人來了解，所以我們在此重新整理並公佈。

作爲一名網絡開發人員，學習瀏覽器的內部工作原理將有助於您作出更明智的決策，並理解那些最佳開發實踐的箇中緣由。儘管這是一篇相當長的文檔，但是我們建議您花些時間來仔細閱讀；讀完之後，您肯定會覺得所費不虛。 —— 保羅·愛麗詩(Paul Irish)，Chrome 瀏覽器開發人員事務部

第一章 簡介

瀏覽器是使用最廣的軟件之一。在這篇博文中，我將介紹瀏覽器的幕後工作原理。通過閱讀本文，我們將會了解，從您在地址欄輸入google.com，直到您在瀏覽器屏幕上看到 Google 首頁的整個過程中都發生了些什麼。

1.1 我們要討論的瀏覽器

目前使用的主流瀏覽器有五個：Internet Explorer、Firefox、Safari、Chrome 瀏覽器和 Opera。本文中以開放源代碼瀏覽器爲例，即 Firefox、Chrome 瀏覽器和 Safari（部分開源）。根據 StatCounter 統計數據，目前（2011 年 8 月）Firefox、Safari 和 Chrome 瀏覽器的總市場佔有率將近 60%。由此可見，如今開放源代碼瀏覽器在瀏覽器市場中佔據了非常堅實的部分。

1.2 瀏覽器的主要功能

瀏覽器的主要功能就是向服務器發出請求，在瀏覽器窗口中展示您選擇的網絡資源。這裏所說的資源一般是指 HTML 文檔，也可以是 PDF、圖片或其他的類型。資源的位置由用戶使用 URI（統一資源標示符）指定。

瀏覽器解釋並顯示 HTML 文件的方式是在 HTML 和 CSS 規範中指定的。這些規範由網絡標準化組織 W3C（萬維網聯盟）進行維護。
多年以來，各瀏覽器都沒有完全遵從這些規範，同時還在開發自己獨有的擴展程序，這給網絡開發人員帶來了嚴重的兼容性問題。如今，大多數的瀏覽器都是或多或少地遵從規範。

瀏覽器的用戶界面有很多彼此相同的元素，其中包括：

• 用來輸入 URI 的地址欄
• 前進和後退按鈕
• 書籤設置選項
• 用於刷新和停止加載當前文檔的刷新和停止按鈕
• 用於返回主頁的主頁按鈕

奇怪的是，瀏覽器的用戶界面並沒有任何正式的規範，這是多年來的最佳實踐自然發展以及彼此之間相互模仿的結果。HTML5 也沒有定義瀏覽器必須具有的用戶界面元素，但列出了一些通用的元素，例如地址欄、狀態欄和工具欄等。當然，各瀏覽器也可以有自己獨特的功能，比如 Firefox 的下載管理器。

1.3 瀏覽器的高層結構(High Level Structure)

瀏覽器的主要組件包括：

• 用戶界面：包括地址欄、前進/後退按鈕、書籤菜單等。除了瀏覽器主窗口顯示的你請求的頁面外，其他顯示的各個部分都屬於用戶界面。
• 瀏覽器引擎：在用戶界面和渲染引擎之間傳送指令。
• 渲染引擎：負責顯示請求的內容。如果請求的內容是 HTML，它就負責解析 HTML 和 CSS 內容，並將解析後的內容顯示在屏幕上。
• 網絡：用於網絡調用，比如 HTTP 請求。其接口與平臺無關，併爲所有平臺提供底層實現。
• 用戶界面後端：用於繪製基本的窗口小部件，比如組合框和窗口。其公開了與平臺無關的通用接口，而在底層使用操作系統的用戶界面方法。
• JavaScript 解釋器：用於解析和執行 JavaScript 代碼，比如chrome的javascript解釋器是V8。
• 數據存儲：這是持久層。瀏覽器需要在硬盤上保存各種數據，例如 Cookie。新的 HTML 規範 (Html5)定義了“網絡數據庫”，這是一個完整（但是輕便）的瀏覽器內數據庫。

圖1.1：瀏覽器的主要組件

值得注意的是，不同於大多數瀏覽器，Chrome 瀏覽器爲每個標籤頁(Tab)都分配了各自的渲染引擎實例，每個標籤頁都是一個獨立的進程（即每個標籤頁面都在獨立的“沙箱”內運行，在提高安全性的同時，一個標籤頁面的崩潰也不會導致其他標籤頁面被關閉）。

第二章 渲染引擎(The rendering engine)

渲染引擎的職責就是渲染，即在瀏覽器窗口中顯示所請求的內容。這是每一個瀏覽器的核心部分，所以渲染引擎也稱爲瀏覽器內核。

默認情況下，渲染引擎可顯示 HTML 和 XML 文檔及圖片。通過插件（或瀏覽器擴展程序），還瀏覽器渲染引擎也可以顯示其它類型的內容。例如，使用 PDF 查看器插件就能顯示 PDF 文檔。在本章中，我們將集中介紹其主要用途：顯示應用了CSS的 HTML 內容和圖片。

2.1 渲染引擎簡介

本文所討論的瀏覽器（Firefox、Chrome和Safari）是基於兩種渲染引擎構建的。Firefox 使用的是 Gecko，這是 Mozilla 公司“自制”的渲染引擎。而 Safari 和 Chrome(28版本以前)瀏覽器使用的都是 Webkit。

2013年7月10日發佈的Chrome 28 版本中，Chrome瀏覽器開始正式使用Blink內核。所以，Webkit已經成爲了Chrome瀏覽器的前內核。

Webkit 是一種開放源代碼渲染引擎，起初用於 Linux 平臺，隨後由 Apple 公司進行修改，從而支持蘋果機和 Windows。有關詳情，請參閱 webkit.org。

2.2 主流程(The main flow)

渲染引擎一開始會從網絡層獲取請求文檔的內容，通常以8K分塊的方式完成。 獲取了文檔內容之後，渲染引擎開始正式工作，其基本流程：

圖2.1：渲染引擎的基本流程。

渲染引擎解析HTML文檔，並將文檔中的標籤轉化爲dom節點樹，即”內容樹”。同時，它也會解析外部CSS文件以及style標籤中的樣式數據。這些樣式信息連同HTML中的”可見內容”一道，被用於構建另一棵樹——”渲染樹(Render樹)”。

渲染樹由一些帶有視覺屬性(如顏色、大小等)的矩形組成，這些矩形將按照正確的順序顯示在頻幕上。

渲染樹構建完畢之後，將會進入”佈局”處理階段，即爲每一個節點分配一個屏幕座標。再下一步就是繪製(painting)，即遍歷render樹，並使用UI後端層繪製每個節點。

值得注意的是，這個過程是逐步完成的，爲了更好的用戶體驗，渲染引擎將會儘可能早的將內容呈現到屏幕上，並不會等到所有的html都解析完成之後再去構建和佈局render樹。它是解析完一部分內容就顯示一部分內容，同時，可能還在通過網絡下載其餘內容。

2.3 主流程示例

圖2.2：Webkit 主流程

圖2.3：Mozilla 的 Gecko 渲染引擎主流程

從圖2.2 和圖2.3可以看出，雖然 Webkit 和 Gecko 使用的術語略有不同，但整體流程還是基本相同的。

Gecko將視覺格式化元素組成的樹稱爲”框架樹”(frame)。每個元素都是一個框架。Webkit使用的術語是”渲染樹”(render)，它由”渲染對象”組成。對於元素的放置，Webkit 使用的術語是”佈局”(layout)，而 Gecko 稱之爲”重排”(reflow)。Webkit稱利用dom節點及樣式信息去構建render樹的過程爲attachment，Gecko在html和dom樹之間附加了一層，這層稱爲內容接收器，相當製造dom元素的工廠。我們會逐一論述流程中的每一部分。

第三章 解析與DOM樹構建(Parsing and DOM tree construction)

3.1 解析綜述(Parsing-general)

既然解析是渲染引擎中一個非常重要的過程，我們將稍微深入的研究它。首先明白什麼叫做解析(parsing)。

解析一個文檔就是指將這個文檔翻譯成一個可以讓代碼理解和使用的有意義的結構。得到的結構通常是一個代表了該文檔結構的節點樹，通常稱之爲解析樹或語法樹。

例如， 解析“2＋3-1”這個表達式，可能返回這樣一棵樹。
　　

圖3.1：數學表達式樹節點

3.1.1 語法(Grammars)

解析是以文檔所遵循的語法規則(編寫文檔所用的語言或格式)爲基礎的。所有可以解析的格式都必須對應確定的語法(由詞彙和語法規則構成)。這稱爲與上下文無關的文法。人類語言並不屬於這樣的語言，因此無法用常規的解析技術進行解析。

3.1.2 解析器-詞法分析器(Parser－Lexer combination)

解析的過程可以分成兩個子過程：詞法分析和語法分析。

• 詞法分析是將輸入內容分割成大量標記的過程。標記是語言中的詞彙，即構成內容的單位。在人類語言中，它相當於語言字典中的單詞。
• 語法分析是應用語言的語法規則的過程。

解析工作一般由兩個組件共同完成：

• 詞法分析器（有時也稱爲標記生成器）：負責將輸入內容分解成一個個有效標記。詞法分析器知道如何將無關的字符（比如空格和換行符）分離出來。
• 解析器：負責根據語言的語法規則分析文檔的結構，從而構建解析樹。

圖3.2：從源文檔到解析樹

解析是一個迭代的過程。通常，解析器會向詞法分析器請求一個新標記，並嘗試將其與某條語法規則進行匹配。如果發現了匹配規則，解析器會將一個對應於該標記的節點添加到解析樹中，然後繼續請求下一個標記。

如果沒有規則可以匹配，解析器就會將標記存儲到內部，並繼續請求標記，直至找到可與所有內部存儲的標記匹配的規則。如果找不到任何匹配規則，解析器就會引發一個異常。這意味着文檔無效，包含語法錯誤。

3.1.3 轉換(Translation)

很多時候，解析樹還不是最終結果。解析通常是在轉換過程中使用的，而轉換是指將輸入文檔轉換成另一種格式。編譯就是一個例子。編譯器可將源代碼編譯成機器代碼，具體過程是首先將源代碼解析成解析樹，然後將解析樹翻譯成機器代碼文檔。

圖3.3：編譯流程

3.1.4 解析示例(Parsing example)

在圖3.1中，我們通過一個數學表達式建立了解析樹。現在，讓我們試着定義一個簡單的數學語言，用來演示解析的過程。

詞彙表：整數、加號、減號
語法規則：

• 構成語言的語法單位是表達式、項和運算符。
• 該語言可以包括多個表達式。
• 一個表達式定義爲兩個項通過一個操作符連接。
• 運算符可以是加號或減號。
• 項可以是一個整數或一個表達式。

現在來分析一下”2＋3－1”這個輸入。
匹配語法規則的第一個子串是2，而根據第5條語法規則，這是一個項。匹配語法規則的第二個子串是 2 + 3，而根據第 3 條規則（一個項接一個運算符，然後再接一個項），這是一個表達式。下一個匹配項已經到了輸入的結束。2 + 3 - 1 是一個表達式，因爲我們已經知道 2 + 3 是一個項，這樣就符合“一個項接一個運算符，然後再接一個項”的規則。2 + +不與任何規則匹配，因此是無效的輸入。

3.1.5 詞彙和語法的正式定義

1) 詞彙通常用正則表達式表示。

例如，我們的示例語言可以定義如下：

INTEGER :0|[1-9][0-9]*
PLUS : +
MINUS: -

正如您所看到的，這裏用正則表達式給出了整數的定義。

2) 語法通常使用一種稱爲 BNF 的格式來定義。

我們的示例語言可以定義如下：

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

之前我們說過，如果語言的語法是與上下文無關的語法，就可以由常規解析器進行解析。

與上下文無關的語法的直觀定義就是可以完全用BNF格式表達的語法。有關正式定義，請參閱關於與上下文無關的語法的維基百科文章。

3.1.6 解析器類型

有兩種基本類型的解析器：自上而下解析器和自下而上解析器。直觀地來說，自上而下的解析器從語法的高層結構出發，嘗試從中找到匹配的結構。而自下而上的解析器從低層規則出發，將輸入內容逐步轉化爲語法規則，直至滿足高層規則。

讓我們來看看這兩種解析器會如何解析我們的示例：

自頂向下解析器從最高層規則開始——它先識別出”2+3”，將其視爲一個表達式，然後識別出”2+3-1”爲一個表達式(識別表達式的過程中匹配了其他規則，但起點是最高層規則)。

自下而上的解析器將掃描輸入內容，找到匹配的規則後，將匹配的輸入內容替換成規則。如此繼續替換，直到輸入內容的結尾。部分匹配的表達式保存在解析器的堆棧中。

堆棧(Stack)	輸入(Input)
	2+3-1
項	2+3-1
項運算	3-1
表達式	-1
表達式運算符	1
表達式	-

這種自下而上的解析器稱爲移位歸約解析器，因爲輸入在向右移位（設想有一個指針從輸入內容的開頭移動到結尾），並逐漸簡化語法規則。

3.1.7 自動生成解析器(Generating parsers automatically)

解析器生成器這個工具可以自動生成解析器，只需要指定語言的文法———詞彙表及語法規則，它就可以生成一個解析器。創建一個解析器需要對解析有深入的理解，而且手動的創建一個有較好性能的解析器並不容易，所以解析生成器很有用。
　　
Webkit使用兩個知名的解析生成器——用於創建語法分析器的Flex及創建解析器的Bison（你可能接觸過Lex和Yacc）。Flex的輸入是一個包含了符號定義的正則表達式，Bison的輸入是用BNF格式表示的語法規則。

3.2 HTML 解析器(HTML Parser)

HTML 解析器的任務是將 HTML 標記解析成解析樹。

3.2.1 HTML 語法定義(The HTML grammar definition)

W3C組織制定規範定義了HTML的詞彙表和語法。當前的版本是 HTML4，HTML5 正在處理過程中（當時）。

3.2.2 非上下文無關的語法(Not a context free grammar)

正如在解析簡介中提到的，上下文無關文法的語法可以用類似BNF的格式來定義。

很遺憾，所有的常規解析器都不適用於 HTML（我並不是開玩笑，它們可以用於解析 CSS 和 JavaScript）。HTML 並不能用解析器所需的與上下文無關的語法來定義。 Html有一個正式的格式定義：DTD(Document Type Definition，文檔類型定義)，但它並不是上下文無關的語法。

這初看起來很奇怪：HTML 和 XML 非常相似。有很多 XML 解析器可以使用。HTML 存在一個 XML 變體 (XHTML)，那麼有什麼大的區別呢？區別在於 HTML 的處理更爲“寬容”，它允許您省略某些隱式添加的標記，有時還能省略一些起始或者結束標記等等。和 XML 嚴格的語法不同，HTML 整體來看是一種“軟性”的語法。

顯然，這種看上去細微的差別實際上卻帶來了巨大的影響。一方面，這是 HTML 如此流行的原因：它能包容您的錯誤，簡化網絡開發。另一方面，這使得它很難編寫正式的語法。概括地說，HTML 無法很容易地通過常規解析器解析（因爲它的語法不是與上下文無關的語法），也無法通過 XML 解析器來解析。

3.2.3 HTML DTD

HTML的定義採用了DTD格式。此格式適用於定義SGML族的語言。它包括所有允許使用的元素及其屬性和層次結構的定義。如上文所述，HTML DTD無法構成與上下文無關的語法。

DTD存在一些變體。嚴格模式完全遵守HTML規範，而其他模式可支持以前的瀏覽器所使用的標記。這樣做的目的是確保向下兼容一些早期版本的內容。最新的嚴格模式DTD可以在這裏找到：www.w3.org/TR/html4/strict.dtd 。

3.2.4 DOM

解析器的輸出(即”解析樹”)是由DOM元素及屬性節點組成的。DOM是文檔對象模型(Document Object Model) 的縮寫。它是HTML文檔的對象表示，同時也是外部內容(例如 JavaScript)與HTML元素之間的接口。解析樹的根節點是”Document”對象。DOM與標記之間幾乎是一一對應的關係。比如下面這段標記：

<html>
  <body>
    <p>
      Hello World
    </p>
    <div> <img src="example.png"/></div>
  </body>
</html>

可翻譯成如下的 DOM 樹：

圖3.4：示例標記的 DOM 樹

和HTML一樣，DOM也是由W3C組織制定的。請參見：www.w3.org/DOM/DOMTR 。這是關於文檔操作的通用規範。其中一個特定模塊描述針對HTML的元素。HTML的定義可以在這裏找到：www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/idl-definitions.html 。

這裏所說的DOM節點樹，指的是那些實現了DOM接口的元素組成的樹。

3.2.5 解析算法(The parsing algorithm)

我們在之前章節已經說過，HTML無法用常規的自上而下或自下而上的解析器進行解析。原因在於：

• 語言本身的寬容特性；
• 瀏覽器對一些常見的非法html有容錯機制；
• 解析過程需要不斷地反覆。源內容在解析過程中通常不會改變，但是在HTML中，腳本標記如果包含 “document.write”，就會添加額外的標記，這樣解析過程實際上就更改了輸入內容。

由於不能使用常規的解析技術，瀏覽器爲html定製了專屬的解析器。 HTML5規範詳細地描述瞭解析算法。此算法由兩個階段組成：符號化及構建樹。

符號化是詞法分析的過程，將輸入內容解析成多個標記，HTML標記包括起始標記、結束標記、屬性名稱和屬性值。標記生成器識別標記，傳遞給樹構造器，然後讀取下一個字符以識別下一個標記，如此反覆直到輸入的結束。

圖3.5：HTML 解析流程

3.2.6 符號識別算法(The tokenization algorithm)

該算法的輸出結果是HTML標記。該算法使用狀態機來表示。每一個狀態接收來自輸入信息流的一個或多個字符，並根據這些字符更新下一個狀態。當前的標記化狀態和樹結構狀態會影響進入下一狀態的決定。這意味着，即使接收的字符相同，對於下一個正確的狀態也會產生不同的結果，具體取決於當前的狀態。該算法相當複雜，無法在此詳述，所以我們通過一個簡單的示例來幫助大家理解其原理。

基本示例 - 將下面的 HTML 代碼標記化：

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

初始狀態是數據狀態。遇到字符 < 時，狀態更改爲“標記打開狀態”。接收一個 a-z字符會創建“起始標記”，狀態更改爲“標記名稱狀態”。這個狀態會一直保持到接收> 字符。在此期間接收的每個字符都會附加到新的標記名稱上。在本例中，我們創建的標記是 html 標記。

遇到 > 標記時，會發送當前的標記，狀態改回“數據狀態”。 標記也會進行同樣的處理。目前 html 和 body 標記均已發出。現在我們回到“數據狀態”。接收到 Hello world 中的 H 字符時，將創建併發送字符標記，直到接收 中的<。我們將爲 Hello world 中的每個字符都發送一個字符標記。

現在我們回到“標記打開狀態”。接收下一個輸入字符 / 時，會創建 end tag token 並改爲“標記名稱狀態”。我們會再次保持這個狀態，直到接收 >。然後將發送新的標記，並回到“數據狀態”。 輸入也會進行同樣的處理。

圖3.6：對示例輸入進行標記化

3.2.7 樹構建算法

在創建解析器的同時，也會創建 Document 對象。在樹構建階段，以 Document 爲根節點的 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，同時模式轉變爲“body”。

現在，接收由“Hello world”字符串生成的一系列字符標記。接收第一個字符時會創建並插入“Text”節點，而其他字符也將附加到該節點。

接收 body 結束標記會觸發“after body”模式。現在我們將接收 HTML 結束標記，然後進入“after after body”模式。接收到文件結束標記後，解析過程就此結束。

圖3.7：示例 HTML 的樹構建

3.2.8 解析結束後的操作

在此階段，瀏覽器會將文檔標註爲交互狀態，並開始解析那些處於“deferred”模式的腳本，也就是那些應在文檔解析完成後才執行的腳本。然後，文檔狀態將設置爲“完成”，一個“加載”事件將隨之觸發。

您可以在 HTML5 規範 中查看標記化和樹構建的完整算法。

3.2.9 瀏覽器的容錯機制

您在瀏覽 HTML 網頁時從來不會看到“語法無效”的錯誤。這是因爲瀏覽器會糾正任何無效內容，然後繼續工作。

以下面的 HTML 代碼爲例：

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

在這裏，我已經違反了很多語法規則（“mytag”不是標準的標記，“p”和“div”元素之間的嵌套有誤等等），但是瀏覽器仍然會正確地顯示這些內容，並且毫無怨言。因爲有大量的解析器代碼會糾正 HTML 網頁作者的錯誤。

不同瀏覽器的錯誤處理機制相當一致，但令人稱奇的是，這種機制並不是 HTML 當前規範的一部分。和書籤管理以及前進/後退按鈕一樣，它也是瀏覽器在多年發展中的產物。很多網站都普遍存在着一些已知的無效 HTML 結構，每一種瀏覽器都會嘗試通過和其他瀏覽器一樣的方式來修復這些無效結構。

HTML5 規範定義了一部分這樣的要求。Webkit 在 HTML 解析器類的開頭註釋中對此做了很好的概括。

解析器對標記化輸入內容進行解析，以構建文檔樹。如果文檔的格式正確，就直接進行解析。

遺憾的是，我們不得不處理很多格式錯誤的 HTML 文檔，所以解析器必須具備一定的容錯性。

我們至少要能夠處理以下錯誤情況：

• 明顯不能在某些外部標記中添加的元素。在此情況下，我們應該關閉所有標記，直到出現禁止添加的元素，然後再加入該元素。
• 我們不能直接添加的元素。這很可能是網頁作者忘記添加了其中的一些標記（或者其中的標記是可選的）。這些標籤可能包括：HTML HEAD BODY TBODY TR TD LI（還有遺漏的嗎？）。
• 向 inline 元素內添加 block 元素。關閉所有 inline 元素，直到出現下一個較高級的 block 元素。
• 如果這樣仍然無效，可關閉所有元素，直到可以添加元素爲止，或者忽略該標記。

讓我們看一些 Webkit 容錯的示例：

1) 使用了</br>而不是<br>

有些網站使用了</br>而不是<br>。爲了與 IE 和 Firefox 兼容，Webkit 將其與<br>做同樣的處理。 代碼如下：

if (t->isCloseTag(brTag) && m_document->inCompatMode()) {
     reportError(MalformedBRError);
     t->beginTag = true;
}<span class="kwd"> </span>

請注意，錯誤處理是在內部進行的，用戶並不會看到這個過程。

2) 離散表格

離散表格是指位於其他表格內容中，但又不在任何一個單元格內的表格。 比如以下的示例：

<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 使用一個堆棧來保存當前的元素內容，它會從外部表格的堆棧中彈出內部表格。現在，這兩個表格就變成了同級關係。

3) 嵌套的表單元素

如果用戶在一個表單元素中又放入了另一個表單，那麼第二個表單將被忽略。 代碼如下：

if (!m_currentFormElement) {
        m_currentFormElement = new HTMLFormElement(formTag,    m_document);
}<span class="kwd"> </span>

4) 過於複雜的標記層次結構

代碼的註釋已經說得很清楚了。

示例網站 www.liceo.edu.mx 嵌套了約 1500 個標記，全都來自一堆<b>標記。我們只允許最多 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;
}

5) 放錯位置的 html 或者 body 結束標記。

同樣，代碼的註釋已經說得很清楚了。

支持格式非常糟糕的 HTML 代碼。我們從不關閉 body 標記，因爲一些愚蠢的網頁會在實際文檔結束之前就關閉。我們通過調用 end() 來執行關閉操作。

if (t->tagName == htmlTag || t->tagName == bodyTag )
        return;

所以網頁作者需要注意，除非您想作爲反面教材出現在 Webkit 容錯代碼段的示例中，否則還請編寫格式正確的 HTML 代碼。

3.3 CSS 解析

還記得簡介中解析的概念嗎？和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”是標識符 (identifier) 的縮寫，比如類名。”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*] ')' ]
  ;<span class="kwd"> </span>

解釋：這是一個規則集的結構：

div.error , a.error {
  color:red;
  font-weight:bold;
}

div.error 和 a.error 是選擇器。大括號內的部分包含了由此規則集應用的規則。此結構的正式定義是這樣的：

ruleset
  : selector [ ',' S* selector ]*
    '{' S* declaration [ ';' S* declaration ]* '}' S*
  ;

這表示一個規則集就是一個選擇器，或者由逗號和空格（S 表示空格）分隔的多個（數量可選）選擇器。規則集包含了大括號，以及其中的一個或多個（數量可選）由分號分隔的聲明。“聲明”和“選擇器”將由下面的 BNF 格式定義。

3.3.1 Webkit CSS 解析器

Webkit 使用 Flex 和 Bison 解析器生成器，通過 CSS 語法文件自動創建解析器。正如我們之前在解析器簡介中所說，Bison 會創建自下而上的移位歸約解析器。Firefox 使用的是人工編寫的自上而下的解析器。這兩種解析器都會將 CSS 文件解析成 StyleSheet 對象，且每個對象都包含 CSS 規則。CSS 規則對象則包含選擇器和聲明對象，以及其他與 CSS 語法對應的對象。

圖3.8：解析 CSS

3.4 處理腳本和樣式表的順序

3.4.1 腳本

網絡的模型是同步的。網頁作者希望解析器遇到<script> 標記時立即解析並執行腳本。文檔的解析將停止，直到腳本執行完畢。如果腳本是外部的，那麼解析過程會停止，直到從網絡同步抓取資源完成後再繼續。此模型已經使用了多年，也在 HTML4 和 HTML5 規範中進行了指定。作者也可以將腳本標註爲“defer”，這樣它就不會停止文檔解析，而是等到解析結束才執行。HTML5 增加了一個選項，可將腳本標記爲異步，以便由其他線程解析和執行。

3.4.2 預解析

Webkit 和 Firefox 都進行了這項優化。在執行腳本時，其他線程會解析文檔的其餘部分，找出並加載需要通過網絡加載的其他資源。通過這種方式，資源可以在並行連接上加載，從而提高總體速度。請注意，預解析器不會修改 DOM 樹，而是將這項工作交由主解析器處理；預解析器只會解析外部資源（例如外部腳本、樣式表和圖片）的引用。

3.4.3 樣式表

另一方面，樣式表有着不同的模型。理論上來說，應用樣式表不會更改 DOM 樹，因此似乎沒有必要等待樣式表並停止文檔解析。但這涉及到一個問題，就是腳本在文檔解析階段會請求樣式信息。如果當時還沒有加載和解析樣式，腳本就會獲得錯誤的回覆，這樣顯然會產生很多問題。這看上去是一個非典型案例，但事實上非常普遍。Firefox 在樣式表加載和解析的過程中，會禁止所有腳本。而對於 Webkit 而言，僅當腳本嘗試訪問的樣式屬性可能受尚未加載的樣式表影響時，它纔會禁止該腳本。

第四章 渲染樹樹構建

在 DOM 樹構建的同時，瀏覽器還會構建另一個樹結構：渲染樹。這是由可視化元素按照其顯示順序而組成的樹，也是文檔的可視化表示。它的作用是讓您按照正確的順序繪製內容。

Firefox 將渲染樹中的元素稱爲“框架”。Webkit 使用的術語是呈現器或呈現對象。

呈現器知道如何佈局並將自身及其子元素繪製出來。

Webkits RenderObject 類是所有呈現器的基類，其定義如下：

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 屬性的不同，針對同一個 DOM 節點應創建什麼類型的呈現器。

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方法。呈現器所指向的樣式對象中包含了一些和幾何無關的信息。

4.1 渲染樹和 DOM 樹的關係

呈現器是和 DOM 元素相對應的，但並非一一對應。非可視化的 DOM 元素不會插入渲染樹中，例如“head”元素。如果元素的 display 屬性值爲“none”，那麼也不會顯示在渲染樹中（但是 visibility 屬性值爲“hidden”的元素仍會顯示）。
　　有一些 DOM 元素對應多個可視化對象。它們往往是具有複雜結構的元素，無法用單一的矩形來描述。例如，“select”元素有 3 個呈現器：一個用於顯示區域，一個用於下拉列表框，還有一個用於按鈕。如果由於寬度不夠，文本無法在一行中顯示而分爲多行，那麼新的行也會作爲新的呈現器而添加。
另一個關於多呈現器的例子是格式無效的 HTML。根據 CSS 規範，inline 元素只能包含 block 元素或 inline 元素中的一種。如果出現了混合內容，則應創建匿名的 block 呈現器，以包裹 inline 元素。

有一些呈現對象對應於 DOM 節點，但在樹中所在的位置與 DOM 節點不同。浮動定位和絕對定位的元素就是這樣，它們處於正常的流程之外，放置在樹中的其他地方，並映射到真正的框架，而放在原位的是佔位框架。

圖4.1：渲染樹及其對應的 DOM 樹。

初始容器 block 爲“viewport”，而在 Webkit 中則爲“RenderView”對象。

4.2 構建渲染樹的流程

在 Firefox 中，系統會針對 DOM 更新註冊展示層，作爲偵聽器。展示層將框架創建工作委託給 FrameConstructor，由該構造器解析樣式（請參閱下面的樣式計算）並創建框架。

在 Webkit 中，解析樣式和創建呈現器的過程稱爲“附加”。每個 DOM 節點都有一個“attach”方法。附加是同步進行的，將節點插入 DOM 樹需要調用新的節點“attach”方法。

處理 html 和 body 標記就會構建渲染樹根節點。這個根節點呈現對象對應於 CSS 規範中所說的容器 block，這是最上層的 block，包含了其他所有 block。它的尺寸就是視口，即瀏覽器窗口顯示區域的尺寸。Firefox 稱之爲 ViewPortFrame，而 Webkit 稱之爲 RenderView。這就是文檔所指向的呈現對象。渲染樹的其餘部分以 DOM 樹節點插入的形式來構建。

請參閱關於處理模型的 CSS2 規範。

4.3 樣式計算

構建渲染樹時，需要計算每一個呈現對象的可視化屬性。這是通過計算每個元素的樣式屬性來完成的。

樣式包括來自各種來源的樣式表、inline 樣式元素和 HTML 中的可視化屬性（例如“bgcolor”屬性）。其中後者將經過轉化以匹配 CSS 樣式屬性。

樣式表的來源包括瀏覽器的默認樣式表、由網頁作者提供的樣式表以及由瀏覽器用戶提供的用戶樣式表（瀏覽器允許您定義自己喜歡的樣式。以 Firefox 爲例，用戶可以將自己喜歡的樣式表放在“Firefox Profile”文件夾下）。

樣式計算存在以下難點：

1) 樣式數據是一個超大的結構，存儲了無數的樣式屬性，這可能造成內存問題。

2) 如果不進行優化，爲每一個元素查找匹配的規則會造成性能問題。要爲每一個元素遍歷整個規則列表來尋找匹配規則，這是一項浩大的工程。選擇器會具有很複雜的結構，這就會導致某個匹配過程一開始看起來很可能是正確的，但最終發現其實是徒勞的，必須嘗試其他匹配路徑。例如下面這個組合選擇器：

div div div div{…} 

這意味着規則適用於作爲 3 個 div 元素的子代的 <div>。如果您要檢查規則是否適用於某個指定的 <div>元素，應選擇樹上的一條向上路徑進行檢查。您可能需要向上遍歷節點樹，結果發現只有兩個 div，而且規則並不適用。然後，您必須嘗試樹中的其他路徑。

3) 應用規則涉及到相當複雜的層疊規則（用於定義這些規則的層次）。

讓我們來看看瀏覽器是如何處理這些問題的：
　　

4.3.1 共享樣式數據

Webkit 節點會引用樣式對象 (RenderStyle)。這些對象在某些情況下可以由不同節點共享。這些節點是同級關係，並且：

• 這些元素必須處於相同的鼠標狀態（例如，不允許其中一個是“:hover”狀態，而另一個不是） 。
• 任何元素都沒有 ID 。
• 標記名稱應匹配 。
• 類屬性應匹配 。
• 映射屬性的集合必須是完全相同的 。
• 鏈接狀態必須匹配 。
• 焦點狀態必須匹配 。
• 任何元素都不應受屬性選擇器的影響，這裏所說的“影響”是指在選擇器中的任何位置有任何使用了屬性選擇器的選擇器匹配 。
• 元素中不能有任何 inline 樣式屬性 。
• 不能使用任何同級選擇器。WebCore 在遇到任何同級選擇器時，只會引發一個全局開關，並停用整個文檔的樣式共享（如果存在）。這包括 + 選擇器以及 :first-child 和 :last-child 等選擇器。

4.3.2 Firefox 規則樹

爲了簡化樣式計算，Firefox 還採用了另外兩種樹：規則樹和樣式上下文樹。Webkit 也有樣式對象，但它們不是保存在類似樣式上下文樹這樣的樹結構中，只是由 DOM 節點指向此類對象的相關樣式。

圖4.1：Firefox 樣式上下文樹

樣式上下文包含端值。要計算出這些值，應按照正確順序應用所有的匹配規則，並將其從邏輯值轉化爲具體的值。例如，如果邏輯值是屏幕大小的百分比，則需要換算成絕對的單位。規則樹的點子真的很巧妙，它使得節點之間可以共享這些值，以避免重複計算，還可以節約空間。

所有匹配的規則都存儲在樹中。路徑中的底層節點擁有較高的優先級。規則樹包含了所有已知規則匹配的路徑。規則的存儲是延遲進行的。規則樹不會在開始的時候就爲所有的節點進行計算，而是隻有當某個節點樣式需要進行計算時，纔會向規則樹添加計算的路徑。

這個想法相當於將規則樹路徑視爲詞典中的單詞。如果我們已經計算出如下的規則樹：

圖4.2：規則樹

假設我們需要爲內容樹中的另一個元素匹配規則，並且找到匹配路徑是 B - E - I（按照此順序）。由於我們在樹中已經計算出了路徑 A - B - E - I - L，因此就已經有了此路徑，這就減少了現在所需的工作量。

讓我們看看規則樹如何幫助我們減少工作。

1) 結構劃分

樣式上下文可分割成多個結構。這些結構體包含了特定類別（如 border 或 color）的樣式信息。結構中的屬性都是繼承的或非繼承的。繼承屬性如果未由元素定義，則繼承自其父代。非繼承屬性（也稱爲“重置”屬性）如果未進行定義，則使用默認值。

規則樹通過緩存整個結構（包含計算出的端值）爲我們提供幫助。這一想法假定底層節點沒有提供結構的定義，則可使用上層節點中的緩存結構。

2) 使用規則樹計算樣式上下文

在計算某個特定元素的樣式上下文時，我們首先計算規則樹中的對應路徑，或者使用現有的路徑。然後我們沿此路徑應用規則，在新的樣式上下文中填充結構。我們從路徑中擁有最高優先級的底層節點（通常也是最特殊的選擇器）開始，並向上遍歷規則樹，直到結構填充完畢。如果該規則節點對於此結構沒有任何規範，那麼我們可以實現更好的優化：尋找路徑更上層的節點，找到後指定完整的規範並指向相關節點即可。這是最好的優化方法，因爲整個結構都能共享。這可以減少端值的計算量並節約內存。

如果我們找到了部分定義，就會向上遍歷規則樹，直到結構填充完畢。

如果我們找不到結構的任何定義，那麼假如該結構是“繼承”類型，我們會在上下文樹中指向父代的結構，這樣也可以共享結構。如果是 reset 類型的結構，則會使用默認值。

如果最特殊的節點確實添加了值，那麼我們需要另外進行一些計算，以便將這些值轉化成實際值。然後我們將結果緩存在樹節點中，供子代使用。

如果某個元素與其同級元素都指向同一個樹節點，那麼它們就可以共享整個樣式上下文。

讓我們來看一個例子，假設我們有如下 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"> very  big  error</span> error
      </p>
    </div>
    <div class="err" id="div2">another error</div>
  </body>
</html>

還有如下規則：

div {margin:5px;color:black}
.err {color:red}
.big {margin-top:3px}
div span {margin-bottom:4px}
#div1 {color:blue}
#div2 {color:green}

爲了簡便起見，我們只需要填充兩個結構：color 結構和 margin 結構。color 結構只包含一個成員（即“color”），而 margin 結構包含四條邊。 形成的規則樹如下圖所示（節點的標記方式爲“節點名 : 指向的規則序號”）：

圖4.3：規則樹

上下文樹如下圖所示（節點名 : 指向的規則節點）：

圖4.3：上下文樹

假設我們解析 HTML 時遇到了第二個<div>標記，我們需要爲此節點創建樣式上下文，並填充其樣式結構。

經過規則匹配，我們發現該<div>的匹配規則是第 1、2 和 6 條。這意味着規則樹中已有一條路徑可供我們的元素使用，我們只需要再爲其添加一個節點以匹配第 6 條規則（規則樹中的 F 節點）。

我們將創建樣式上下文並將其放入上下文樹中。新的樣式上下文將指向規則樹中的 F 節點。

現在我們需要填充樣式結構。首先要填充的是 margin 結構。由於最後的規則節點 (F) 並沒有添加到 margin 結構，我們需要上溯規則樹，直至找到在先前節點插入中計算過的緩存結構，然後使用該結構。我們會在指定 margin 規則的最上層節點（即 B 節點）上找到該結構。

我們已經有了 color 結構的定義，因此不能使用緩存的結構。由於 color 有一個屬性，我們無需上溯規則樹以填充其他屬性。我們將計算端值（將字符串轉化爲 RGB 等）並在此節點上緩存經過計算的結構。

第二個<span>元素處理起來更加簡單。我們將匹配規則，最終發現它和之前的 span 一樣指向規則 G。由於我們找到了指向同一節點的同級，就可以共享整個樣式上下文了，只需指向之前 span 的上下文即可。

對於包含了繼承自父代的規則的結構，緩存是在上下文樹中進行的（事實上 color 屬性是繼承的，但是 Firefox 將其視爲 reset 屬性，並緩存到規則樹上）。
例如，如果我們在某個段落中添加 font 規則：

p {font-family:Verdana;font size:10px;font-weight:bold} 

那麼，該段落元素作爲上下文樹中的 div 的子代，就會共享與其父代相同的 font 結構（前提是該段落沒有指定 font 規則）。

在 Webkit 中沒有規則樹，因此會對匹配的聲明遍歷 4 次。首先應用非重要高優先級的屬性（由於作爲其他屬性的依據而應首先應用的屬性，例如 display），接着是高優先級重要規則，然後是普通優先級非重要規則，最後是普通優先級重要規則。這意味着多次出現的屬性會根據正確的層疊順序進行解析。最後出現的最終生效。

因此概括來說，共享樣式對象（整個對象或者對象中的部分結構）可以解決問題 1和問題 3。Firefox 規則樹還有助於按照正確的順序應用屬性。

4.3.3 對規則進行處理以簡化匹配

樣式規則有一些來源：

• 外部樣式表或樣式元素中的 CSS 規則
  p {color:blue}

• inline 樣式屬性及類似內容
  <pstyle="color:blue"/>

• HTML 可視化屬性（映射到相關的樣式規則）
  <pbgcolor="blue"/>

後兩種很容易和元素進行匹配，因爲元素擁有樣式屬性，而且 HTML 屬性可以使用元素作爲鍵值進行映射。

我們之前在第 2 個問題中提到過，CSS 規則匹配可能比較棘手。爲了解決這一難題，可以對 CSS 規則進行一些處理，以便訪問。

樣式表解析完畢後，系統會根據選擇器將 CSS 規則添加到某個哈希表中。這些哈希表的選擇器各不相同，包括 ID、類名稱、標記名稱等，還有一種通用哈希表，適合不屬於上述類別的規則。如果選擇器是 ID，規則就會添加到 ID 表中；如果選擇器是類，規則就會添加到類表中，依此類推。

這種處理可以大大簡化規則匹配。我們無需查看每一條聲明，只要從哈希表中提取元素的相關規則即可。這種優化方法可排除掉 95% 以上規則，因此在匹配過程中根本就不用考慮這些規則了。

我們以如下的樣式規則爲例：

p.error {color:red}
#messageDiv {height:50px}
div {margin:5px}

第一條規則將插入類表，第二條將插入 ID 表，而第三條將插入標記表。 對於下面的 HTML 代碼段：

<p class="error">an error occurred </p>
<div id=" messageDiv">this is a message</div>

我們首先會爲 p 元素尋找匹配的規則。類表中有一個“error”鍵，在下面可以找到“p.error”的規則。div 元素在 ID 表（鍵爲 ID）和標記表中有相關的規則。剩下的工作就是找出哪些根據鍵提取的規則是真正匹配的了。 例如，如果 div 的對應規則如下：

table div {margin:5px}

這條規則仍然會從標記表中提取出來，因爲鍵是最右邊的選擇器，但這條規則並不匹配我們的 div 元素，因爲 div 沒有 table 祖先。

Webkit 和 Firefox 都進行了這一處理。

4.3.4 以正確的層疊順序應用規則

樣式對象具有每個可視化屬性一一對應的屬性（均爲 CSS 屬性但更爲通用）。如果某個屬性未由任何匹配規則所定義，那麼部分屬性就可由父代元素樣式對象繼承。其他屬性具有默認值。

如果定義不止一個，就會出現問題，需要通過層疊順序來解決。

1)樣式表層疊順序

某個樣式屬性的聲明可能會出現在多個樣式表中，也可能在同一個樣式表中出現多次。這意味着應用規則的順序極爲重要。這稱爲“層疊”順序。根據 CSS2 規範，層疊的順序爲（優先級從低到高）：

• 瀏覽器聲明
• 用戶普通聲明
• 作者普通聲明
• 作者重要聲明
• 用戶重要聲明

瀏覽器聲明是重要程度最低的，而用戶只有將該聲明標記爲“重要”纔可以替換網頁作者的聲明。同樣順序的聲明會根據特異性進行排序，然後再是其指定順序。HTML 可視化屬性會轉換成匹配的 CSS 聲明。它們被視爲低優先級的網頁作者規則。

2) 特異性

選擇器的特異性由 CSS2 規範定義如下：

• 如果聲明來自於“style”屬性，而不是帶有選擇器的規則，則記爲 1，否則記爲 0 (= a)
• 記爲選擇器中 ID 屬性的個數 (= b)
• 記爲選擇器中其他屬性和僞類的個數 (= c)
• 記爲選擇器中元素名稱和僞元素的個數 (= d)

將四個數字按 a-b-c-d 這樣連接起來（位於大數進制的數字系統中），構成特異性。

您使用的進制取決於上述類別中的最高計數。 例如，如果 a=14，您可以使用十六進制。如果 a=17，那麼您需要使用十七進制；當然不太可能出現這種情況，除非是存在如下的選擇器：html body div div p …（在選擇器中出現了 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 */
 style=""          /* a=1 b=0 c=0 d=0 -> specificity = 1,0,0,0 */

3) 規則排序

找到匹配的規則之後，應根據級聯順序將其排序。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;
}

4.4 漸進式處理

Webkit 使用一個標記來表示是否所有的頂級樣式表（包括 @imports）均已加載完畢。如果在附加過程中尚未完全加載樣式，則使用佔位符，並在文檔中進行標註，等樣式表加載完畢後再重新計算。

第五章 佈局

呈現器在創建完成並添加到渲染樹時，並不包含位置和大小信息。計算這些值的過程稱爲佈局或重排。

HTML 採用基於流的佈局模型，這意味着大多數情況下只要一次遍歷就能計算出幾何信息。處於流中靠後位置元素通常不會影響靠前位置元素的幾何特徵，因此佈局可以按從左至右、從上至下的順序遍歷文檔。但是也有例外情況，比如 HTML 表格的計算就需要不止一次的遍歷 。

座標系是相對於根框架而建立的，使用的是上座標和左座標。

佈局是一個遞歸的過程。它從根呈現器（對應於 HTML 文檔的<html>元素）開始，然後遞歸遍歷部分或所有的框架層次結構，爲每一個需要計算的呈現器計算幾何信息。
根呈現器的位置左邊是 0,0，其尺寸爲視口（也就是瀏覽器窗口的可見區域）。

所有的呈現器都有一個“laybout”或者“reflow”方法，每一個呈現器都會調用其需要進行佈局的子代的 layout 方法。

5.1 Dirty 位系統

爲避免對所有細小更改都進行整體佈局，瀏覽器採用了一種“dirty 位”系統。如果某個呈現器發生了更改，或者將自身及其子代標註爲“dirty”，則需要進行佈局。

有兩種標記：“dirty”和“children are dirty”。“children are dirty”表示儘管呈現器自身沒有變化，但它至少有一個子代需要佈局。

5.2 全局佈局和增量佈局

全局佈局是指觸發了整個渲染樹範圍的佈局，觸發原因可能包括：

• 影響所有呈現器的全局樣式更改，例如字體大小更改。
• 屏幕大小調整。

佈局可以採用增量方式，也就是隻對 dirty 呈現器進行佈局（這樣可能存在需要進行額外佈局的弊端）。

當呈現器爲 dirty 時，會異步觸發增量佈局。例如，當來自網絡的額外內容添加到 DOM 樹之後，新的呈現器附加到了渲染樹中。

圖5.1：增量佈局 - 只有 dirty 呈現器及其子代進行佈局

5.3 異步佈局和同步佈局

增量佈局是異步執行的。Firefox 將增量佈局的“reflow 命令”加入隊列，而調度程序會觸發這些命令的批量執行。Webkit 也有用於執行增量佈局的計時器：對渲染樹進行遍歷，並對 dirty 呈現器進行佈局。

請求樣式信息（例如“offsetHeight”）的腳本可同步觸發增量佈局。

全局佈局往往是同步觸發的。

有時，當初始佈局完成之後，如果一些屬性（如滾動位置）發生變化，佈局就會作爲回調而觸發。

5.4 優化

如果佈局是由“大小調整”或呈現器的位置（而非大小）改變而觸發的，那麼可以從緩存中獲取呈現器的大小，而無需重新計算。

在某些情況下，只有一個子樹進行了修改，因此無需從根節點開始佈局。這適用於在本地進行更改而不影響周圍元素的情況，例如在文本字段中插入文本（否則每次鍵盤輸入都將觸發從根節點開始的佈局）。

5.5 佈局處理

佈局通常具有以下模式：

• 父呈現器確定自己的寬度。
• 父呈現器依次處理子呈現器，並且：
  
  • 放置子呈現器（設置 x,y 座標）。
  • 如果有必要，調用子呈現器的佈局（如果子呈現器是 dirty 的，或者這是全局佈局，或出於其他某些原因），這會計算子呈現器的高度。
• 父呈現器根據子呈現器的累加高度以及邊距和補白的高度來設置自身高度，此值也可供父呈現器的父呈現器使用。
• 將其 dirty 位設置爲 false。

Firefox 使用“state”對象 (nsHTMLReflowState) 作爲佈局的參數（稱爲“reflow”），這其中包括了父呈現器的寬度。

Firefox 佈局的輸出爲“metrics”對象 (nsHTMLReflowMetrics)，其包含計算得出的呈現器高度。

5.6 寬度計算

呈現器寬度是根據容器塊的寬度、呈現器樣式中的“width”屬性以及邊距和邊框計算得出的。例如以下 div 的寬度：

<divstyle="width:30%"/>

將由 Webkit 計算如下（BenderBox 類，calcWidth 方法）：

• 容器的寬度取容器的 availableWidth 和 0 中的較大值。availableWidth 在本例中相當於 contentWidth，計算公式：clientWidth()- paddingLeft()- paddingRight()，clientWidth 和 clientHeight 表示一個對象的內部（除去邊框和滾動條）。
• 元素的寬度是“width”樣式屬性。它會根據容器寬度的百分比計算得出一個絕對值。
• 然後加上水平方向的邊框和補白。

現在計算得出的是“preferred width”。然後需要計算最小寬度和最大寬度。 如果首選寬度大於最大寬度，那麼應使用最大寬度。如果首選寬度小於最小寬度（最小的不可破開單位），那麼應使用最小寬度。

這些值會緩存起來，以用於需要佈局而寬度不變的情況。

5.7 換行

如果呈現器在佈局過程中需要換行，會立即停止佈局，並告知其父代需要換行。父代會創建額外的呈現器，並對其調用佈局。

第六章 繪製

在繪製階段，系統會遍歷渲染樹，並調用呈現器的“paint”方法，將呈現器的內容顯示在屏幕上。繪製工作是使用用戶界面基礎組件完成的。

6.1 全局繪製和增量繪製

和佈局一樣，繪製也分爲全局（繪製整個渲染樹）和增量兩種。在增量繪製中，部分呈現器發生了更改，但是不會影響整個樹。更改後的呈現器將其在屏幕上對應的矩形區域設爲無效，這導致 OS 將其視爲一塊“dirty 區域”，並生成“paint”事件。OS 會很巧妙地將多個區域合併成一個。在 Chrome 瀏覽器中，情況要更復雜一些，因爲 Chrome 瀏覽器的呈現器不在主進程上。Chrome 瀏覽器會在某種程度上模擬 OS 的行爲。展示層會偵聽這些事件，並將消息委託給呈現根節點。然後遍歷渲染樹，直到找到相關的呈現器，該呈現器會重新繪製自己（通常也包括其子代）。

6.2 繪製順序

CSS2 規範定義了繪製流程的順序。繪製的順序其實就是元素進入堆棧樣式上下文的順序。這些堆棧會從後往前繪製，因此這樣的順序會影響繪製。塊呈現器的堆棧順序如下：

• 背景顏色
• 背景圖片
• 邊框
• 子代
• 輪廓

6.3 Firefox 顯示列表

Firefox 遍歷整個渲染樹，爲繪製的矩形建立一個顯示列表。列表中按照正確的繪製順序（先是呈現器的背景，然後是邊框等等）包含了與矩形相關的呈現器。這樣等到重新繪製的時候，只需遍歷一次渲染樹，而不用多次遍歷（繪製所有背景，然後繪製所有圖片，再繪製所有邊框等等）。

Firefox 對此過程進行了優化，也就是不添加隱藏的元素，例如被不透明元素完全遮擋住的元素。

6.4 Webkit 矩形存儲

在重新繪製之前，Webkit 會將原來的矩形另存爲一張位圖，然後只繪製新舊矩形之間的差異部分。

第七章 動態變化

在發生變化時，瀏覽器會儘可能做出最小的響應。因此，元素的顏色改變後，只會對該元素進行重繪。元素的位置改變後，只會對該元素及其子元素（可能還有同級元素）進行佈局和重繪。添加 DOM 節點後，會對該節點進行佈局和重繪。一些重大變化（例如增大“html”元素的字體）會導致緩存無效，使得整個渲染樹都會進行重新佈局和繪製。

第八章 渲染引擎的線程

渲染引擎採用了單線程。幾乎所有操作(除了網絡操作)都是在單線程中進行的。在 Firefox 和 Safari 中，該線程就是瀏覽器的主線程。而在 Chrome 瀏覽器中，該線程是標籤進程的主線程。

網絡操作可由多個並行線程執行。並行連接數是有限的(通常爲 2 至 6 個，以 Firefox 3 爲例是 6 個)。

8.1 事件循環

瀏覽器的主線程是事件循環。它是一個無限循環，永遠處於接受處理狀態，並等待事件(如佈局和繪製事件)發生，並進行處理。這是 Firefox 中關於主事件循環的代碼：

while(!mExiting)
    NS_ProcessNextEvent(thread);

第九章 CSS2 可視化模型

9.1 畫布

根據 CSS2 規範，“畫布”這一術語是指“用來呈現格式化結構的空間”，也就是供瀏覽器繪製內容的區域。畫布的空間尺寸大小是無限的，但是瀏覽器會根據視口的尺寸選擇一個初始寬度。

根據 www.w3.org/TR/CSS2/zindex.html，畫布如果包含在其他畫布內，就是透明的；否則會由瀏覽器指定一種顏色。

9.2 CSS 框模型

CSS 框模型描述的是針對文檔樹中的元素而生成，並根據可視化格式模型進行佈局的矩形框。

每個框都有一個內容區域（例如文本、圖片等），還有可選的周圍補白、邊框和邊距區域。

圖9.1：CSS2 框模型

每一個節點都會生成 0..n 個這樣的框。 所有元素都有一個“display”屬性，決定了它們所對應生成的框類型。示例：

block  - generates a block box.
inline - generates one or more inline boxes.
none - no box is generated.

默認值是 inline，但是瀏覽器樣式表設置了其他默認值。例如，“div”元素的 display 屬性默認值是 block。

您可以在這裏找到默認樣式表示例：www.w3.org/TR/CSS2/sample.html

9.3 定位方案

有三種定位方案：

• 普通：根據對象在文檔中的位置進行定位，也就是說對象在渲染樹中的位置和它在 DOM 樹中的位置相似，並根據其框類型和尺寸進行佈局。
• 浮動：對象先按照普通流進行佈局，然後儘可能地向左或向右移動。
• 絕對：對象在渲染樹中的位置和它在 DOM 樹中的位置不同。

定位方案是由“position”屬性和“loat”屬性設置的。

• 如果值是 static 和 relative，就是普通流
• 如果值是 absolute 和 fixed，就是絕對定位

static 定位無需定義位置，而是使用默認定位。對於其他方案，網頁作者需要指定位置：top、bottom、left、right。

框的佈局方式是由以下因素決定的：

• 框類型
• 框尺寸
• 定位方案
• 外部信息，例如圖片大小和屏幕大小

9.4 框類型

block 框：形成一個 block，在瀏覽器窗口中擁有其自己的矩形區域。

圖9.2：block 框

inline 框：沒有自己的 block，但是位於容器 block 內。

圖9.3：inline 框

block 採用的是一個接一個的垂直格式，而 inline 採用的是水平格式。

圖9.4：block 和 inline 格式

inline 框放置在行中或“行框”中。這些行至少和最高的框一樣高，還可以更高，當框根據“底線”對齊時，這意味着元素的底部需要根據其他框中非底部的位置對齊。如果容器的寬度不夠，inline 元素就會分爲多行放置。在段落中經常發生這種情況。

圖9.5：行

9.5 定位

9.5.1 相對

相對定位：先按照普通方式定位，然後根據所需偏移量進行移動。

圖9.6：相對定位

9.5.2 浮動

浮動框會移動到行的左邊或右邊。有趣的特徵在於，其他框會浮動在它的周圍。下面這段 HTML 代碼：

<p>
  <img style="float:right" src="images/image.gif" width="100" height="100">
  Lorem ipsum dolor sit amet, consectetuer...
</p>

顯示效果如下：

圖9.7：浮動

9.5.3 絕對定位和固定定位

這種佈局是準確定義的，與普通流無關。元素不參與普通流。尺寸是相對於容器而言的。在固定定位中，容器就是可視區域。

圖9.8：固定定位

請注意，即使在文檔滾動時，固定框也不會移動。

9.6 分層展示

這是由 z-index CSS 屬性指定的。它代表了框的第三個維度，也就是沿“z 軸”方向的位置。

這些框分散到多個堆棧（稱爲堆棧上下文）中。在每一個堆棧中，會首先繪製後面的元素，然後在頂部繪製前面的元素，以便更靠近用戶。如果出現重疊，新繪製的元素就會覆蓋之前的元素。

堆棧是按照 z-index 屬性進行排序的。具有“z-index”屬性的框形成了本地堆棧。視口具有外部堆棧。示例：　

<style type="text/css">
      div {
        position: absolute;
        left: 2in;
        top: 2in;
      }
</style>

<p>
    <div style="z-index: 3;background-color:red; width: 1in; height: 1in; ">
    </div>
    <div style="z-index: 1;background-color:green;width: 2in; height: 2in;">
    </div>
 </p>

結果如下：

圖9.9：固定定位

雖然紅色 div 在標記中的位置比綠色 div 靠前（按理應該在常規流程中優先繪製），但是 z-index 屬性的優先級更高，因此它移動到了根框所保持的堆棧中更靠前的位置。

參考資料

• 瀏覽器架構
  
  • Grosskurth, Alan. A Reference Architecture for Web Browsers (pdf)
  • Gupta, Vineet. How Browsers Work - Part 1 - Architecture
• 解析
  
  • Aho, Sethi, Ullman, Compilers: Principles, Techniques, and Tools（即“Dragon book”）, Addison-Wesley, 1986
  • Rick Jelliffe. The Bold and the Beautiful: two new drafts for HTML 5
• Firefox
  
  • L. David Baron, Faster HTML and CSS: Layout Engine Internals for Web Developers
  • L. David Baron, Faster HTML and CSS: Layout Engine Internals for Web Developers（Google 技術訪談視頻）
  • L. David Baron, Mozilla’s Layout Engine
  • L. David Baron, Mozilla Style System Documentation
  • Chris Waterson, Notes on HTML Reflow
  • Chris Waterson, Gecko Overview
  • Alexander Larsson, The life of an HTML HTTP request
• WebKit
  
  • David Hyatt, Implementing CSS（第一部分）
  • David Hyatt, An Overview of WebCore
  • David Hyatt, WebCore Rendering
  • David Hyatt, The FOUC Problem
• W3C 規範
  
  • HTML 4.01 規範
  • W3C HTML5 規範
  • 層疊樣式表第 2 級第 1 次修改 (CSS 2.1) 規範
• 瀏覽器構建說明
  
  • Firefox. https://developer.mozilla.org/en/Build_Documentation
  • WebKit. http://webkit.org/building/build.html