各瀏覽器處理網頁設計的原理
一、介紹
瀏覽器可以被認為是使用最廣泛的軟體,本文將介紹瀏覽器的工作原理,我們將看到,從你在地址欄輸入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規範中規定了瀏覽器解釋網頁設計文檔的方式,由W3C組織對這些規範進行維護,W3C是負責制定web標準的組織。
HTML規範的最新版本是HTML4(http://www.w3.org/TR/網頁設計401/),HTML5還在制定中(譯注:兩年前),最新的CSS規範版本是2(http://www.w3.org/TR/CSS2),CSS3也還正在制定中(譯注:同樣兩年前)。
這些年來,瀏覽器廠商紛紛開發自己的擴展,對規範的遵循並不完善,這為web開發者帶來了嚴重的相容性問題。
但是,瀏覽器的用戶介面則差不多,常見的用戶介面元素包括:
•用來輸入URI的位址欄
•前進、後退按鈕
•書籤選項
•用於刷新及暫停當前載入文檔的刷新、暫停按鈕
•用於到達首頁的首頁按鈕
奇怪的是,並沒有哪個正式公佈的規範對用戶介面做出規定,這些是多年來各瀏覽器廠商之間相互模仿和不斷改進的結果。
HTML5並沒有規定瀏覽器必須具有的UI元素,但列出了一些常用元素,包括位址欄、狀態欄及工具欄。還有一些瀏覽器有自己專有的功能,比如Firefox的下載管理。更多相關內容將在後面討論用戶介面時介紹。
瀏覽器的主要構成(High Level Structure)
瀏覽器的主要組件包括:
1. 用戶介面 - 包括位址欄、後退/前進按鈕、書籤目錄等,也就是你所看到的除了用來顯示你所請求頁面的主視窗之外的其他部分。
2. 瀏覽器引擎 - 用來查詢及操作轉譯引擎的介面。
3. 轉譯引擎 - 用來顯示請求的內容,例如,如果請求內容為網頁設計,它負責解析網頁設計及css,並將解析後的結果顯示出來。
4. 網路 - 用來完成網路調用,例如http請求,它具有平臺無關的介面,可以在不同平臺上工作。
5. UI後端 - 用來繪製類似組合選擇框及對話方塊等基本元件,具有不特定於某個平臺的通用介面,底層使用作業系統的用戶介面。
6. JS解釋器 - 用來解釋執行JS程式碼。
7. 資料存儲 - 屬於持久層,瀏覽器需要在硬碟中保存類似cookie的各種資料,HTML5定義了web database技術,這是一種羽量級完整的用戶端存儲技術
圖1:瀏覽器主要組件
需要注意的是,不同於大部分瀏覽器,Chrome為每個Tab分配了各自的轉譯引擎實例,每個Tab就是一個獨立的進程。
對於構成瀏覽器的這些元件,後面會逐一詳細討論。
二、轉譯引擎(The rendering engine)
轉譯引擎的職責就是轉譯,即在瀏覽器視窗中顯示所請求的內容。
預設情況下,轉譯引擎可以顯示網頁設計、xml文檔及圖片,它也可以借助插件(一種瀏覽器擴展)顯示其他類型資料,例如使用PDF閱讀器插件,可以顯示PDF格式,將由專門一章講解插件及擴展,這裏只討論轉譯引擎最主要的用途——顯示應用了CSS之後的網頁設計及圖片。
轉譯引擎簡介
本文所討論的瀏覽器——Firefox、Chrome和Safari是基於兩種轉譯引擎構建的,Firefox使用Geoko——Mozilla自主研發的轉譯引擎,Safari和Chrome都使用webkit。
Webkit是一款開源轉譯引擎,它本來是為Linux平臺研發的,後來由Apple移植到Mac及Windows上,相關內容請參考http://webkit.org。
轉譯主流程(The main flow)
轉譯引擎首先通過網路獲得所請求文檔的內容,通常以8K分塊的方式完成。
下面是轉譯引擎在取得內容之後的基本流程:
解析網頁設計以構建dom樹 -> 構建render樹 -> 佈局render樹 -> 繪製render樹
圖2:轉譯引擎基本流程
轉譯引擎開始解析網頁設計,並將標籤轉化為內容樹中的dom節點。接著,它解析外部CSS檔及style標籤中的樣式資訊。這些樣式資訊以及網頁設計中的可見性指令將被用來構建另一棵樹——render樹。
Render樹由一些包含有顏色和大小等屬性的矩形組成,它們將被按照正確的順序顯示到螢幕上。
Render樹構建好了之後,將會執行佈局過程,它將確定每個節點在螢幕上的確切座標。再下一步就是繪製,即遍曆render樹,並使用UI後端層繪製每個節點。
值得注意的是,這個過程是逐步完成的,為了更好的用戶體驗,轉譯引擎將會盡可能早的將內容呈現到螢幕上,並不會等到所有的網頁設計都解析完成之後再去構建和佈局render樹。它是解析完一部分內容就顯示一部分內容,同時,可能還在通過網路下載其餘內容。
圖3:webkit主流程
圖4:Mozilla的Geoko轉譯引擎主流程
從圖3和4中可以看出,儘管webkit和Gecko使用的術語稍有不同,他們的主要流程基本相同。Gecko稱可見的格式化元素組成的樹為frame樹,每個元素都是一個frame,webkit則使用render樹這個名詞來命名由轉譯物件組成的樹。Webkit中元素的定位稱為佈局,而Gecko中稱為回流。Webkit稱利用dom節點及樣式資訊去構建render樹的過程為attachment,Gecko在網頁設計和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可以是一個整數或一個運算式
如果一個語言的文法是上下文無關的,則它可以用正則解析器來解析。對上下文無關文法的一個直觀的定義是,該文法可以用BNF來完整的表達。可查看http://en.wikipedia.org/wiki/Context-free_grammar。
解析器類型(Types of parsers)
有兩種基本的解析器——自頂向下解析及自底向上解析。比較直觀的解釋是,自頂向下解析,查看語法的最高層結構並試著匹配其中一個;自底向上解析則從輸入開始,逐步將其轉換為語法規則,從底層規則開始直到匹配高層規則。
來看一下這兩種解析器如何解析上面的例子:
自頂向下解析器從最高層規則開始——它先識別出“2+3“,將其視為一個運算式,然後識別出”2+3-1“為一個運算式(識別運算式的過程中匹配了其他規則,但出發點是最高層規則)。
自底向上解析會掃描輸入直到匹配了一條規則,然後用該規則取代匹配的輸入,直到解析完所有輸入。
自底向上解析器稱為shift reduce解析器,因為輸入向右移動(想像一個指標首先指向輸入開始處,並向右移動),並逐漸簡化為語法規則。
自動化解析(Generating parsers automatically)
解析器生成器這個工具可以自動生成解析器,只需要指定語言的文法——辭彙表及語法規則,它就可以生成一個解析器。創建一個解析器需要對解析有深入的理解,而且手動的創建一個由較好性能的解析器並不容易,所以解析生成器很有用。Webkit使用兩個知名的解析生成器——用於創建語法分析器的Flex及創建解析器的Bison(你可能接觸過Lex和Yacc)。Flex的輸入是一個包含了符號定義的正則運算式,Bison的輸入是用BNF格式表示的語法規則。
HTML解析器(HTML Parser)
HTML解析器的工作是將網頁設計標識解析為解析樹。
HTML文法定義(The HTML grammar definition)
W3C組織制定規範定義了HTML的辭彙表和語法。
非上下文無關文法(Not a context free grammar)
正如在解析簡介中提到的,上下文無關文法的語法可以用類似BNF的格式來定義。
不幸的是,所有的傳統解析方式都不適用於網頁設計(當然我提出它們並不只是因為好玩,它們將用來解析css和js),網頁設計不能簡單的用解析所需的上下文無關文法來定義。
Html有一個正式的格式定義——DTD(Document Type Definition文檔類型定義)——但它並不是上下文無關文法,網頁設計更接近於xml,現在有很多可用的xml解析器,網頁設計有個xml的變體——x網頁設計,它們間的不同在於,網頁設計更寬容,它允許忽略一些特定標籤,有時可以省略開始或結束標籤。總的來說,它是一種soft語法,不像xml呆板、固執。
顯然,這個看起來很小的差異卻帶來了很大的不同。一方面,這是網頁設計流行的原因——它的寬容使web開發人員的工作更加輕鬆,但另一方面,這也使很難去寫一個格式化的文法。所以,網頁設計的解析並不簡單,它既不能用傳統的解析器解析,也不能用xml解析器解析。
HTML DTD
Html適用DTD格式進行定義,這一格式是用於定義SGML家族的語言,包括了對所有允許元素及它們的屬性和層次關係的定義。正如前面提到的,網頁設計 DTD並沒有生成一種上下文無關文法。
DTD有一些變種,標準模式只遵守規範,而其他模式則包含了對瀏覽器過去所使用標籤的支持,這麼做是為了相容以前內容。最新的標準DTD在http://www.w3.org/TR/網頁設計4/strict.dtd
DOM
輸出的樹,也就是解析樹,是由DOM元素及屬性節點組成的。DOM是文檔物件模型的縮寫,它是網頁設計文檔的物件表示,作為網頁設計元素的外部接口供js等調用。
樹的根是“document”對象。
和網頁設計一樣,DOM的規範也是由W3C組織制定的。訪問http://www.w3.org/DOM/DOMTR,這是使用文檔的一般規範。一個模型描述一種特定的網頁設計元素,可以在http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/idl-definitions.htm查看網頁設計定義。
這裏所謂的樹包含了DOM節點是說樹是由實現了DOM介面的元素構建而成的,瀏覽器使用已被瀏覽器內部使用的其他屬性的具體實現。
解析演算法(The parsing algorithm)
正如前面章節中討論的,hmtl不能被一般的自頂向下或自底向上的解析器所解析。
原因是:
1. 這門語言本身的寬容特性
2. 瀏覽器對一些常見的非法網頁設計有容錯機制
3. 解析過程是往復的,通常源碼不會在解析過程中發生改變,但在網頁設計中,腳本標籤包含的“document.write”可能添加標籤,這說明在解析過程中實際上修改了輸入。
不能使用正則解析技術,瀏覽器為網頁設計定制了專屬的解析器。
Html5規範中描述了這個解析演算法,演算法包括兩個階段——符號化及構建樹。
符號化是詞法分析的過程,將輸入解析為符號,網頁設計的符號包括開始標籤、結束標籤、屬性名及屬性值。
符號識別器識別出符號後,將其傳遞給樹構建器,並讀取下一個字元,以識別下一個符號,這樣直到處理完所有輸入。
圖9:HTML解析流程
符號識別演算法(The tokenization algorithm)
演算法輸出網頁設計符號,該演算法用狀態機表示。每次讀取輸入流中的一個或多個字元,並根據這些字元轉移到下一個狀態,當前的符號狀態及構建樹狀態共同影響結果,這意味著,讀取同樣的字元,可能因為當前狀態的不同,得到不同的結果以進入下一個正確的狀態。
這個演算法很複雜。
初始狀態為“Data State”,當遇到“<”字元,狀態變為“Tag open state”,讀取一個a-z的字元將產生一個開始標籤符號,狀態相應變為“Tag name state”,一直保持這個狀態直到讀取到“>”,每個字元都附加到這個符號名上,例子中創建的是一個網頁設計符號。
當讀取到“>”,當前的符號就完成了,此時,狀態回到“Data state”,“<body>”重複這一處理過程。到這裏,網頁設計和body標籤都識別出來了。現在,回到“Data state”,讀取“Hello world”中的字元“H”將創建並識別出一個字元符號,這裏會為“Hello world”中的每個字元生成一個字元符號。
這樣直到遇到“</body>”中的“<”。現在,又回到了“Tag open state”,讀取下一個字元“/”將創建一個閉合標籤符號,並且狀態轉移到“Tag name state”,還是保持這一狀態,直到遇到“>”。然後,產生一個新的標籤符號並回到“Data state”。後面的“</網頁設計>”將和“</body>”一樣處理。
在樹的構建階段,將修改以Document為根的DOM樹,將元素附加到樹上。每個由符號識別器識別生成的節點將會被樹構造器進行處理,規範中定義了每個符號相對應的Dom元素,對應的Dom元素將會被創建。這些元素除了會被添加到Dom樹上,還將被添加到開放元素堆疊中。這個堆疊用來糾正嵌套的未匹配和未閉合標籤,這個演算法也是用狀態機來描述,所有的狀態採用插入模式。
首先是“initial mode”,接收到網頁設計符號後將轉換為“before 網頁設計”模式,在這個模式中對這個符號進行再處理。此時,創建了一個HTMLHtmlElement元素,並將其附加到根Document對象上。
狀態此時變為“before head”,接收到body符號時,即使這裏沒有head符號,也將自動創建一個HTMLHeadElement元素並附加到樹上。
現在,轉到“in head”模式,然後是“after head”。到這裏,body符號會被再次處理,將創建一個HTMLBodyElement並插入到樹中,同時,轉移到“in body”模式。
然後,接收到字串“Hello world”的字元符號,第一個字元將導致創建並插入一個text節點,其他字元將附加到該節點。
接收到body結束符號時,轉移到“after body”模式,接著接收到網頁設計結束符號,這個符號意味著轉移到了“after after body”模式,當接收到檔結束符時,整個解析過程結束。
解析結束時的處理(Action when the parsing is finished)
在這個階段,瀏覽器將文檔標記為可交互的,並開始解析處於延時模式中的腳本——這些腳本在文檔解析後執行。
文檔狀態將被設置為完成,同時觸發一個load事件。
Html5規範中有符號化及構建樹的完整演算法(http://www.w3.org/TR/網頁設計5/syntax.網頁設計#網頁設計-parser)。
瀏覽器容錯(Browsers error tolerance)
你從來不會在一個網頁設計頁面上看到“無效語法”這樣的錯誤,瀏覽器修復了無效內容並繼續工作。
以下麵這段網頁設計為例:
這段網頁設計違反了很多規則(mytag不是合法的標籤,p及div錯誤的嵌套等等),但是瀏覽器仍然可以沒有任何怨言的繼續顯示,它在解析的過程中修復了網頁設計作者的錯誤。
瀏覽器都具有錯誤處理的能力,但是,另人驚訝的是,這並不是網頁設計最新規範的內容,就像書籤及前進後退按鈕一樣,它只是瀏覽器長期發展的結果。一些比較知名的非法網頁設計結構,在許多站點中出現過,瀏覽器都試著以一種和其他瀏覽器一致的方式去修復。
Html5規範定義了這方面的需求,webkit在網頁設計解析類開始部分的注釋中做了很好的總結。
解析器將符號化的輸入解析為文檔並創建文檔,但不幸的是,我們必須處理很多沒有很好格式化的網頁設計文檔,至少要小心下面幾種錯誤情況。
1. 在未閉合的標籤中添加明確禁止的元素。這種情況下,應該先將前一標籤閉合
2. 不能直接添加元素。有些人在寫文檔的時候會忘了中間一些標籤(或者中間標籤是可選的),比如HTML HEAD BODY TR TD LI等
3. 想在一個行內元素中添加塊狀元素。關閉所有的行內元素,直到下一個更高的塊狀元素
4. 如果這些都不行,就閉合當前標籤直到可以添加該元素。
下面來看一些webkit容錯的例子:
一些網站使用</br>替代<br>,為了相容IE和Firefox,webkit將其看作<br>。
程式碼:
Note -這裏的錯誤處理在內部進行,用戶看不到。
迷路的表格
這指一個表格嵌套在另一個表格中,但不在它的某個單格內。
webkit使用堆疊存放當前的元素內容,它將從外部表格的堆疊中彈出內部的表格,則它們變為了兄弟表格。
嵌套的表單元素
用戶將一個表單嵌套到另一個表單中,則第二個表單將被忽略。
太深的標籤繼承
www.liceo.edu.mx是一個由嵌套層次的站點的例子,最多只允許20個相同類型的標籤嵌套,多出來的將被忽略。
放錯了地方的網頁設計、body閉合標籤
又一次不言自明。
支持不完整的網頁設計。我們從來不閉合body,因為一些愚蠢的網頁總是在還未真正結束時就閉合它。我們依賴調用end方法去執行關閉的處理。
所以,web開發者要小心了,除非你想成為webkit容錯程式碼的範例,否則還是寫格式良好的網頁設計吧。
CSS解析(CSS parsing)
還記得簡介中提到的解析的概念嗎,不同於網頁設計,css屬於上下文無關文法,可以用前面所描述的解析器來解析。Css規範定義了css的詞法及語法文法。
這說明,一個規則集合具有一個或是可選個數的多個選擇器,這些選擇器以逗號和空格(S表示空格)進行分隔。每個規則集合包含大括弧及大括弧中的一條或多條以分號隔開的聲明。聲明和選擇器在後面進行定義。
Webkit CSS解析器(Webkit CSS parser)
Webkit使用Flex和Bison解析生成器從CSS語法檔中自動生成解析器。回憶一下解析器的介紹,Bison創建一個自底向上的解析器,Firefox使用自頂向下解析器。它們都是將每個css檔解析為樣式表物件,每個物件包含css規則,css規則物件包含選擇器和聲明物件,以及其他一些符合css語法的物件。
處理腳本及樣式表的順序(The order of processing scripts and style sheets)
腳本
web的模式是同步的,開發者希望解析到一個script標籤時立即解析執行腳本,並阻塞文檔的解析直到腳本執行完。如果腳本是外引的,則網路必須先請求到這個資源——這個過程也是同步的,會阻塞文檔的解析直到資源被請求到。這個模式保持了很多年,並且在網頁設計4及網頁設計5中都特別指定了。開發者可以將腳本標識為defer,以使其不阻塞文檔解析,並在文檔解析結束後執行。Html5增加了標記腳本為非同步的選項,以使腳本的解析執行使用另一個線程。
預解析(Speculative parsing)
Webkit和Firefox都做了這個優化,當執行腳本時,另一個線程解析剩下的文檔,並載入後面需要通過網路載入的資源。這種方式可以使資源並行載入從而使整體速度更快。需要注意的是,預解析並不改變Dom樹,它將這個工作留給主解析過程,自己只解析外部資源的引用,比如外部腳本、樣式表及圖片。
樣式表(Style sheets)
樣式表採用另一種不同的模式。理論上,既然樣式表不改變Dom樹,也就沒有必要停下文檔的解析等待它們,然而,存在一個問題,腳本可能在文檔的解析過程中請求樣式資訊,如果樣式還沒有載入和解析,腳本將得到錯誤的值,顯然這將會導致很多問題,這看起來是個邊緣情況,但確實很常見。Firefox在存在樣式表還在載入和解析時阻塞所有的腳本,而Chrome只在當腳本試圖訪問某些可能被未載入的樣式表所影響的特定的樣式屬性時才阻塞這些腳本。
四、轉譯樹構建(Render tree construction)
當Dom樹構建完成時,瀏覽器開始構建另一棵樹——轉譯樹。轉譯樹由元素顯示序列中的可見元素組成,它是文檔的視覺化表示,構建這棵樹是為了以正確的順序繪製文檔內容。
Firefox將轉譯樹中的元素稱為frames,WebKit則用renderer或轉譯物件來描述這些元素。
每個轉譯物件用一個和該節點的css盒模型相對應的矩形區域來表示,正如css2所描述的那樣,它包含諸如寬、高和位置之類的幾何資訊。盒模型的類型受該節點相關的display樣式屬性的影響(參考樣式計算章節)。下面的webkit程式碼說明了如何根據display屬性決定某個節點創建何種類型的轉譯物件。
元素的類型也需要考慮,例如,表單控制項和表格帶有特殊的框架。
在Webkit中,如果一個元素想創建一個特殊的轉譯物件,它需要重寫“createRenderer”方法,使轉譯物件指向不包含幾何資訊的樣式物件。
轉譯樹和Dom樹的關係(The render tree relation to the DOM tree)
轉譯物件和Dom元素相對應,但這種對應關係不是一對一的,不可見的Dom元素不會被插入轉譯樹,例如head元素。另外,display屬性為none的元素也不會在轉譯樹中出現(visibility屬性為hidden的元素將出現在轉譯樹中)。
還有一些Dom元素對應幾個可見物件,它們一般是一些具有複雜結構的元素,無法用一個矩形來描述。例如,select元素有三個轉譯物件——一個顯示區域、一個下拉清單及一個按鈕。同樣,當文本因為寬度不夠而折行時,新行將作為額外的轉譯元素被添加。另一個多個轉譯物件的例子是不規範的網頁設計,根據css規範,一個行內元素只能僅包含行內元素或僅包含塊狀元素,在存在混合內容時,將會創建匿名的塊狀轉譯物件包裹住行內元素。
一些轉譯物件和所對應的Dom節點不在樹上相同的位置,例如,浮動和絕對定位的元素在文本流之外,在兩棵樹上的位置不同,轉譯樹上標識出真實的結構,並用一個占位元結構標識出它們原來的位置。
創建樹的流程(The flow of constructing the tree)
Firefox中,表述為一個監聽Dom更新的監聽器,將frame的創建委派給Frame Constructor,這個構建器計算樣式(參看樣式計算)並創建一個frame。
Webkit中,計算樣式並生成轉譯物件的過程稱為attachment,每個Dom節點有一個attach方法,attachment的過程是同步的,調用新節點的attach方法將節點插入到Dom樹中。
處理網頁設計和body標籤將構建轉譯樹的根,這個根轉譯物件對應被css規範稱為containing block的元素——包含了其他所有塊元素的頂級塊元素。它的大小就是viewport——瀏覽器視窗的顯示區域,Firefox稱它為viewPortFrame,webkit稱為RenderView,這個就是文檔所指向的轉譯物件,樹中其他的部分都將作為一個插入的Dom節點被創建。
樣式計算(Style Computation)
創建轉譯樹需要計算出每個轉譯物件的可視屬性,這可以通過計算每個元素的樣式屬性得到。
樣式包括各種來源的樣式表,行內樣式元素及網頁設計中的視覺化屬性(例如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可以使用。
當一個元素和它的一個兄弟元素指向同一個樹節點時,完整的樣式上下文可以被它們共用。
假設我們解析網頁設計,遇到第二個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規則
•行內樣式屬性
•網頁設計視覺化屬性(對應為相應的樣式規則)
後面兩個很容易匹配到元素,因為它們所擁有的樣式屬性和網頁設計屬性可以將元素作為key進行對應。
就像前面問題2所提到的,css的規則匹配可能很狡猾,為了解決這個問題,可以先對規則進行處理,以使其更容易被訪問。
解析完樣式表之後,規則會根據選擇符添加一些hash對應,對應可以是根據id、class、標籤名或是任何不屬於這些分類的綜合對應。如果選擇符為id,規則將被添加到id對應,如果是class,則被添加到class對應,等等。
這個處理是匹配規則更容易,不需要查看每個聲明,我們能從對應中找到一個元素的相關規則,這個優化使在進行規則匹配時減少了95+%的工作量。
第一條規則將被插入class對應,第二條插入id對應,第三條是標籤對應。
我們首先找到p元素對應的規則,class對應將包含一個“error”的key,找到p.error的規則,div在id對應和標籤對應中都有相關的規則,剩下的工作就是找出這些由key對應的規則中哪些確實是正確匹配的。
這也是標籤對應產生的,因為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)
規則排序
規則匹配後,需要根據級聯順序對規則進行排序,WebKit先將小列表用冒泡排序,再將它們合併為一個大列表,WebKit通過為規則複寫“>”操作來執行排序:
逐步處理Gradual process
webkit使用一個標誌位元標識所有頂層樣式表都已載入,如果在attch時樣式沒有完全載入,則放置占位符,並在文檔中標記,一旦樣式表完成載入就重新進行計算。
五、佈局(Layout)
當轉譯物件被創建並添加到樹中,它們並沒有位置和大小,計算這些值的過程稱為layout或reflow。
Html使用基於流的佈局模型,意味著大部分時間,可以以單一的途徑進行幾何計算。流中靠後的元素並不會影響前面元素的幾何特性,所以佈局可以在文檔中從右向左、自上而下的進行。也存在一些例外,比如網頁設計 tables。
坐標系統相對於根frame,使用top和left座標。
佈局是一個遞迴的過程,由根轉譯物件開始,它對應網頁設計文檔元素,佈局繼續遞迴的通過一些或所有的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.網頁設計。這個就是元素壓入堆疊的順序,這個順序影響著繪製,堆疊從後向前進行繪製。
一個塊轉譯物件的堆疊順序是:
1. 背景色
2. 背景圖
3. border
4. children
5. outline
Firefox顯示列表
Firefox讀取轉譯樹並為繪製的矩形創建一個顯示列表,該列表以正確的繪製順序包含這個矩形相關的轉譯物件。
用這樣的方法,可以使重繪時只需查找一次樹,而不需要多次查找——繪製所有的背景、所有的圖片、所有的border等等。
Firefox優化了這個過程,它不添加會被隱藏的元素,比如元素完全在其他不透明元素下面。
WebKit矩形存儲
重繪前,WebKit將舊的矩形保存為點陣圖,然後只繪製新舊矩形的差集。
七、動態變化
瀏覽器總是試著以最小的動作響應一個變化,所以一個元素顏色的變化將只導致該元素的重繪,元素位置的變化將大致元素的佈局和重繪,添加一個Dom節點,也會大致這個元素的佈局和重繪。一些主要的變化,比如增加網頁設計元素的字型大小,將會導致緩存失效,從而引起整數的佈局和重繪。
八、轉譯引擎的線程
轉譯引擎是單線程的,除了網路操作以外,幾乎所有的事情都在單一的線程中處理,在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.網頁設計的定義,畫布如果是包含在其他畫布內則是透明的,否則瀏覽器會指定一個顏色。
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.網頁設計查看更多的預設樣式表示例。
定位策略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圍繞在它周圍。下麵這段網頁設計:
Absolute和Fixed
這種情況下的佈局完全不顧普通的文檔流,元素不屬於文檔流的一部分,大小取決於容器。Fixed時,容器為viewport(可視區域)。
注意-fixed即使在文檔流滾動時也不會移動。
Layered representation
這個由CSS屬性中的z-index指定,表示盒模型的第三個大小,即在z軸上的位置。Box分發到堆疊中(稱為堆疊上下文),每個堆疊中靠後的元素將被較早繪製,棧頂靠前的元素離用戶最近,當發生交疊時,將隱藏靠後的元素。堆疊根據z-index屬性排序,擁有z-index屬性的box形成了一個局部堆疊,viewport有外部堆疊。
轉貼來源:網頁設計部落格
參考文獻:
1.林建煌 (2007), 消費者行為, 台北市: 智勝文化.
2.林永惟、宋同正 (2008), 商業平面設計之設計品質, 商業設計學報, 12(), 19-34.
3.陳良進 (2000), 台灣地區公民營風景遊樂區網站比較之研究, 高雄餐旅學報, 3(), 19-28.
相關文章
我們如何從網頁設計中學到借鏡如何依網頁設計的首頁設計經驗更新網頁設計的首頁文案與6個文案要點問題做一個程式設計的自由人思考、學習網頁設計的原則和方式
最新文章
HVACKer:入侵隔離網絡的新型攻擊技術還有什麼不會被入侵?路由器 LED 燈已成為攻擊入口美 5 家獨角獸同天申請 IPO 掛牌,最狂的是一家估值 124 億美的數據分析新創!【台灣「智慧產業」開始佈局】緯創集團領投跨國 AI 新創 iKala,下一步拓展東南亞市場快可以用手機遠端遙控你的所有家電了