對規則進行處置以簡化匹配過程
若是終究沒有找到該佈局的任何劃定規矩定義，那麼如果這個結構是繼承型的，則找到其在內容樹中的parent的佈局，這類環境下，我們也成功的共用了卻構；如果這個構造是reset型的，則使用預設的值。
4、轉譯樹構建（Render tree construction）
詞法剖析就是將輸入分化為符號，符號是說話的辭彙表——根基有用單元的糾合。對於人類說話來講，它相當於我們字典中泛起的所有單詞。
解析演算法（The parsing algorithm）
Inline box：並沒有本身的塊狀區域，但包括在一個塊狀區域內
然後，領受到字串“Hello world”的字元符號，第一個字元將導致創建並插入一個text節點，其他字元將附加到該節點。
當Dom樹構建完成時，瀏覽器開始構建另外一棵樹——轉譯樹。轉譯樹由元素顯示序列中的可見元素組成，它是文檔的視覺化表示，構建這棵樹是為了以准確的挨次繪製文檔內容。
有些時候，layout會被作為一個初始layout以後的回調，比如滑動條的滑動翻譯
這意味著劃定規矩應用到三個div的後裔div元素，選擇樹上一條特定的路徑去搜檢，這可能需要遍曆節點樹，最後卻發現它只是兩個div的子女，其實不使用該法則，然後則需要沿著另外一條路徑去測驗考試
Dirty bit系統
這類環境下的佈局完全掉臂通俗的文檔流，元素不屬於文檔流的一部門，巨細取決於容器翻譯Fixed時，容器為viewport（可視區域）翻譯
語法：
八、轉譯引擎的線程
當一個layout因為resize或是轉譯位置改變（並非巨細改變）而觸發時，轉譯物件的巨細將會從緩存中讀取，而不會從新計較。
解析可以分為兩個子進程——語法闡發及詞法分析
按照W3C（World Wide Web Consortium萬維網聯盟）的瀏覽器統計資料，當前（2011年5月），Firefox、Safari及Chrome的市場佔有率綜合已接近 60％。（原文為2009年10月，資料沒有太大轉變）是以，可以說開源瀏覽器已佔據了瀏覽器市場的荊棘銅駝。
Html有一個正式的格局界說——DTD（Document Type Definition文檔類型定義）——但它並不是上下文無關文法，網頁設計更接近於xml，現在有良多可用的xml解析器，網頁設計有個xml的變體 ——x網頁設計，它們間的分歧在於，網頁設計更寬容，它許可忽略一些特定標籤，有時可以省略最先或結束標籤翻譯總的來講，它是一種soft語法，不像xml 機器、執拗翻譯
CSS盒模型描述了矩形盒，這些矩形盒是為文檔樹中的元素生成的，並根據可視的花式化模子進行結構。每個box包孕內容區域（如圖片、文本等）及可選的四周padding、border和margin區域。
Layered representation
來看一下這兩種解析器若何解析上面的例子：
轉譯引擎簡介
Firefox優化了這個過程，它不添加會被埋沒的元素，好比元素完全在其他不透明元素下面。
圖9：HTML解析流程
增量layout的進程長短同步的，Firefox為增量layout生成了reflow佇列，以及一個調劑執行這些批次處置號令翻譯WebKit也有一個計時器用來履行增量layout－遍曆樹，為dirty狀況的轉譯物件重新結構翻譯
圖6：從原始檔到解析樹
瀏覽器的首要功能是將用戶選擇的web資本出現出來，它需要從伺服器要求資本，並將其顯示在瀏覽器視窗中，資源的花樣凡是是HTML，也包括 PDF、image及其他花樣。用戶用URI（Uniform Resource Identifier同一資源辨認字）來指定所要求資本的位置，在網路一章有更多討論。
DTD有一些變種，標準模式只遵守規範，而其他模式則包括了對瀏覽器曩昔所使用標籤的支持，這麼做是為了相容之前內容。最新的標準DTD在http://www.w3.org/TR/網頁設計4/strict.dtd
Firefox佈局的輸出是一個“metrics”物件（nsHTMLReflowMetrics）。它包孕轉譯對象較量爭論出的高度。
Box結構的方式由這幾項決意：box的類型、box的巨細、定位策略及擴大資訊（好比圖片巨細和螢幕尺寸）。
逐步處理Gradual process
轉貼來源：網頁設計部落格
自動化解析（Generating parsers automatically）
轉譯引擎的職責就是轉譯，即在瀏覽器視窗中顯示所要求的內容翻譯
css2定義了繪製過程的按次——http://www.w3.org/TR/CSS21/zindex.網頁設計。這個就是元素壓入堆疊的順序，這個順序影響著繪製，堆疊從後向進步行繪製。
轉譯引擎起首通過網路取得所要求文檔的內容，平常以8K分塊的體例完成翻譯
一個浮動的box移動到一行的最左邊或是最右側，其餘的box環繞在它周圍翻譯下麵這段網頁設計：
詞彙表：我們的說話包羅整數、加號及減號。
轉譯引擎起頭解析網頁設計，並將標籤轉化為內容樹中的dom節點翻譯接著，它解析外部CSS檔及style標籤中的樣式資訊。這些樣式資訊和網頁設計中的可見性指令將被用來構建另外一棵樹——render樹。
Line breaking
預設的是inline，但瀏覽器樣式表設置了其他預設值，例如，div元素預設為block。可以拜候http://www.w3.org/TR/CSS2/sample.網頁設計查看更多的預設樣式默示例。
解析器－詞法闡發器（Parser－Lexer combination）
文法（Grammars）
layout進程
HTML5並沒有劃定瀏覽器必需具有的UI元素，但列出了一些常用元素，包孕位址欄、狀況欄及東西欄。還有一些瀏覽器有本身專有的功能，好比Firefox的下載辦理。更多相幹內容將在後面接頭用戶介面時介紹。
事宜迴圈
值得注意的是，這個進程是逐步完成的，為了更好的用戶體驗，轉譯引擎將會盡量早的將內容呈現到螢幕上，其實不會比及所有的網頁設計都解析完成以後再去構建和佈局render樹。它是解析完一部門內容就顯示一部份內容，同時，可能還在通過網路下載其餘內容。
Inline盒模子放置在行內或是line box中，每行最少和最高的box一樣高，當box以baseline對齊時——即一個元素的底部和另外一個box上除底部以外的某點對齊，行高可以比最高 的box高翻譯當容器寬度不敷時，行內元素將被放到多行中，這在一個p元素中常常發生翻譯
用如許的方法，可以使重繪時只需查找一次樹，而不需要多次查找——繪製所有的背景、所有的圖片、所有的border等等翻譯
圖20：增量layout
圖5：數學運算式樹節點
一般環境下，假如只有子樹産生改變，則layout並不從根最先。這類情形産生在，變化産生在元素本身並且不影響它四周元素，例如，將文本插入文本域（否則，每次擊鍵都將觸發從根入手下手的重排）。
DOM
然則，瀏覽器的用戶介面則差不多，常見的用戶介面元素包羅：
•用來輸入URI的位址欄
•前進、撤退退卻按鈕
•書籤選項
•用於刷新及暫停當前載入文檔的刷新、暫停按鈕
•用於達到首頁的首頁按鈕
瀏覽器主線程是一個事務迴圈，它被設計為無窮迴圈以連結履行過程的可用，等待事件（例如layout和paint事件）並履行它們翻譯下面是Firefox的首要事務迴圈程式碼翻譯
圖5中，我們從一個數學運算式構建了一個解析樹，這裏定義一個簡單的數學語言來看下解析過程。
劃定規矩排序
Floats
解析器生成器這個對象可以自動生成解析器，只需要指定說話的文法——詞彙表及語律例則，它就可以生成一個解析器。建立一個解析器需要對解析有深切的 理解，並且手動的建立一個由較好性能的解析器其實不輕易，所以解析生成器很有效。Webkit利用兩個知名的解析生成器——用於創建語法闡發器的Flex及 建立解析器的Bison（你可能接觸過Lex和Yacc）。Flex的輸入是一個包括了符號定義的正則運算式，Bison的輸入是用BNF格式表示的語法 法則。
當一個轉譯物件在結構過程當中需要折行時，則暫停並告訴它的parent它需要折行，parent將創建額外的轉譯物件並挪用它們的layout。
本文所接洽的瀏覽器——Firefox、Chrome和Safari是基於兩種轉譯引擎構建的，Firefox利用Geoko——Mozilla自主研發的轉譯引擎，Safari和Chrome都利用webkit翻譯
全局和增量layout
9、CSS2可視模子（CSS2 visual module）
樣式規則有幾個來曆：
•外部樣式表或style標籤內的css規則
•行內樣式屬性
•網頁設計視覺化屬性（對應為相應的樣式規則）
瀏覽器的首要功能
這裏所謂的樹包含了DOM節點是說樹是由實現了DOM介面的元素構建而成的，瀏覽器利用已被瀏覽器內部利用的其他屬性的具體實現。
HTML規範的最新版本是HTML4(http://www.w3.org/TR/網頁設計401/)，HTML5還在擬定中（譯注：兩年前），最新的CSS規範版本是2（http://www.w3.org/TR/CSS2），CSS3也還正在制定中（譯注：一樣兩年前）。
1. parent轉譯物件決定它的寬度
2. parent轉譯對象讀取chilidren，並：
while (!mExiting)
W3C組織制訂規範定義了HTML的辭彙表和語法翻譯
下面是轉譯引擎在取得內容以後的基本流程：
p {font-family:Verdana;font size:10px;font-weight:bold}
Html5規範中描寫了這個解析演算法，演算法包孕兩個階段——符號化及構建樹。
NS_ProcessNextEvent(thread);
定位策略Position scheme
Webkit和Firefox城市做這個處置懲罰。
顯然，這個看起來很小的差異卻帶來了很大的不同翻譯一方面，這是網頁設計風行的緣由——它的寬容使web開辟人員的工作更加輕鬆，但另外一方面，這也使很難去寫一個花式化的文法翻譯所以，網頁設計的解析其實不簡單，它既不克不及用傳統的解析器解析，也不能用xml解析器解析翻譯
轉譯物件的寬度利用容器的寬度、轉譯物件樣式中的寬度及margin、border進行計較。例如，下面這個div的寬度：
六、繪製（Painting）
Render樹由一些包括有色彩和巨細等屬性的矩形組成，它們將被依照正確的順序顯示到螢幕上。
相對定位——先依照一般的定位，然後按所要求的差值移動翻譯
圖3：webkit主流程
b. 在需要時（它們當前為dirty或是處於全局layout或其他緣由）挪用child轉譯物件的layout，這將較量爭論child的高度
圖1：瀏覽器首要組件
樹的根是“document”對象。
1.林建煌 (2007)翻譯社 消費者行為, 台北市: 智勝文化.
2.林永惟、宋同正 (2008), 貿易 平面設計 之設計品質, 貿易設計學報, 12()翻譯社 19-34.
3.陳良進 (2000), 台灣地區公民營景致遊樂區網站比力之研究, 高雄餐旅學報, 3(), 19-28.
很多時候，解析樹並非終究效果翻譯解析一般在轉換中使用——將輸入文檔轉換為另一種格式。編譯就是個例子，編譯器在將一段源碼編譯為機械碼的時辰，先將源碼解析為解析樹，然後將該樹轉換為一個機械碼文檔。
解析進程是迭代的，解析器從詞法闡發器處取到一個新的符號，並試著用這個符號匹配一條語律例則，假如匹配了一條規則，這個符號對應的節點將被添加到 解析樹上，然後解析器要求另外一個符號翻譯若是沒有匹配到劃定規矩，解析器將在內部保存該符號，並從詞法闡明器取下一個符號，直到所有內部保留的符號可以或許匹配一項 語律例則翻譯如果終究沒有找到匹配的法則，解析器將拋出一個異常，這意味著文檔無效或是包括語法錯誤翻譯
憑據CSS2規範，術語canvas用來描述花式化的佈局所轉譯的空間——瀏覽器繪製內容的處所翻譯畫布對每個維度空間都是無限大的，但瀏覽器基於viewport的大小選擇了一個初始寬度翻譯
1、介紹
正如前面章節中討論的，hmtl不能被一般的自頂向下或自底向上的解析器所解析。
Firefox顯示列表
HTML解析器（HTML Parser）
當轉譯物件被創建並添加到樹中，它們並沒有位置和巨細，計較這些值的進程稱為layout或reflow。
所有的元素都有一個display屬性，用來決定它們生成box的類型，例如：
1. 該說話的語法根基單位包羅運算式、term及操作符
2. 該說話可以包羅多個運算式
3. 一個運算式定義為兩個term經由過程一個操作符毗連
4. 操作符可所以加號或減號
5. term可所以一個整數或一個運算式
網路操作由幾個平行線程執行，並行毗鄰的個數是受限的（通常是2－6個）翻譯
為了不因為每一個小轉變都悉數重新佈局，瀏覽器使用一個dirty bit系統，一個轉譯物件産生了轉變或是被添加了，就符號它及它的children為dirty——需要layout翻譯存在兩個標識——dirty及 children are dirty，children are dirty申明即便這個轉譯物件可能沒問題，但它最少有一個child需要layout。
今天，有五種主流瀏覽器——IE、Firefox、Safari、Chrome及Opera。
非同步和同步layout
Firefox讀取轉譯樹並為繪製的矩形建立一個顯示列表，該列表以准確的繪製挨次包括這個矩形相幹的轉譯物件。
解析基於文檔依據的語法規則——文檔的說話或格式。每種可被解析的花樣必需具有由詞彙及語法規則構成的特定的文法，稱為上下文無關文法。人類說話不具有這一特性，是以不克不及被一般的解析手藝所解析。
static和relative是normal，absolute和fixed屬於absolute。
第一條劃定規矩將被插入class對應，第二條插入id對應，第三條是標籤對應翻譯
Html合用DTD格式進行界說，這一格局是用於界說SGML家族的語言，包孕了對所有許可元素及它們的屬性和條理關係的定義。正如前面提到的，網頁設計 DTD並沒有生成一種上下文無關文法。
a. 放置child轉譯物件（設置它的x和y）
解析竣事時的處置（Action when the parsing is finished）
Css2規範中定義的選擇符specifity以下：
•若是聲明來自style屬性，而不是一個選擇器的法則，則計1，不然計0（＝a）
•計算選擇器中id屬性的數量（＝b）
•計算選擇器中class及偽類的數目（＝c）
•計較選擇器中元素名及偽元素的數目（＝d）
block －生成塊狀box
自頂向下解析器從最高層法則入手下手——它先識別出“2+3“，將其視為一個運算式，然後辨認出”2+3-1“為一個運算式（識別運算式的過程中匹配了其他規則，但出發點是最高層法則）。
然後建立一個樣式上下文並將其放到上下文樹中，新的樣式上下文將指向規則樹中的節點F。
HTML和CSS規範中劃定了瀏覽器诠釋 網頁設計 文檔的體例，由W3C組織對這些規範進行保護，W3C是負責制訂web標準的組織。
HTML解析器的工作是將網頁設計標識解析為解析樹翻譯
none －不生成box
和網頁設計一樣，DOM的規範也是由W3C組織制定的。拜候http://www.w3.org/DOM/DOMTR，這是利用文檔的一般規範。一個模型描寫一種特定的網頁設計元素，可以在http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/idl-definitions.htm查看網頁設計界說翻譯
Render樹構建好了以後，將會履行結構進程，它將肯定每一個節點在螢幕上簡直切座標。再下一步就是繪製，即遍曆render樹，並利用UI後端層繪製每一個節點。
inline －生成一個或多個行內box
若是特定的節點添加了值，那麼需要做一些額外的計較以將其轉換為現實值，然後在樹上的節點緩存該值，使它的children可以使用。
這樣直到碰到“”中的“<”。現在，又回到了“Tag open state”，讀取下一個字元“/”將建立一個閉合標籤符號，而且狀況轉移到“Tag name state”，還是連結這一狀況，直到碰到“>”翻譯然後，產生一個新的標籤符號並回到“Data state”翻譯後面的“”將和“”一樣處置懲罰翻譯
WebKit矩形存儲
圖7：編譯流程
這指一個表格嵌套在另一個表格中，但不在它的某個單格內翻譯
這個由CSS屬性中的z-index指定，表示盒模子的第三個巨細，即在z軸上的位置翻譯Box分發到堆疊中（稱為堆疊上下文），每一個堆疊中靠後的元 素將被較早繪製，棧頂靠前的元素離用戶比來，當産生交疊時，將隱藏靠後的元素。堆疊憑據z-index屬性排序，具有z-index屬性的box形成了一 個局部堆疊，viewport有外部堆疊。
1. 這門說話本身的寬容特征
2. 瀏覽器對一些常見的不法網頁設計有容錯機制
3. 解析過程是往復的，每每源碼不會在解析過程當中發生改變，但在網頁設計中，腳本標籤包括的“document.write”可能添加標籤，這申明在解析過程當中現實上修改了輸入。
圖2：轉譯引擎根基流程
別的，當劇本要求樣式資訊時，例如“offsetHeight”，會同步的觸發增量結構翻譯
c. parent轉譯物件使用child轉譯物件的積累高度，和margin和padding的高度來設置自己的高度－這將被parent轉譯物件的parent利用
3、解析與DOM樹構建（Parsing and DOM tree construction）
Box類型
當layout在整棵轉譯樹觸發時，稱為全局layout，這可能在下面這些情形下産生：
預設環境下，轉譯引擎可以顯示網頁設計、xml文檔及圖片，它也能夠借助插件（一種瀏覽器擴大）顯示其他類型資料，例如利用PDF浏覽器插件，可以顯示PDF花式，將由專門一章講授插件及擴展，這裏只接頭轉譯引擎最首要的用途——顯示應用了CSS之後的網頁設計及圖片翻譯
參考文獻：
瀏覽器聲明是最不重要的，用戶只有在聲明被標記為important時才會籠蓋作者的聲明。具有同等級其它聲明將按照specifity和它們被界說時的遞次進行排序。Html視覺化屬性將被轉換為匹配的css聲明，它們被視為最低優先挨次的作者法則。
轉譯引擎是單線程的，除網路操作以外，幾近所有的工作都在單一的線程中處置，在Firefox和Safari中，這是瀏覽器的主線程，Chrome中這是tab的主線程翻譯
七、動態轉變
Specifity
瀏覽器可以被認為是利用最廣泛的軟體，本文將介紹瀏覽器的工作道理，天成翻譯公司們將看到，從
當讀取到“>”，當前的符號就完成了，此時，狀況回到“Data state”，“
2、轉譯引擎（The rendering engine）
語法分析指對語言應用語法規則翻譯
這裏有三種策略：
優化
解析網頁設計以構建dom樹 -> 構建render樹 -> 佈局render樹 -> 繪製render樹
以下麵這段網頁設計為例：
http://www.piece2ec.com.tw/news.asp?ID=1872
這也是標籤對應產生的，因為key是最右邊的選擇符，但它並不匹配這裏的div元素，因為這裏的div沒有table祖先。
有兩種根基的解析器——自頂向下解析及自底向上解析。比力直觀的解釋是，自頂向下解析，查看語法的最高層結構並試著匹配其中一個；自底向上解析則從輸入開始，逐步將其轉換為語律例則，從底層法則最先直到匹配高層劃定規矩。
和結構一樣，繪製也能夠是全局的——繪製完整的樹——或增量的翻譯在增量的繪製過程當中，一些轉譯物件以不影響整棵樹的方式改變，改變的轉譯物件使其在 螢幕上的矩形區域失效，這將導致功課系統將其看作dirty區域，並產生一個paint事務，功課系統很奇妙的處置這個進程，並將多個區域合併為一個。 Chrome中，這個進程更複雜些，因為轉譯物件在分歧的進程中，而不是在主進程中。Chrome在必然程度上類比功課系統的行為，表現為監聽事件並派發 動靜給轉譯根，在樹中查找到相幹的轉譯物件，重繪這個物件（常常還包羅它的children）。
樣式表的級聯順序
狀況此時變為“before head”，接收到body符號時，即使這裏沒有head符號，也將自動建立一個HTMLHeadElement元素並附加到樹上。
1. 用戶介面 － 包括位址欄、撤退退卻/進步按鈕、書籤目錄等，也就是
2. 瀏覽器引擎 － 用來查詢及操作轉譯引擎的介面。
3. 轉譯引擎 － 用來顯示請求的內容，例如，假如要求內容為網頁設計，它負責解析網頁設計及css，並將解析後的結果顯示出來。
4. 網路 － 用來完成網路挪用，例如http要求，它具有平臺無關的介面，可以在分歧平臺上工作。
5. UI後端 － 用來繪製雷同組合選擇框及對話方塊等根基元件，具有不特定於某個平臺的通用介面，底層利用作業系統的用戶介面。
6. JS註釋器 － 用來诠釋履行JS程式碼翻譯
7. 資料存儲 － 屬於持久層，瀏覽器需要在硬碟中保留近似cookie的各類資料，HTML5界說了web database手藝，這是一種羽量級完整的用戶端存儲技術
webkit利用一個標誌位元標識所有頂層樣式表都已載入，若是在attch時樣式沒有完全載入，則放置占位符，並在文檔中符號，一旦樣式表完成載入就從新進行計較。
寬度計較
WebkKit節點援用樣式物件（轉譯樣式），某些環境下，這些物件可以被節點間共用，這些節點需要是兄弟或是表兄弟節點，並且：
元素的類型也需要考慮，例如，表單節制項和表格帶有非凡的框架。
奇異的是，並沒有哪個正式發佈的規範對用戶介面做出劃定，這些是多年來各瀏覽器廠商之間相互模仿和絡續改良的結果。
我們來看一下瀏覽器若何處置懲罰這些問題：
樣式物件具有對應所有可見屬性的屬性，如果特性沒有被任何匹配的法則所定義，那麼一些特性可以從parent的樣式物件中繼承，別的一些使用預設值翻譯
瀏覽器容錯（Browsers error tolerance）
所有的轉譯物件都有一個layout或reflow方法，每一個轉譯物件挪用需要結構的children的layout方式翻譯
你從來不會在一個網頁設計頁面上看到“無效語法”如許的錯誤，瀏覽器修復了無效內容並繼續工作。
嵌套的表單元素
webkit中寬度的計算進程是（RenderBox類的calcWidth方法）：
•容器的寬度是容器的可用寬度和0中的最大值，這裏的可用寬度 為：contentWidth=clientWidth()-paddingLeft()-paddingRight()，clientWidth和 clientHeight代表一個物件內部的不包羅border和滑動條的巨細
•元素的寬度指樣式屬性width的值，它可以經由過程計較容器的百分比獲得一個絕對值
•加上水準標的目的上的border和padding
Webkit和Firefox都做了這個優化，當履行腳本時，另一個線程解析剩下的文檔，並載入後面需要經由過程網路載入的資本翻譯這類體例可使資源並 行載入從而使整體速度更快翻譯需要注意的是，預解析並不改變Dom樹，它將這個工作留給主解析過程，自己只解析外部資本的援用，好比外部劇本、樣式表及圖 片翻譯
HTML文法界說（The HTML grammar definition）
演算法輸出網頁設計符號，該演算法用狀況機表示。每次讀取輸入流中的一個或多個字元，並根據這些字元轉移到下一個狀況，當前的符號狀況及構建樹狀態配合影響效果，這意味著，讀取同樣的字元，可能因為當前狀況的分歧，得到不同的成果以進入下一個准確的狀況。
樣式上下文樹緩存完整的佈局（包孕計算後的值），如許，假如底層節點沒有為一個佈局供應定義，則利用上層節點緩存的構造。
Webkit利用Flex和Bison解析生成器從CSS語法檔中主動生成解析器。回想一下解析器的介紹，Bison建立一個自底向上的解析 器，Firefox利用自頂向下解析器。它們都是將每一個css檔解析為樣式表物件，每個物件包括css法則，css規則物件包括選擇器和聲明物件，和其 他一些符合css語法的物件。
1. 樣式資料長短常大的佈局，保存大量的樣式屬性會帶來記憶體問題。
2. 假如不進行優化，找到每個元素匹配的劃定規矩會致使機能問題，為每一個元素查找匹配的法則都需要遍曆整個劃定規矩表，這個過程有很大的工作量。選擇符可能有複雜的構造，匹配進程如果沿著一條起頭看似正確，後來卻被證實是無用的路徑，則必需去測驗考試另外一條路徑。
太深的標籤擔當
放錯了地方的網頁設計、body閉合標籤
緣由是：
layout一般有下面這幾個部分：
劇本
轉譯物件和Dom元素相對應，但這類對應關係不是一對一的，弗成見的Dom元素不會被插入轉譯樹，例如head元素。別的，display屬性為none的元素也不會在轉譯樹中出現（visibility屬性為hidden的元素將呈現在轉譯樹中）。
根據http://www.w3.org/TR/CSS2/zindex.網頁設計的界說，畫布若是是包括在其他畫布內則是透明的，不然瀏覽器會指定一個色彩。
如果一個語言的文法是上下文無關的，則它可以用正則解析器來解析翻譯對上下文無關文法的一個直觀的定義是，該文法可以用BNF來完整的表達。可查看http://en.wikipedia.org/wiki/Context-free_grammar。
自底向上解析會掃描輸入直到匹配了一條法則，然後用該劃定規矩取代匹配的輸入，直到解析完所有輸入翻譯
所有匹配的劃定規矩都存儲在規則樹中，一條路徑中的底層節點具有最高的優先按次，這棵樹包含了所找到的所有法則匹配的路徑（譯注：可以取巧理解為每條路 徑對應一個節點，路徑上包括了該節點所匹配的所有法則）翻譯劃定規矩樹並不是一開始就為所有節點進行計較，而是在某個節點需要計算樣式時，才進行相應的計算並將 計較後的路徑添加到樹中翻譯
Relative
這個問題的產生是因為存在不止一處的定義，這裏用級聯挨次解決這個問題。
解析實例Parsing example
div div div div｛…｝
對於組成瀏覽器的這些元件，後面會一一詳細接洽翻譯
全局的layout一般都是同步觸發。
一些網站使用
替換
，為了相容IE和Firefox，webkit將其看做
翻譯
解析完樣式表以後，劃定規矩會按照選擇符添加一些hash對應，對應可所以按照id、class、標籤名或是任何不屬於這些分類的綜合對應翻譯假如選擇符為id，規則將被添加到id對應，若是是class，則被添加到class對應，等等翻譯
Html5規範界說了這方面的需求，webkit在網頁設計解析類入手下手部分的注釋中做了很好的總結。
Firefox中，表述為一個監聽Dom更新的監聽器，將frame的建立委派給Frame Constructor，這個構建器計較樣式（參看樣式計算）並建立一個frame。
樣式表來曆於瀏覽器預設樣式表，及頁面作者和用戶供應的樣式表——有些樣式是瀏覽器用戶供應的（瀏覽器許可用戶定義喜好的樣式，例如，在Firefox中，可以通過在Firefox Profile目次下放置樣式表實現）。
繪製按次
到這裏是最好寬度的較量爭論過程，目下當今計算寬度的最大值和最小值，假如最佳寬度大於最大寬度則使用最大寬度，若是小於最小寬度則利用最小寬度。最後緩存這個值，當需要layout但寬度未改變時利用。
現在我們需要填充這個樣式上下文，先從填充margin構造入手下手，既然最後一個規則節點沒有添加margin佈局，沿著路徑向上，直到找到緩存的前 面插入節點計較出的佈局，天成翻譯公司們發現B是最近的指定margin值的節點。因為已經有了color結構的定義，所以不能使用緩存的結構，既然color只有 一個屬性，也就不需要沿著路徑向上填充其他屬性。計較出終究值（將字串轉換為RGB等），並緩存計較後的結構。
符號化是詞法分析的進程，將輸入解析為符號，網頁設計的符號包孕開始標籤、竣事標籤、屬性名及屬性值。
每一個節點生成0－n個如許的box翻譯
CSS解析（CSS parsing）
佈局是一個遞迴的過程，由根轉譯物件開始，它對應網頁設計文檔元素，結構繼續遞迴的經由過程一些或所有的frame層級，為每一個需要幾何資訊的轉譯物件進行計較。
自底向上解析器稱為shift reduce解析器，因為輸入向右移動（想像一個指標起首指向輸入入手下手處，並向右移動），並逐步簡化為語律例則。
Html5規範中有符號化及構建樹的完全演算法(http://www.w3.org/TR/網頁設計5/syntax.網頁設計#網頁設計-parser)翻譯
坐標系統相對於根frame，利用top和left座標。
既然解析是轉譯引擎中一個特別很是重要的進程，我們將略微深切的研究它。起首扼要介紹一下解析。
解析一個文檔行將其轉換為具有必然意義的結構——編碼可以理解和利用的工具。解析的結果凡是是表達文檔佈局的節點樹，稱為解析樹或語法樹。
Firefox利用一個“state”物件（nsHTMLReflowState）做為參數去結構（firefox稱為reflow），state包括parent的寬度及其他內容。
每一個轉譯物件用一個和該節點的css盒模子相對應的矩形區域來表示，正如css2所描述的那樣，它包含諸如寬、高和位置之類的幾何資訊。盒模型的類 型受該節點相幹的display樣式屬性的影響（參考樣式計較章節）。下面的webkit程式碼申明了若何按照display屬性決意某個節點建立何種類 型的轉譯物件。
符號辨認演算法（The tokenization algorithm）
還有一些Dom元素對應幾個可見物件，它們一般是一些具有複雜佈局的元素，沒法用一個矩形來描寫。例如，select元素有三個轉譯物件——一個顯 示區域、一個下拉清單及一個按鈕。一樣，當文本因為寬度不敷而折行時，新即將作為額外的轉譯元素被添加。另外一個多個轉譯物件的例子是不規範的網頁設計，根 據css規範，一個行內元素只能僅包含行內元素或僅包括塊狀元素，在存在混合內容時，將會建立匿名的塊狀轉譯物件包裹住行內元素。
總結一下，共用樣式物件（結構中完整或部分內容）解決了問題1和3，Firefox的法則樹幫助以正確的挨次應用規則。
Webkit是一款開源轉譯引擎，它原本是為Linux平臺研發的，後來因Apple移植到Mac及Windows上，相幹內容請參考http://webkit.org翻譯
計較樣式的一些堅苦：
用戶將一個表單嵌套到另外一個表單中，則第二個表單將被疏忽。
www.liceo.edu.mx是一個由嵌套條理的站點的例子，最多只答應20個不異類型的標籤嵌套，多出來的將被忽略。
樣式包羅各種起原的樣式表，行內樣式元素及網頁設計中的視覺化屬性（例如bgcolor），視覺化屬性轉化為css樣式屬性。
Absolute和Fixed
這段網頁設計違反了很多規則（mytag不是合法的標籤，p及div毛病的嵌套等等），但是瀏覽器仍然可以沒有任何怨言的繼續顯示，它在解析的過程當中修復了網頁設計作者的錯誤。
那麼這個p在內容樹中的子節點div，會共用和它parent一樣的font構造，這種情況發生在沒有為這個div指定font規則時。
處置懲罰劇本及樣式表的順序（The order of processing scripts and style sheets）
轉譯樹和Dom樹的關係（The render tree relation to the DOM tree）
畫布The Canvas
”反複這一處置懲罰進程。到這裏，網頁設計和body標籤都識別出來了。如今，回到“Data state”，讀取“Hello world”中的字元“H”將建立並辨認出一個字元符號，這裏會為“Hello world”中的每一個字元生成一個字元符號。
使用法則樹較量爭論樣式上下文
重繪前，WebKit將舊的矩形保留為點陣圖，然後只繪製新舊矩形的差集。
圖14：Firefox樣式上下文樹
全局和增量
轉換（Translation）
瀏覽器的首要構成（High Level Structure）
下面來看一些webkit容錯的例子：
webkit利用堆疊寄存當前的元素內容，它將從外部表格的堆疊中彈出內部的表格，則它們變為了兄弟表格翻譯
假設我們解析網頁設計，碰到第二個div標籤，天成翻譯公司們需要為這個節點建立樣式上下文，並填充它的樣式佈局翻譯
我們將樹上的路徑看成辭典中的單詞，假如已較量爭論出了如下的法則樹：
web的模式是同步的，開辟者但願解析到一個script標籤時立即解析履行劇本，並阻塞文檔的解析直到劇本履行完。如果劇本是外引的，則網路必需 先請求到這個資本——這個進程也是同步的，會阻塞文檔的解析直到資本被要求到翻譯這個模式保持了許多年，而且在網頁設計4及網頁設計5中都特別指定了。開辟 者可以將劇本標識為defer，以使其不阻塞文檔解析，並在文檔解析竣事後履行。Html5增添了標記劇本為非同步的選項，以使劇本的解析執行利用另外一個 線程翻譯
在Webkit中，若是一個元素想建立一個非凡的轉譯物件，它需要重寫“createRenderer”方式，使轉譯物件指向不包括幾何資訊的樣式物件。
3. 利用法則觸及非常複雜的級聯，它們定義了規則的條理
程式碼：
例如，若是我們為一個paragraph的文字添加法則：
樣式上下文按結構劃分，這些結構包括近似border或color這樣的特定分類的樣式資訊翻譯一個結構中的所有特性不是擔當的就長短擔當的，對繼續 的特性，除非元素本身有定義，不然就從它的parent擔當。非繼續的特性（稱為reset特征）假如沒有界說，則利用預設的值。
樣式表（Style sheets）
在樹的構建階段，將修改以Document為根的DOM樹，將元素附加到樹上翻譯每一個由符號辨認器辨認生成的節點將會被樹組織器進行處理，規範中界說 了每一個符號相對應的Dom元素，對應的Dom元素將會被建立翻譯這些元素除會被添加到Dom樹上，還將被添加到開放元素堆疊中翻譯這個堆疊用來改正嵌套的未 匹配和未閉合標籤，這個演算法也是用狀態機來描寫，所有的狀態採用插入模式翻譯
Firefox法則樹（Firefox rule tree）
瀏覽器都具有毛病處置的能力，可是，另人驚訝的是，這並非網頁設計最新規範的內容，就像書籤及前進撤退退卻按鈕一樣，它只是瀏覽器恒久發展的成果。一些比力知名的不法網頁設計構造，在很多站點中呈現過，瀏覽器都試著以一種和其他瀏覽器一致的體式格局去修復。
處置懲罰網頁設計和body標籤將構建轉譯樹的根，這個根轉譯物件對應被css規範稱為containing block的元素——包括了其他所有塊元素的頂級塊元素翻譯它的巨細就是viewport——瀏覽器視窗的顯示區域，Firefox稱它為 viewPortFrame，webkit稱為RenderView，這個就是文檔所指向的轉譯物件，樹中其他的部份都將作為一個插入的Dom節點被創 建。
就像前面問題2所提到的，css的法則匹配可能很桀黠，為了解決這個問題，可以先對規則進行處置，以使其更容易被會見翻譯
創建轉譯樹需要計較出每個轉譯物件的可視屬性，這可以經由過程計較每一個元素的樣式屬性獲得。
Firefox將轉譯樹中的元素稱為frames，WebKit則用renderer或轉譯物件來描寫這些元素。
不克不及利用正則解析技術，瀏覽器為網頁設計定制了專屬的解析器。
假如需要為內容樹中的另一個節點匹配規則，此刻知道匹配的規則（以正確的順序）為B-E-I，因為我們已計算出了路徑A-B-E-I-L，所以樹上已經存在了這條路徑，剩下的工作就很少了翻譯
圖4：Mozilla的Geoko轉譯引擎主流程
在這個階段，瀏覽器將文檔標識表記標幟為可交互的，並起頭解析處於延時模式中的劇本——這些劇本在文檔解析後履行。
一個樣式屬性的聲明可能在幾個樣式表中出現，或是在一個樣式表中出現屢次，因此，應用法則的順序至關重要，這個挨次就是級聯順序。按照css2的規範，級聯遞次為（從低到高）：
1. 瀏覽器聲明
2. 用戶聲明
3. 作者的一般聲明
4. 作者的important聲明
5. 用戶important聲明
共用樣式資料（Sharing style data）
瀏覽器總是試著以最小的動作響應一個轉變，所以一個元素色彩的變化將只致使該元素的重繪，元素位置的轉變將大致元素的結構和重繪，添加一個Dom節 點，也會大致這個元素的佈局和重繪翻譯一些主要的變化，比如增添網頁設計元素的字型巨細，將會致使緩存失效，從而引發整數的結構和重繪。
輸出的樹，也就是解析樹，是由DOM元素及屬性節點構成的。DOM是文檔物件模子的縮寫，它是網頁設計文檔的物件表示，作為網頁設計元素的外部接供詞js等挪用。
還記得簡介中提到的解析的概念嗎，分歧於網頁設計，css屬於上下文無關文法，可以用前面所描寫的解析器來解析。Css規範定義了css的詞法及語法文法。
當為一個特定的元素計較樣式時，起首計算出規則樹中的一條路徑，或是利用已經存在的一條，然後使用路徑中的規則去填充新的樣式上下文，從樣式的底層 節點起頭，它具有最高優先順序（通常是最特定的選擇器），遍曆法則樹，直到填滿構造。如果在阿誰法則節點沒有界說所需的結構規則，則沿著路徑向上，直到找 到該構造劃定規矩。
定位Position
法則匹配後，需要憑據級聯遞次對法則進行排序，WebKit先將小列表用冒泡排序，再將它們合併為一個大列表，WebKit經由過程為劃定規矩複寫“>”操作來執行排序：
1. 這些元素必需處於不異的滑鼠狀況（比如不能一個處於hover，而另一個不是）
2. 不克不及有元素具有id
3. 標籤名必需匹配
4. class屬性必需匹配
5. 對應的屬性必需不異
6. 鏈結狀態必須匹配
7. 焦點狀態必需匹配
8. 不克不及有元素被屬性選擇器影響
9. 元素不克不及有行內樣式屬性
10. 不克不及有生效的兄弟選擇器，webcore在任何兄弟選擇器相遇時只是簡單的拋出一個全局轉換，而且在它們顯示時使全部文檔的樣式共用失效，這些包括＋選擇器和類似:first-child和:last-child如許的選擇器。
解析器一般將工作分派給兩個元件——詞法闡明器（有時也叫分詞器）負責將輸入分解為合法的符號，解析器則根據語言的語法規則闡發文檔佈局，從而構建解析樹，詞法剖析器知道怎麼跳過空白和換行之類的無關字元翻譯
CSS盒模型
正如在解析簡介中提到的，上下文無關文法的語法可以用類似BNF的格式來界說。
支撐不完全的網頁設計。我們從來不閉合body，因為一些愚昧的網頁老是在還未真正結束時就閉合它翻譯我們依靠挪用end方式去履行封閉的處置。
d. 將dirty標識設置為false
當一個元素和它的一個兄弟元素指向同一個樹節點時，完全的樣式上下文可以被它們共用。
這個演算法很複雜。
Html使用基於流的佈局模型，意味著大部門時候，可以以單一的路子進行幾何較量爭論。流中靠後的元素其實不會影響前面元素的幾何特征，所以結構可以在文檔中從右向左、自上而下的進行。也存在一些破例，好比網頁設計 tables。
例如，解析“2＋3－1”這個運算式，可能返回這樣一棵樹。
在static定位中，不界說位置而利用預設的位置翻譯其他策略中，作者指定位置——top、bottom、left、right。
非上下文無關文法（Not a context free grammar）
從圖3和4中可以看出，儘管webkit和Gecko利用的術語稍有分歧，他們的首要流程根基溝通。Gecko稱可見的花式化元素構成的樹為 frame樹，每個元素都是一個frame，webkit則使用render樹這個名詞來命名由轉譯物件構成的樹。Webkit中元素的定位稱為結構，而 Gecko中稱為回流。Webkit稱利用dom節點及樣式資訊去構建render樹的進程為attachment，Gecko在網頁設計和dom樹之間 附加了一層，這層稱為內容領受器，相當製造dom元素的工廠。下面將討論流程中的各個階段。
天成翻譯公司們進行劃定規矩匹配，找到這個div匹配的劃定規矩為1、2、6，我們發現規則樹上已經存在了一條我們可以使用的路徑1、2，我們只需為法則6新增一個節點添加到下面（就是法則樹中的F）。
本文將基於一些開源瀏覽器的例子——Firefox、Chrome及Safari，Safari是部門開源的。
1. 在未閉合的標籤中添加明白制止的元素翻譯這類情況下，應當先將前一標籤閉合
2. 不克不及直接添加元素翻譯有些人在寫文檔的時候會忘了中心一些標籤（或者中央標籤是可選的），好比HTML HEAD BODY TR TD LI等
3. 想在一個行內元素中添加塊狀元素。封閉所有的行內元素，直到下一個更高的塊狀元素
4. 假如這些都不可，就閉合當前標籤直到可以添加該元素翻譯
所以，web開辟者要謹慎了，除非你想成為webkit容錯程式碼的範例，不然照舊寫格局良好的網頁設計吧。
Firefox用兩個樹用來簡化樣式較量爭論－法則樹和樣式上下文樹，WebKit也有樣式物件，但它們並沒有存儲在近似樣式上下文樹如許的樹中，只是由Dom節點指向其相幹的樣式翻譯
初始狀態為“Data State”，當碰到“<”字元，狀況變為“Tag open state”，讀取一個a－z的字元將產生一個開始標籤符號，狀況響應變為“Tag name state”，一直連結這個狀況直到讀取到“>”，每個字元都附加到這個符號名上，例子中建立的是一個網頁設計符號。
樣式表採用另外一種分歧的模式翻譯理論上，既然樣式表不改變Dom樹，也就沒有需要停下文檔的解析等待它們，然而，存在一個問題，腳本可能在文檔的解析 過程中請求樣式資訊，若是樣式還沒有載入息爭析，劇本將獲得毛病的值，顯然這將會導致許多問題，這看起來是個邊緣情形，但確實很常見翻譯Firefox在存 在樣式表還在載入和解析時梗阻所有的劇本，而Chrome只在當劇本試圖會見某些可能被未載入的樣式表所影響的特定的樣式屬性時才壅塞這些腳本翻譯
佈局化
文檔狀況將被設置為完成，同時觸發一個load事宜。
樣式計較（Style Computation）
解析器將符號化的輸入解析為文檔並建立文檔，但不幸的是，我們必需處置很多沒有很好花樣化的網頁設計文檔，最少要謹慎下面幾種毛病環境。
Note －這裏的錯誤處置懲罰在內部進行，用戶看不到翻譯
這個處置懲罰是匹配法則更輕易，不需要查看每個聲明，天成翻譯公司們能從對應中找到一個元素的相幹劃定規矩，這個優化使在進行規則匹配時削減了95+%的工作量翻譯
一些轉譯物件和所對應的Dom節點不在樹上不異的位置，例如，浮動和絕對定位的元素在文本流之外，在兩棵樹上的位置分歧，轉譯樹上標識出真實的佈局，並用一個占位元構造標識出它們本來的位置。
HTML DTD
Webkit CSS解析器（Webkit CSS parser）
第二個span元素更簡單，進行劃定規矩匹配後發現它指向規則G，和前一個span一樣，既然有兄弟節點指向統一個節點，就可以共用完全的樣式上下文，只需指向前一個span的上下文。
因為佈局中包括繼承自parent的規則，上下文樹做了緩存（color特征是繼續來的，但Firefox將其視為reset並在法則樹中緩存）。
這申明，一個法則鸠合具有一個或是可選個數的多個選擇器，這些選擇器以逗號和空格（S表示空格）進行分隔。每一個劃定規矩集合包括大括弧及大括弧中的一條或多條以分號離隔的聲明。聲明和選擇器在後面進行界說。
符號辨認器識別出符號後，將其傳遞給樹構建器，並讀取下一個字元，以辨認下一個符號，如許直到處理完所有輸入。
創建樹的流程（The flow of constructing the tree）
layout也能夠是增量的，如許只有標誌為dirty的轉譯物件會從新佈局（也將致使一些額外的結構）。增量layout會在轉譯物件dirty時非同步觸發，例如，當網路領受到新的內容並添加到Dom樹後，新的轉譯物件會添加到轉譯樹中翻譯
樣式上下文包括終究值，這些值是經由過程以准確挨次運用所有匹配的劃定規矩，並將它們由邏輯值轉換為具體的值，例如，若是邏輯值為螢幕的百分比，則經由過程較量爭論將其轉化為絕對單位翻譯樣式樹的使用確切很奇妙，它使得在節點中共用的這些值不需要被屢次較量爭論，同時也節流了存儲空間。
現在，轉到“in head”模式，然後是“after head”。到這裏，body符號會被再次處置，將建立一個HTMLBodyElement並插入到樹中，同時，轉移到“in body”模式。
5、結構（Layout）
Webkit中，計較樣式並生成轉譯物件的進程稱為attachment，每一個Dom節點有一個attach方法，attachment的進程是同步的，挪用新節點的attach方法將節點插入到Dom樹中。
迷路的表格
天成翻譯公司們起首找到p元素對應的劃定規矩，class對應將包含一個“error”的key，找到p.error的法則，div在id對應和標籤對應中都有相幹的規則，剩下的工作就是找出這些由key對應的法則中哪些確切是准確匹配的。
預解析（Speculative parsing）
瀏覽器的首要組件包孕：
又一次不言自明。
領受到body結束符號時，轉移到“after body”模式，接著接收到網頁設計結束符號，這個符號意味著轉移到了“after after body”模式，當領受到檔結束符時，全部解析進程竣事。
首先是“initial mode”，接收到網頁設計符號後將轉換為“before 網頁設計”模式，在這個模式中對這個符號進行再處理。此時，創建了一個HTMLHtmlElement元素，並將其附加到根Document對象上。
轉譯主流程（The main flow）
解析（Parsing－general）
解析器類型（Types of parsers）
例如，下面這個複雜選擇符
不幸的是，所有的傳統解析體例都不合用於網頁設計（當然天成翻譯公司提出它們並不只是因為好玩，它們將用來解析css和js），網頁設計不能簡單的用解析所需的上下文無關文法來界說翻譯
而今來看一下樹若何保存翻譯
後面兩個很輕易匹配到元素，因為它們所擁有的樣式屬性和網頁設計屬性可以將元素作為key進行對應。
Webkit中，並沒有法則樹，匹配的聲明會被遍曆四次，先是利用非important的高優先挨次屬性（之所以先應用這些屬性，是因為其他的依靠 於它們－比如display），其次是高優先按次important的，接著是一般優先順序非important的，最後是一般優先按次 important的法則。如許，出現多次的屬性將被依照正確的級聯順序進行處置，最後一個生效。
以准確的級聯順序應用規則
根轉譯物件的位置是0翻譯社0，它的巨細是viewport－瀏覽器視窗的可見部份。
需要注意的是，不同於大部分瀏覽器，Chrome為每一個Tab分配了各自的轉譯引擎實例，每一個Tab就是一個自力的曆程。
1. 一個全局的樣式改變影響所有的轉譯物件，比如字型巨細的改變。
2. 窗口resize。
這些年來，瀏覽器廠商紛纭開辟本身的擴大，對規範的遵循其實不完美，這為web開發者帶來了嚴重的相容性問題。
一個塊轉譯物件的堆疊順序是：
1. 靠山色
2. 佈景圖
3. border
4. children
5. outline
將討論的瀏覽器
繪製階段，遍曆轉譯樹並挪用轉譯物件的paint方式將它們的內容顯示在螢幕上，繪製利用UI根本元件，這在UI的章節有更多的介紹。
Block box：構成一個塊，即在瀏覽器視窗上有本身的矩形
block一個挨著一個垂直格式化，inline則在水準標的目的上格局化。
1. normal －物件按照它在文檔的中位置定位，這意味著它在轉譯樹和在Dom樹中位置一致，並根據它的盒模型和大小進行佈局。
2. float －物件先像通俗流一樣結構，然後盡量的向左或是向右移動。
3. absolute －物件在轉譯樹中的位置和Dom樹中位置無關。
注意－fixed即便在文檔流轉動時也不會移動翻譯
本篇文章引用自此: http://blog.youthwant.com.tw/piece2ec/piece2/299/有關各國語文翻譯公證的問題歡迎諮詢天成翻譯公司02-77260931
留言列表
