瀏覽器的工做原理解析

時間 2019-11-17

原文原文鏈接

PART1 有關瀏覽器的內核

1、Trident內核，表明產品IE

Trident內核又稱爲IE內核。是微軟開發的一種排版引擎。1997年與IE4一塊兒誕生。雖然它相對於其它瀏覽器核心還比較落後，但trident一直在被不斷地更新和完善。並且除IE外，許多產品都在使用Trident核心，好比Windows的HELP程序、RealPlayer、Windows Media Player、Windows Live Messager、Outlook Express等。css

使用此內核的其它瀏覽器有：IE、傲遊、世界之窗、Avant、騰訊TT、Netscape 8、NetCaptor、Sheipnir、GOSURF、GreenBrower和KKman等。html

2、Gekco內核，表明Mozilla Firefox

Gecko是一套開源的、以C++編寫的網頁排版引擎。html5

目前爲Mozilla家族網頁瀏覽器以及Netscape 6以及之後版本瀏覽器所使用。這軟件本來是由網景通信公司開發，如今由Mozilla基金會維護。它的最大優點是跨平臺，能在Win、linux和MacOS等主要操做系統上運行，並且它提供了一個豐富的程序界面以供互聯網相關的應用程序使用，例如網頁瀏覽器、HTML編輯器、客戶端/服務器等等。node

使用此核瀏覽器：Firefox、Netspace6~9linux

3、Webkit內核，Safari、Chrome

webkit是一個開源項目，包含了來自KDE項目和蘋果公司的一些組件，主要用於Mac OS，特色在於源碼結構清晰、渲染速度極快。缺點是對網頁代碼的兼容性不高，致使一些編寫不標準的網頁沒法正常顯示。web

4、Presto內核，表明做品Opera

Presto是由Opera Software開發的瀏覽器排版引擎，供Opera 7.0及以上使用。正則表達式

Presto在退出後不斷有更新版本退出，使很多錯誤得以修正，以及閱讀Javascript效能得以最佳化，併成爲速度最快的引擎，這也是Opera被公認爲速度最快的瀏覽器的基礎。算法

PART2 瀏覽器的工做原理

1.簡介

如下介紹瀏覽器的工做原理，咱們將看到，從你在地址欄輸入google.com到你看到google主頁過程當中都發生了什麼。chrome

1.1討論的瀏覽器

IE、Firefox、Safari、Chrome、Opera。如下是基於一些開源瀏覽器（Firefox、Chrome及Safari，Safari是部分開源的）的例子。express

1.2瀏覽器的主要功能

瀏覽器的主要功能是將用戶選擇的web資源呈現出來，他須要從服務器請求資源，並將其顯示在瀏覽器窗口中，資源的格式一般是HTML，也包括PDF、image及其餘格式。用戶用URL（Uniform Resorce Indentifier 統一資源標識符）來指定請求資源的位置。

HTML和CSS規範中規定了瀏覽器解釋html文檔的方式，由W3C組織對這些規範進行維護，W3C是負責制定web標準的組織。

瀏覽器廠商開發本身的擴展，對規範的遵循不完善，這爲web開發者帶來了嚴重的兼容性問題。但瀏覽器的用戶界面差很少，常見的用戶界面元素包括：

用來輸入URL的地址欄

前進後退按鈕

書籤選項

用於刷新及暫停當前加載文檔的刷新、暫停按鈕

用於到達主頁的主頁按鈕

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

瀏覽器的主要組件包括：

用戶界面 - 包括地址欄、後退/前進按鈕、書籤目錄等，也就是你所看到的除了用來顯示你所請求頁面的主窗口以外的其餘部分
瀏覽器引擎 - 用來查詢及操做渲染引擎的接口
渲染引擎 - 用來顯示請求的內容，例如，若是請求內容爲html，他負責解析html及css，並將解析後的結果顯示出來
網絡 - 用來完成網絡調用，例如http請求，它具備平臺無關的接口，能夠再不一樣平臺上工做
UI後端 - 用來繪製相似組合選擇框及對話框等基本組件，具備不特定於某個平臺的通用接口，底層使用操做系統的用戶接口
JS解釋器 - 用來解釋執行JS代碼
數據存儲 - 用於持久層，瀏覽器須要在硬盤中保存相似cookie的各類數據，還包括HTML5的web database技術。

圖1 ：瀏覽器主要組件

須要注意的是，不一樣於大部分瀏覽器，chrome爲每一個Tab分配了各自的渲染引擎實例，每一個Tab就是一個獨立的進程。

2.渲染引擎

渲染引擎的職責就是渲染，即在瀏覽器窗口中顯示所請求的內容。

默認狀況下，渲染引擎能夠顯示html、xml文檔及圖片，它也能夠藉助插件顯示其餘類型數據，例如PDF閱讀器插件，能夠顯示PDF格式。這一部分只討論渲染引擎最主要的用途 --- 顯示應用了CSS以後的html及圖片。

2.1渲染引擎

Firefox是基於Geoko的，Safari和Chrome都是用webkit。

2.2主要流程

渲染引擎首先經過網絡得到所請求文檔的內容，一般以8K分塊的方式完成。

下面是渲染引擎在取得內容以後的基本流程：

解析html以構建DOM樹->構建render樹->佈局render樹->繪製render樹

圖2：渲染引擎基本流程

渲染引擎開始解析html，並將標籤轉化爲內容樹中的dom節點。接着，他解析外部CSS文件及style標籤中的樣式信息。這些樣式信息以及html中的可見性指令將被用來構建另外一棵樹 --- render樹。

Render樹由一些包含有顏色和大小等屬性的矩形組成，他們將被按照正確的順序顯示到屏幕上。

Render樹構建好了以後，將會執行佈局過程，它將肯定每一個節點在屏幕上的確切座標。在下一步就是繪製，即遍歷render樹，並使用UI後端層繪製每一個節點。

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

圖3：webkit主流程

圖4：Geoko渲染引擎主流程

從圖3和圖4看出，儘管webkit和Geoko使用的術語稍有不一樣，他們的主要流程基本相同。

Gecko稱可見的格式化元素組成的樹爲iframe樹，每一個元素都是一個frame，webkit則使用render樹來命名由渲染對象組成的樹。webkit中元素的定位稱爲佈局，而Gecko中稱爲迴流。

webkit利用dom節點及樣式信息去構建render樹的過程爲attachement，Gecko在html和dom樹之間附加了一層，這層稱爲內容接收器，至關於製造dom元素的工廠，下面將討論流程中的各個階段。

3.解析和DOM樹建設

3.1 通常解析

解析是渲染引擎中一個很是重要的過程，咱們將稍微深刻地研究它。

解析一個文檔即將其轉換爲具備必定意義的結構---編碼能夠理解和使用的東西。解析的結果一般是表達文檔結構的節點數，稱爲解析樹或語法樹。

例如，解析「2+3-1」這個表達式，可能返回這樣一棵樹：

圖5：數學表達式樹節點

3.1.1語法

解析基於文檔依據的語法規則。每種可被解析的格式必須具備詞彙及語法規則組成的特定文法，這是與上下文無關的文法。人類語言不具備這一特性，所以不能被通常的解析技術所解析。

3.1.2解析器 - 詞法分析器

解析能夠分爲兩個子過程---語法分析及詞法分析。

詞法分析就是將輸入分解爲符號，符號是語言的詞彙表---基本有效單元的集合。對於人類語言來講，他至關於咱們字典中出現的全部單詞。

語法分析指對語言應用語法規則。

解析器通常將工做分配給兩個組件---詞法分析器（分詞器）負責將輸入分解爲合法的符號，解析器則根據語言的語法規則分析文檔結構，從而構建解析樹，分詞器知道怎麼跳過空白和換行之類的無關字符。

圖6：從源文檔到解析樹

解析的過程是迭代的，解析器今後法分析器處取獲得一個新的符號，並試着用這個符號匹配一條語法規則，若是匹配到了一條規則，這個符號對應的節點將被添加到解析樹上，而後解析器請求另外一個符號。若是沒有匹配到規則，解析器將在內部保存該符號，並從分詞器去下一個符號，直到全部內部保存的符號可以匹配一項語法規則。若是最終沒有找到匹配的規則，解析器將拋出一個異常，這意味着文檔無效或是包含語法錯誤。

3.1.3轉換

不少時候，解析樹並非最終結果。解析通常在轉換中使用---將輸入文檔轉換爲另外一種格式。編譯就是個例子，編譯器將在一段源碼編譯爲機器碼的時候，先將源碼解析爲解析樹，而後將該樹轉換爲一個機器碼文檔。

圖7：編譯流程

3.1.4解析示例

圖5中，咱們從一個數學表達式構建了一個解析樹，這裏定義一個簡單的數學語言來看下解析過程。

詞彙表：整數、加號、減號。

語法：

1該語言的語法基本單元包括表達式、term及操做符。

2該語言能夠包括多個表達式

3一個表達式定義爲兩個term經過一個操做符鏈接

4操做符能夠是加號或減號

5term能夠是一個整數或一個表達式

如今來分析一下「2＋3－1」這個輸入：

第一個匹配規則的子字符串是「2」，根據規則5，它是一個term，第二個匹配的是「2＋3」，它符合第2條規則——一個操做符鏈接兩個term，下一次匹配發生在輸入的結束處。「2＋3－1」是一個表達式，由於咱們已經知道「2＋3」是一個term，因此咱們有了一個term緊跟着一個操做符及另外一個term。「2＋＋」將不會匹配任何規則，所以是一個無效輸入。

3.1.5詞彙和語法的正式定義

詞彙表一般利用正則表達式來定義。

例如上面的語言能夠定義爲：

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）

3.1.6解析器的類型

有兩種基本的解析器 --- 自頂向下解析及自底向上解析。比較相當的解釋是，自頂向下解析，查看語法的最高層結構並試着匹配其中一個；自底向上解析則從輸入開始，逐步將其轉換爲語法規則，從底層規則開始直到匹配高層規則。

來看一下這兩種解析器如何解析上面的例子：

自頂向下解析器從最高層規則開始---他先識別出「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解析器，由於輸入向右移動（想象一個指針首先指向輸入開始處，並向右移動），並逐漸簡化爲語法規則

3.1.7自動化解析

解析器生成器這個工具能夠自動生成解析器，只須要指定語言的文法---詞彙表及語法規則，他就能夠生成一個解析器。建立一個解析器須要對解析有深刻地理解，並且手動地建立一個有較好性能的解析器並不容易，因此解析生成器頗有用。Webkit使用兩個知名的解析生成器---用於建立語法分析器的Flex以及建立解析器的Bison。Flex的輸入時一個包含了符號定義的正則表達式，Bison的輸入是用BNF格式表示的語法規則。

3.2HTML解析器

HTML解析器的工做室將html標識解析爲解析樹。

3.2.1HTML語法定義

W3C組織規定規範定義了HTML的詞彙表和語法。

3.2.2並不是一個上下文無關的語法

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

不幸的是，全部的傳統解析方式都不適用於html（傳統的解析方式將用來解析css和js），html不能簡單的用解析所需的上下文無關語法來定義。

html有一個正式的格式定義DTD（Document Type Definition），但它不是上下文無關的，html更接近於xml，如今由不少可用的xml解析器，html有個xml的變體xhtml，他們間的不一樣在於，html更寬容，它容許忽略一些特定標籤，有時能夠省略開始或結束標籤。總的來講，它是一種soft語法，不像xml呆板執拗。

顯然，這個看起來很小的差別卻帶來了很大的不一樣。一方面，這是html流行的緣由---她的寬容使web開發人員的工做更加輕鬆，但另外一方面，這也使很難去寫一個格式化的文法。因此，html的解析並不簡單，它既不能用傳統的解析器解析，也不能用xml解析器解析。

3.2.3HTML DTD

html使用DTD進行定義，這一格式是用於定義SGML家族的語言，包括了對全部容許元素及它們的屬性和層次關係的定義。

標準DTD：http://www.w3.org/TR/html4/strict.dtd

3.2.4DOM

輸出的樹，也就是解析樹，是由DOM元素及屬性節點組成的。DOM是文檔對象模型的縮寫，它是html文檔的對象表示，做爲html元素的外部接口供js等調用。

樹根是「document」對象。

DOM和標籤基本是一一對應的關係，例如，以下標籤

<html>

<body>

<p>

Hello DOM

</p>

</body>

</html>

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

DOM規範：http://www.w3.org/DOM/DOMTR

這裏所謂的樹包含了DOM節點是說樹是由實現了DOM接口的元素構建而成的，瀏覽器使用已被瀏覽器內部使用的其餘屬性的具體實現。

3.2.5解析算法

正如前面章節所討論的，html不能被通常的自頂向下或自底向上的解析器所解析。

緣由是：

1.這門語言自己的寬容特性

2.瀏覽器對一些常見的非法html有容錯機制

3.解析過程是往復的，一般源碼不會再解析過程當中發生改變，但在html中，腳本標籤包含的「document.write」可能添加標籤，這說明在解析過程當中實際上修改了輸入

不能使用正則解析技術，瀏覽器爲html定製了專屬的解析器。

html5規範中描述了這個解析算法，算法包括兩個階段---符號化及構建樹。

符號化是詞法分析的過程，將輸入解析爲符號，html的符號包括開始標籤、結束標籤、屬性名及屬性值。

符號識別器識別出符號後，將其值傳遞給樹構建器，並讀取下一個字符，以識別下一個符號，這樣直處處理完全部輸入。

圖9：html解析流程

3.2.6符號識別算法 The tokenization algorithm

算法輸出html符號，該算法用狀態機表示。每次讀取輸入流中的一個或多個字符，並根據這些字符轉移到下一個狀態，當前的符號狀態及構建樹狀態共同影響結果，這意味着，讀取一樣的字符，可能由於當前狀態的不一樣，獲得不一樣的結果以進入下一個正確的狀態。

這個算法很複雜，這裏用一個簡單的例子來解釋這個原理。

基本示例---符號化下面的html：

<html>

<body>

Hello world

</body>

</html>

初始狀態爲「Data State」，當遇到"<"字符，狀態變爲「Tag open state」，讀取一個a-z的字符將產生一個開始標籤符號，狀態響應變爲「Tag name state「，一直保持這個狀態直到讀取到」>"，每一個字符都附加到這個符號名上，例子中建立的是一個html符號。

當讀取到「>」，當前的符號就完成了，此時，狀態回到「Date state」，「<body>」重複這一處理過程。到這裏，html和body標籤都識別出來了。如今，回到「Data state」，讀取」Hello world「中的字符「H」將建立並識別出一個字符符號，這裏會爲「Hello world」中的每一個字符生成一個字符符號。

這樣直到遇到「</body>」中的「<」。如今，又回到了「Tag open state」，讀取下一個字符「/」將建立一個閉合標籤符號，而且狀態轉移到「Tag name state」，仍是一直保持這一狀態，直到遇到「>」。而後，產生一個新的標籤符號並回到「Data state」。後面的「</html>」將和「</body>」同樣處理。

圖10：符號化示例輸入

3.2.7樹構建算法

在樹的構建階段，將修改以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樹的構建過程

3.2.8解析完成時的動做

在這個階段，瀏覽器將文檔標記爲可交互的，並開始解析處於延時模式中的腳本---這些腳本在文檔解析後執行。

文檔狀態將被設置爲完成，同時出發一個load事件。

html5規範中有符號化及構建樹的完整算法（http://www.w3.org/TR/html5/syntax.html#html-parser）。

3.2.9瀏覽器容錯

你不會在一個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>, 爲了兼容IE和Firefox，webkit將其看作<br>。

代碼：

if (t->isCloseTag(brTag) && m_document->inCompatMode()) {

reportError(MalformedBRError);

t->beginTag = true;

}

這裏的錯誤處理是在內部進行，用戶看不到。

迷路的表格：

這指一個表格嵌套在另外一個表格中，但不在它的某個單元格內。好比：

<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吧。

3.3CSS解析

不一樣於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表示空格）進行分隔。每一個規則集合包含大括號及大括號中的一條或多條以分好隔開的聲明。聲明和選擇器在後面進行定義。

3.3.1Webkit的CSS解析器

webkit使用Flex和Bison解析生成器從CSS語法文件中自動生成解析器。回憶一下解析器的介紹，Bison建立一個自底向上的解析器，Firefox使用自頂向下解析器。他們都是將每一個css文件解析爲樣式表對象，每一個對象包含css規則，css規則對象包含選擇器和聲明對象，以及其餘一些符合css語法的對象。

圖12：解析css

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

3.4.1腳本

web的模式是同步的，開發者但願解析到一個script標籤時當即解析執行腳本，並阻塞文檔的解析直到腳本執行完。若是腳本是外引的，則網絡必須先請求道這個資源---這個過程也是同步的，會阻塞文檔的解析直到資源被請求到。這個模式保持了不少年，而且在html4及html5中都特別指定了。開發者能夠將腳本標識爲defer，以使其不阻塞文檔解析，並在文檔解析結束後執行。Html5增長了標記腳本爲異步的選項，以使腳本的解析執行使用另外一個線程。

3.4.2預解析

webkit和firefox都作了這個優化，當執行腳本時，另外一個線程解析剩下的文檔，並加載後面須要經過網絡加載的資源。這種方式可使資源並行加載從而使總體速度更快。須要注意的是，預解析並不改變Dom樹，它將這個工做留給主解析過程，本身只解析外部資源的引用，好比外部腳本、樣式表及圖片。

3.4.3樣式表

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

4.渲染樹構建

當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」方法，使渲染對象指向不包含集合信息的樣式對象。

4.1渲染樹與DOM樹的關係

渲染對象和Dom元素相對應，但這種對應關係不是一對一的，不可見的Dom元素不會被插入渲染樹，例如head元素。另外，display屬性爲none的元素也不會在渲染書中出現（visibility屬性爲hidden的元素將出如今渲染樹中）。

還有一些Dom元素對應幾個可見對象，他們通常是一些具備複雜結構的元素，沒法用一個矩形來描述。例如，select元素有三個渲染對象（一個現實區域、一個下拉列表及一個按鈕）。一樣，當文本由於寬度不夠而折行時，新行將做爲額外的渲染元素被添加。另外一個多個渲染對象的例子是不規範的html，根據css規範，一個行內元素只能僅包含行內元素或僅包含塊狀元素，在存在混合內容時，將會建立匿名的塊狀渲染對象包裹住行內元素。

一些渲染對象和所對應的Dom節點不在樹上相同的位置，例如，浮動和絕對定位的元素在文本流以外，在兩棵樹上的位置不一樣，渲染樹上標識出真實的結構，並用一個佔位結構標識出他們原來的位置。

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

4.2構建樹的流程

Firefox中，表述爲一個監聽Dom更新的監聽器，將frame的建立委派給Frame Constructor，這個構造器計算樣式並建立一個frame。

webkit中，計算樣式並生成渲染對象的過程稱爲attachement，每一個Dom節點有一個attach方法，attachement的過程是同步的，調用新節點的attach方法將節點插入到Dom樹中。

處理html和body標籤將構建渲染樹的根，這個根渲染對象對應被css規範稱爲containing block的元素---包含了其餘全部塊元素的頂級塊元素。它的大小就是viewport---瀏覽器窗口的顯示區域，Firefox稱他爲ViewPortFrame，webkit稱爲RenderView，這個就是文檔所指向的渲染對象，樹中其餘的部分都將做爲一個插入的Dom節點被建立。

4.3樣式的計算

建立渲染樹須要計算出每一個渲染對象的可視屬性，這能夠經過計算每一個元素的樣式屬性獲得。

樣式包括各類來源的樣式表，行內樣式元素及html中的可視化屬性（例如bgcolor），可視化屬性轉化爲css樣式屬性。

樣式表來源與瀏覽器默認樣式表，及頁面做者和用戶提供的樣式表---有些樣式是瀏覽器用戶提供的（瀏覽器容許用戶定義喜歡的樣式）。

計算樣式的一些困難：

1.樣式數據是很是大的結構，保存大量的樣式屬性會帶來內存問題

2.若是不進行優化，找到每一個元素匹配的規則會致使性能問題，爲每一個元素查找匹配的規則都須要遍歷整個規則表，這個過程有很大的工做量。選擇符可能有複雜的結構，匹配過程若是沿着一條開始看似正確，後來卻被證實是無用的路徑，則必須去嘗試另外一條路徑。

例以下面這個複雜的選擇符：

div div div div｛…｝

這意味着規則應用到三個div的後代div元素，選擇樹上一條特定的路徑去檢查，這可能須要遍歷節點樹，最後卻發現它只是兩個div的後代，並不使用該規則，而後則須要沿着另外一條路徑去嘗試

3.應用規則設計很是複雜的級聯，他們定義了規則的層次。

如下是瀏覽器如何處理這些問題的

4.3.1共享樣式數據

webkit節點引用樣式對象（渲染樣式），某些狀況下，這些對象能夠被節點間共享，這些節點須要是兄弟或表兄弟節點，而且：

這些元素必須處於相同的鼠標狀態（不如不能一個處於hover，而另外一個不是）
不能有元素具備id
標籤名必須匹配
class屬性必須匹配
對應的屬性必須相同
鏈接狀態必須匹配
焦點狀態必須匹配
不能有元素被屬性選擇器影響
元素不能有行內樣式屬性
不能有生效的兄弟選擇器，webcore在任何兄弟選擇器相遇時只是簡單的拋出一個全局轉換，而且在他們顯示時整個文檔的樣式共享失效，這些包括+選擇器和相似:first-child和:last-child這樣的選擇器。

4.3.2火狐規則樹

Firefox用兩個樹來簡化樣式計算---規則樹和樣式上下文樹，webkit也有樣式對象，但它們並無存儲在相似樣式上下文樹這樣的樹中，只是由Dom節點指向其相關的樣式。

圖14：Firefox樣式上下文樹

樣式上下文包含最終值，這些值是經過以正確順序所應用全部匹配的規則，並將它們由邏輯值轉換爲具體的值，例如，若是邏輯值爲屏幕的百分比，則經過計算將其轉換爲絕對單位。樣式樹的使用確實很巧妙，它使得在節點中共享的這些值不須要被屢次計算，同時也節省了存儲空間。

全部匹配的規則都存儲在規則樹中，一條路徑中的底層節點擁有最高的優先級，這棵樹包含了所找到的全部規則匹配的路徑（能夠取巧理解爲每條路徑對應一個節點，路徑上包含了該節點所匹配的全部規則）。規則樹並非一開始就爲全部節點進行計算，而是在某個節點須要計算樣式時，才進行相應的計算並將計算後的路徑添加到樹中。

咱們將樹上的路徑當作詞典中的單詞，加入已經計算出以下的規則樹：

加入須要爲內容樹中的另外一個節點匹配規則，如今知道匹配的規則（以正確的順序）爲BEI，由於咱們已經計算出了路徑ABEIL，因此樹上已經存在了這條路徑，剩下的工做就不多了。

如今來看一下樹如何保存。

4.3.2.1結構劃分

樣式上下文按結構劃分，這些結構包括相似border或color這樣的特定分類的樣式信息。一個結構中的全部特性不是繼承的就是非繼承的，對繼承的特性，除非元素自身有定義，不然就從它的parent繼承。非繼承的特性（稱爲reset特性）若是沒有定義，則使用默認的值。

樣式上下文樹緩存完整的結構（包括計算後的值），這樣，若是底層節點沒有爲一個結構提供定義，則使用上層節點緩存的結構。

4.3.2.2使用規則樹計算樣式

當爲一個特定的元素計算樣式使，首先計算出規則樹中的一條路徑，或是使用已經存在的一條，而後使用路徑中的規則去填充新的樣式上下文，從樣式的底層節點開始，它具備最高優先級（一般是最特定的選擇器），遍歷規則樹，直到填滿結構。若是在那個規則節點沒有定義所需的結構規則，則沿着路徑向上，直到找到該結構規則。

若是最終沒有找到該結構的任何規則定義，那麼若是這個結構是繼承型的，則找到其在內容樹中的parent的結構，這種狀況下，咱們也成功的共享告終構；若是這個結構是reset型的，則使用默認的值。

若是特定的節點添加了值，那麼須要作一些恩愛的計算以將其轉換爲實際值，而後再樹上的節點緩存該值，使他的children可使用。

當一個元素和它的一個兄弟元素指向同一個樹節點時，完整的樣式上下文能夠被他們共享。

來看一個例子：假設有下面這段html：

<html>

<body>

<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結構只包含一個成員---顏色，margin結構包含四條邊。

生成的規則樹以下（節點名：指向的規則）

上下文樹以下（節點名：指向的規則節點）

假設咱們解析html，遇到第二個div標籤，咱們須要爲這個節點建立樣式上下文，並填充它的樣式結構。

咱們進行規則匹配，找到這個div匹配的規則爲1、2、6，咱們發現規則樹上已經存在了一條咱們可使用的路徑1、2，咱們只需爲規則6新增一個節點添加到下面（就是規則樹中的F）。

而後建立一個樣式上下文並將其放到上下文樹中，新的樣式上下文將指向規則樹中的節點F。

如今咱們須要填充這個樣式上下文，先從填充margin結構開始，既然最後一個規則節點沒有添加margin結構，既然最後一個規則節點沒有添加margin結構，沿着路徑向上，直到找到緩存的前面插入節點計算出的機構，咱們發現B是最近的指定margin值的節點。由於已經有了color結構的定義，因此不能使用緩存的機構，既然coloe只有一個屬性，也就不須要沿着路徑向上填充其餘屬性。計算出最終值（將字符串轉換爲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的規則樹幫助以正確的順序應用規則。

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

樣式規則有幾個來源：

外部樣式表或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都會作這個處理。

4.3.4運用正確的級聯秩序規則

樣式對象擁有對應全部課件屬性的屬性，若是特性沒有被任何匹配的規則所定義，那麼一些特性能夠從parent的樣式對象中繼承，另一些使用默認值。

這個問題的產生是由於存在不止一處的定義，這裏用級聯順序解決這個問題。

4.3.4.1樣式表的級聯順序

一個樣式屬性的聲明可能在幾個樣式表中出現，或是在一個樣式表中出現屢次，所以，應用規則的順序相當重要，這個順序就是級聯順序。根據CSS2的規範，級聯順序（從低到高）：

1.瀏覽器的聲明

2.用戶聲明

3.做者的通常聲明

4.做者的important聲明

5.用戶important聲明

瀏覽器聲明是最不重要的，用戶只有在聲明被標記爲important時纔會覆蓋做者的聲明。具備同等級別的聲明將根據specifity以及它們被定義時的順序進行排序。Html可視化屬性將被轉換爲匹配的css聲明，它們被視爲最低優先級的做者規則。

4.3.4.2特異性 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 */

style=」" /* a=1 b=0 c=0 d=0 -> specificity = 1,0,0,0 */

4.3.4.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使用一個標誌位標識全部頂層樣式表都已加載，若是在atach時樣式沒有徹底加載，則放置佔位符，並在文檔中標記，一旦樣式表完成加載就從新進行計算。

5.佈局

當渲染對象被建立並添加到樹中，他們並無位置和大小，計算這些值的過程稱爲layout或reflow。

Html使用基於流的佈局模型，意味着大部分時間，能夠以單一的途徑進行幾何計算。流中靠後的元素並不會影響前面元素的幾何特性，因此佈局能夠再文檔中從右向左。自上而下的進行。也存在一些例外，好比html tables。

座標系統相對於根frame，使用top和left座標。

佈局是一個遞歸的過程，由根渲染對象開始，它對應html文檔元素，佈局繼續遞歸的經過一些或全部的frame層級，爲每一個須要集合信息的渲染對象進行計算。

根渲染對象的位置是0,0，它的大小是viewport---瀏覽器窗口的可見部分。

全部的渲染對象都有一個layout或reflow方法，每一個渲染對象調用須要佈局的children的layout方法。

5.1髒位系統 Dirty Bit

爲了避免由於每一個小變化都所有從新佈局，瀏覽器使用一個dirty bit系統，一個渲染對象發生了變化或是被添加了，就標記它及它的children爲dirty---須要layout。存在兩個標識---dirty及children are dity，children are dirty說明即便這個渲染對象可能沒問題，但它至少有一個child須要layout。

5.2全局和增量佈局

當layout在整棵渲染樹觸發時，稱爲全局layout，這可能在下面這些狀況下發生：

1.一個全局的樣式改變影響全部的渲染對象，好比字號的改變

2.窗口resize

layout也能夠是增量的，這樣只有標識爲dirty的渲染對象會從新佈局（也將致使一些額外的佈局）。增量layout會在渲染對象dirty時異步觸發，例如，當網絡接收到新的內容並添加到Dom樹後，新的渲染對象會添加到渲染樹中。

圖18：增量layout

5.3異步和同步佈局

增量layout的過程是異步的，Firefox爲增量layout生成了reflow隊列，以及一個調度執行這些批處理命令。Webkit也有一個計時器用來執行增量layout---遍歷樹，爲dirty狀態的渲染對象從新佈局。

另外，當腳本請求樣式信息時，例如「offsetHeight」，會同步的觸發增量佈局。

全局的layout通常都是同步觸發。

有些時候，layout會被做爲一個廚師layout以後的回調，好比滑動條的滑動。

5.4優化

當一個layout由於resize或是渲染位置改變（並非大小改變）而觸發時，渲染對象的大小將會從緩存中讀取，而不會從新計算。

通常狀況下，若是隻有子樹發生改變，則layout並不從根開始。這種狀況發生在，變化發生在元素自身而且不影響它周圍元素，例如，將文本插入文本域（不然，每次擊鍵都將觸發從根部開始的重排）。

5.5佈局過程

layout通常有下面這幾個部分：

1.parent渲染對象決定它的寬度

2.parent渲染對象讀取children，並：

a.放置child渲染對象（設置它的x和y）

b.在須要時（他們當前爲dirty或是處於全局layout或者其餘緣由）調用child渲染對象的layout，這將計算child的告訴

3.parent渲染對象使用child渲染對象的累計高度，以及margin和padding的高度來設置本身的高度---這將被parent渲染對象的parent使用

4.將dirty標識設置爲false

Firefox佈局的輸出是一個「metrics」對象（nsHTMLReflowMetrics）。它包括渲染對象計算出的高度

5.6寬度計算

渲染對象的寬度使用容器的款速、渲染對象樣式中的寬度及margin、border進行計算。例如，下面這個div的寬度：

webkit中寬度的計算過程是（RenderBox類的calcWidth方法）：

容器的款速是容器的可用寬度和0中的最大值，這裏的可用款速爲：contentWidth=clientWidth()-paddingLeft()-paddingRight()，clientWwidth和clientHeight表明一個對象內部的不包括border和滑動條的大小
元素的寬度指樣式屬性width的值，他能夠經過計算容器的百分比獲得一個絕對值
加上水平方向上的border和padding

到這裏是最佳寬度的計算過程，如今計算寬度的最大值和最小值，若是最佳寬度大於最大寬度則使用最大寬度，若是小於最小寬度則使用最小寬度。最後緩存這個值，當須要layout但寬度未改變時使用。

5.7斷行

當一個渲染對象在佈局過程當中須要折行時，則暫停並告訴它的parent他須要折行，parent將建立額外的渲染對象並調用它們的layout。

6.繪製

繪製階段，遍歷渲染樹並調用渲染對象的paint方法將它們的內容顯示在屏幕上，繪製使用UI基礎組件，這在UI的章節有更多的介紹。

6.1全局和增量

和佈局同樣，繪製也能夠是全局的---繪製完整的樹--或增量的。在增量的繪製過程當中，一些渲染對象以不影響整棵樹的方式改變，改變的渲染對象使其在屏幕上的矩形區域失效，這將致使操做系統將其看作dirty區域，併產生一個paint時間，操做系統很巧妙的處理這個過程，並將多個區域合併爲一個。chrome中，這個過程更爲複雜，由於渲染對象在不一樣的進程中，而不是在主進程中。chrome在必定程度上模擬操做系統的行爲，表現爲監聽事件並派發消息給渲染根，在樹中查找到相關的渲染對象，重繪這個對象（每每還包括他的children）。

6.2繪製順序

CSS2定義了繪製過程的順序：http://www.w3.org/TR/CSS21/zindex.html。這個就是元素壓入堆棧的順序，這個順序影響着重繪，堆棧從後向前進行繪製。

一個塊渲染對象的堆棧順序是：

1.背景色

2.背景圖

3.border

4.children

5.outline

6.3火狐顯示列表

Firefox讀取渲染樹併爲繪製的矩形建立一個顯示列表，該列表以正確的繪製順序包含這個矩形相關的渲染對象。

用這樣的方法，可使重繪時只需查找一次樹，而不須要屢次查找---繪製全部的背景、全部的圖片、全部的border等等。

Firefox優化了這個過程，他不添加會被隱藏的元素，好比元素徹底在其餘不透明元素下面。

6.4webkit的矩形存儲

重繪前，webkit將舊的矩形保存爲位圖，而後只繪製新舊矩形的差集。

7.動態改變

瀏覽器老是試着以最小的動做響應一個變化，因此一個元素顏色的變化將只致使該元素的重繪，元素的位置變化將致使元素的佈局和重繪，添加一個Dom節點，也會致使這個元素的佈局和重繪。一些主要的變化，好比增長html元素的字號，將會致使緩存失效，從而引發整個頁面的佈局和重繪。

8.渲染引擎的線程

渲染引擎是單線程的，除了網絡操做之外，幾乎全部的事情都在單一的線程中處理，在Firefox和Safari中，這是瀏覽器的主線程，Chrome中這是tab的主線程。

網絡操做由幾個並行線程執行，並行鏈接的個數是受限的（一般是2~6個）。

8.1事件循環

瀏覽器主線程是一個時間循環，它被設計爲無限循環以保持執行過程的可用，等待事件（例如layout和paint事件）並執行它們。下面是Firefox的主要時間循環代碼。

while (!mExiting)

NS_ProcessNextEvent(thread);

9.CSS2的可視模型

9.1畫布 the canvas

根據CSS2規範，術語canvas用來描述格式化的結構所渲染的空間---瀏覽器繪製內容的地方。畫布對每一個維度空間都是無限大的，但瀏覽器基於viewport的大小選擇了一個初始寬度。

根據http://www.w3.org/TR/CSS2/zindex.html的定義，畫布若是是包含在其餘畫布內則是透明的，不然瀏覽器會指定一個顏色。

9.2CSS盒模型

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查看更多的默認樣式表示例。

9.3定位策略

1.normal---對象根據他在文檔中的位置定位，這意味着它在渲染樹和在Dom樹中位置一致，並根據它的盒模型和大小進行佈局。

2.float---對象先像普通流同樣佈局，而後儘量的向左或是向右移動

3.absolute---對象子啊渲染樹中的位置和Dom樹中位置無關

static和relative是normal，absolute和fixed屬於absolute。

在static定位中，不定義位置而使用默認的位置。其餘策略中，做者指定位置---top，bottom，left，right。

Box佈局的方式由這幾項決定：box的類型、box的大小、定位策略及擴展信息（好比圖片大小和屏幕尺寸）

9.4盒類型

Block box：構成一個塊，即在瀏覽器窗口上有本身的矩形：

Inline box：並無本身的塊區域，擔保函在一個塊狀區域內：

block一個挨着一個垂直格式化，inline則在水平方向上格式化：

Inline盒模型放置在行內或是line box中，每行至少和最高的box同樣高，當box以baseline對齊時---即一個元素的底部和另外一個box上除底部之外的某點對齊，行高能夠比最高的box高。當容器寬度不夠時，行內元素將被放到多行中，這在一個p元素中常常發生。

9.5定位

9.5.1相對

相對定位---先按照通常的定位，而後按所要求的差值移動。

9.5.2漂浮

一個浮動的box移動到一行的最左邊或是最右邊，其他的box圍繞在它周圍。下面這段html：

<p>

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

</p>

將顯示爲：

9.5.3絕對和固定 Absolute和Fixed

這種狀況下的佈局徹底不顧普通的文檔流，元素不屬於文檔流的一部分，大小取決於容器，Fixed時，容器爲viewport（可視區域）。

圖26：fixed

注意---fixed即便在文檔流滾動時也不會移動。

9.6分層Layered representation

這個由CSS屬性z-index指定，表示盒模型的第三個大小，即在z軸上的位置。Box分發到堆棧中（稱爲堆棧上下文），每一個堆棧中靠後的元素將被較早繪製，棧頂靠前的元素離用戶最近，當發生交疊時，將隱藏靠後的元素。堆棧根據z-index屬性排序，擁有z-index屬性的box造成了一個局部堆疊棧，viewport有外部堆棧，例如：