• 放錯位置的 html 或者 body 結束標記

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

if (t->tagName == htmlTag || t->tagName == bodyTag )
        return;
複製程式碼

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

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*] ')' ]
  ;
複製程式碼

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

div.error , a.error {
  color:red;
  font-weight:bold;
}
複製程式碼

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

ruleset
  : selector [ ',' S* selector ]*
    '{' S* declaration [ ';' S* declaration ]* '}' S*
  ;
複製程式碼

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

WebKit CSS解析器

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

處理指令碼和樣式表的順序

指令碼

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

預解析

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

樣式表

另一方面，樣式表有著不同的模型。理論上來說，應用樣式表不會更改 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 方法。渲染器所指向的樣式物件中包含了一些和幾何無關的資訊。

渲染樹和dom樹的關係

渲染器是和 DOM 元素相對應的，但並非一一對應。非視覺化的 DOM 元素不會插入渲染樹中，例如“head”元素。如果元素的 display 屬性值為“none”，那麼也不會顯示在渲染樹中（但是 visibility 屬性值為“hidden”的元素仍會顯示）。

有一些 DOM 元素對應多個視覺化物件。它們往往是具有複雜結構的元素，無法用單一的矩形來描述。例如，“select”元素有 3 個渲染器：一個用於顯示區域，一個用於下拉列表框，還有一個用於按鈕。如果由於寬度不夠，文字無法在一行中顯示而分為多行，那麼新的行也會作為新的渲染器而新增。

另一個關於多渲染器的例子是格式無效的 HTML。根據 CSS 規範，inline 元素只能包含 block 元素或 inline 元素中的一種。如果出現了混合內容，則應建立匿名的 block 渲染器，以包裹 inline 元素。

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

構建渲染樹的流程

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

在 WebKit 中，解析樣式和建立渲染器的過程稱為“附加”。每個 DOM 節點都有一個“attach”方法。附加是同步進行的，將節點插入 DOM 樹需要呼叫新的節點“attach”方法。

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

樣式計算

構建渲染樹時，需要計算每一個渲染物件的視覺化屬性。這是通過計算每個元素的樣式屬性來完成的。

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

樣式表的來源包括瀏覽器的預設樣式表、由網頁作者提供的樣式表以及由瀏覽器使用者提供的使用者樣式表（瀏覽器允許您定義自己喜歡的樣式。以 Firefox 為例，使用者可以將自己喜歡的樣式表放在“Firefox Profile”資料夾下）。

樣式計算存在以下難點：

1. 樣式資料是一個超大的結構，儲存了無數的樣式屬性，這可能造成記憶體問題。
2. 如果不進行優化，為每一個元素查詢匹配的規則會造成效能問題。要為每一個元素遍歷整個規則列表來尋找匹配規則，這是一項浩大的工程。選擇器會具有很複雜的結構，這就會導致某個匹配過程一開始看起來很可能是正確的，但最終發現其實是徒勞的，必須嘗試其他匹配路徑。

例如下面這個組合選擇器：

    div div div div{
        ...
    }
複製程式碼

這意味著規則適用於作為 3 個 div 元素的子代的

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

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

共享樣式資料

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

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

Firefox規則樹

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

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

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

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

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

結構劃分

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

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

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

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

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

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

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

讓我們來看一個例子，假設我們有如下 HTML 程式碼：

    <html>
    <body>
        
            
  
           

              
              
            
            
相關推薦
			   
            
            
            
 

    

    
    
[譯]瀏覽器工作原理探究
     
 引言 
最近對web的效能優化比較感興趣，而前端程式碼主要在瀏覽器工作的。如果對瀏覽器的工作原理了解清楚，可以為web效能優化提供方向以及理論依據。 本文主要參考 How Browsers Work: Behind the scenes of modern web browsers 。在此基礎上整理而來的。個 

  
 

    

    
    
瀏覽器工作原理（二）：瀏覽器渲染過程概述
     
 sync   結構   dom   end   繪制   fault   異步加載   步驟   targe   參考：https://segmentfault.com/a/1190000012925872#articleHeader4
瀏覽器器內核拿到內容後，渲染大概可以劃分成以下幾個步驟：

解析html 

  
 

    

    
    
web效能優化-瀏覽器工作原理
     
 要徹底瞭解web效能優化的問題，得搞清楚瀏覽器的工作原理。 
我們需要了解，你在瀏覽器位址列中輸入url到頁面展示的短短几秒中，瀏覽器究竟做了什麼，才能瞭解到為什麼我們口中所說的優化方案能夠起到優化作用。 
瀏覽器的多程序架構（以下的例子都是以chrome為例） 
chrome由多個程序組成，每個程序都有自己 

  
 

    

    
    
JS進階 - 瀏覽器工作原理
     
 一、瀏覽器的結構 
瀏覽器的主要元件為： 
 
 使用者介面 - 包括位址列、前進/後退按鈕、書籤選單等。除了瀏覽器主視窗（顯示頁面），其他部分都屬於使用者介面。 
 瀏覽器引擎 - 在使用者介面和渲染引擎之間傳送指令。 
 渲染引擎 - 顯示（渲染）請求的內容。如果請求的內容是 HTML，它就負責 

  
 

    

    
    
瀏覽器工作原理2-域名解析
     
  
  
  
 當你在位址列輸入網址https://blog.csdn.net/並按下回車的時候，瀏覽器首先需要做的就是域名解析。 
 我們在瀏覽器位址列輸入的通常都是域名，域名其實就是IP地址的代稱。使用域名有兩個好處： 
  
  好記。 使用這一串帶有特殊含義的字元作為域名，而不需要記憶沒有含義的數字 

  
 

    

    
    
瀏覽器工作原理1-基本介紹
     
  
  
  
 基本介紹 
 瀏覽器工作原理也就是當你輸入一個網址到螢幕上看到這個網站的過程中發生了什麼事情，對於前端開發人員來說，這是必須瞭解的東西1。 
 在介紹瀏覽器工作原理之前，先了解下當前世面上目前主流瀏覽器包括Chrome、Firefox、UC、Safari 和 Opera。根據statcoun 

  
 

    

    
    
瀏覽器工作原理（五）：CSS解析（CSS parsing）
     
 
                
還記得簡介中提到的解析的概念嗎，不同於html，css屬於上下文無關文法，可以用前面所描述的解析器來解析。Css規範定義了css的詞法及語法文法。
看一些例子：
每個符號都由正則表示式定義了詞法文法（詞彙表）：

comment///*[^*]*/*+([^/*][^*]* 

  
 

    

    
    
深入理解瀏覽器工作原理
     
 前面的話
　　瀏覽器（browser application）是專門用來訪問和瀏覽全球資訊網頁面的客戶端軟體，也是現代計算機系統中應用最為廣泛的軟體之一，其重要性不言而喻。前端工程師作為負責程式頁面顯示的工程師，需要直接與瀏覽器打交道。本文將詳細介紹瀏覽器的工作原理

組成
　　瀏覽器的組成如下圖所示 

  
 

    

    
    
瀏覽器工作原理
     
 
							
							
							我們在瀏覽器輸入一個url，瀏覽器無法通過一個url訪問到伺服器，只能通過IP地址才能找到web伺服器，所以瀏覽器會通過域名獲取web伺服器的IP地址即DNS解析，然後通過解析出來的IP地址去訪問伺服器，然後兩者通過HTTP協議去通訊，其完整的流程如下圖所示：
 

  
 

    

    
    
瀏覽器工作原理詳解
     
 
                

這篇文章是以色列開發人員塔利·加希爾的研究成果。她在查閱了所有公開發布的關於瀏覽器內部機制的資料，並花了很多時間來研讀網路瀏覽器的原始碼。她寫道：


在 IE 佔據 90%市場份額的年代，我們除了把瀏覽器當成一個“黑箱”，什麼也做不了。但是現在，開放原始碼的瀏 

  
 

    

    
    
Spring MVC中DispatcherServlet工作原理探究
     
 
                
下面類圖將主要的類及方法抽離出來，以便檢視方便，根據類的結構來說明整個請求是如何工作的
主要使用到的技術有Spring的IOC容器和Servlet。


假如我們要實現一個請求home.htm然後返回home.jsp檢視資源則
當home.htm請求到達時，我們需要Disp 

  
 

    

    
    
瀏覽器工作原理（四）：HTML解析器 HTML Parser
     
 
                
HTML解析器的工作是將html標識解析為解析樹。

HTML文法定義（The HTML grammar definition）
W3C組織制定規範定義了HTML的詞彙表和語法。

非上下文無關文法（Not a context free grammar）
正如在解析簡介中提 

  
 

    

    
    
深入解析瀏覽器的幕後工作原理(三) 呈現樹和 DOM 樹的關系
     
 文本   一行   出現   src   格式   關於   放置   顯示   關系   
呈現樹和 DOM 樹的關系
　　呈現器是和 DOM 元素相對應的，但並非一一對應。非可視化的 DOM 元素不會插入呈現樹中，例如“head”元素。如果元素的 display 屬性值為“none”，那麽也不會顯示在呈現 

  
 

    

    
    
深入解析瀏覽器的幕後工作原理(二) 呈現引擎
     
 div   分享   image   ima   好的   clas   logs   指令   開放源代碼   
呈現引擎

　　本文所討論的瀏覽器（Firefox、Chrome 瀏覽器和 Safari）是基於兩種呈現引擎構建的。Firefox 使用的是 Gecko，這是 Mozilla 公司“自制”的呈現 

  
 

    

    
    
根據瀏覽器渲染引擎工作原理(reflow/repaint)，來優化DOM的操作
     
 工作原理   scroll   標簽   發現   較高的   所有   hid   問題   移動端   1.瀏覽器的渲染引擎工作原理：
  （1）解析HTML，生成DOM樹。解析HTML文檔，轉換樹中的html標簽或js生成的標簽到DOM節點，它被稱為 -- 內容樹。
  （2）構建渲染樹，解析Style 

  
 

    

    
    
【譯】JavaScript的工作原理：引擎，執行時和呼叫堆疊的概述
     
 原文地址：https://blog.sessionstack.com/how-does-javascript-actually-work-part-1-b0bacc073cf（需要翻牆）
隨著javascript變得越來越流行，很多團隊的技術棧都開始使用它，比如前端、後端、hybrid、嵌入式裝置等。
這篇文 

  
 

    

    
    
zuul原始碼分析-探究原生zuul的工作原理
     
 前提
最近在專案中使用了SpringCloud，基於zuul搭建了一個提供加解密、鑑權等功能的閘道器服務。鑑於之前沒怎麼使用過Zuul，於是順便仔細閱讀了它的原始碼。實際上，zuul原來提供的功能是很單一的：通過一個統一的Servlet入口(ZuulServlet)攔截所有的請求，然後通過內建的com.net 

  
 

    

    
    
【譯】JavaScript的工作原理：記憶體管理和4種常見的記憶體洩漏
     
 該系列的第一篇文章重點介紹了引擎，執行時和呼叫堆疊的概述。第二篇文章深入剖析了Google的V8 JavaScript引擎，並提供了關於如何編寫更好的JavaScript程式碼的一些提示。 
在第三篇文章中，我們將討論另一個越來越被開發人員忽視的關鍵主題，因為日常使用的程式語言（記憶體管理）越來越成熟和複雜。 

  
 

    

    
    
瀏覽器渲染原理及解剖瀏覽器內部工作原理
     
 
                

1、簡單地說，頁面渲染就是瀏覽器將html程式碼根據CSS定義的規則顯示在瀏覽器視窗中的這個過程。先來大致瞭解一下瀏覽器都是怎麼工作的：
　　1. 使用者輸入網址（假設是個html頁面，並且是第一次訪問），瀏覽器向伺服器發出請求，伺服器返回html檔案；
　　2. 

  
 

    

    
    
【譯】JavaScript的工作原理：事件迴圈及非同步程式設計的出現和 5 種更好的 async/await 程式設計方式
     
 此篇是JavaScript的工作原理的第四篇，其它三篇可以看這裡： 
 
 【譯】JavaScript的工作原理：引擎，執行時和呼叫堆疊的概述 
 【譯】JavaScript的工作原理：V8引擎內部+關於如何編寫優化程式碼的5個技巧 
 【譯】JavaScript的工作原理：記憶體管理和4種常見的記憶體洩漏