Web標準的簡單理解 不一樣內核瀏覽器的差別以及瀏覽器渲染簡介(轉)
Web標準是一系列標準的集合。這些標準大概分三方面：結構、表現和行爲。結構化主要有HTML, XHTML和XML,表現主要有CSS，行爲標準主要包括對象模型,如 W3C DOM、ECMAScript等。這些標準大部分是右W3C起草和發佈的。php
1、簡單介紹一下什麼是瀏覽器內核。
瀏覽器最重要或者說核心的部分是「Rendering Engine」，可大概譯爲「解釋引擎」，不過咱們通常習慣將之稱爲「瀏覽器內核」。負責對網頁語法的解釋（如HTML、JavaScript）並渲染（顯示）網頁。 因此，一般所謂的瀏覽器內核也就是瀏覽器所採用的渲染引擎，渲染引擎決定了瀏覽器如何顯示網頁的內容以及頁面的格式信息。不一樣的瀏覽器內核對網頁編寫語法的解釋也有不一樣，所以同一網頁在不一樣的內核的瀏覽器裏的渲染（顯示）效果也可能不一樣，這也是網頁編寫者須要在不一樣內核的瀏覽器中測試網頁顯示效果的緣由。css
改而來的，並沿用到目前的IE9。Trident其實是一款開放的內核，其接口內核設計的至關成熟，所以纔有許多
採用IE內核而非IE的瀏覽器涌現（如 Maxthon、The World 、TT、GreenBrowser、AvantBrowser等）。此外，
爲了方便也有不少人直接簡稱其爲IE內核（固然也不排除有部分人是由於不知道內核名稱而只好如此說）。因爲IE自己的「壟斷性」（雖然名義上IE並不是壟斷，但實際上，特別是從Windows 95年代一直到XP初期，就市場佔有率來講IE的確藉助Windows的東風處於「壟斷」的地位）而使得Trident內核的長期一家獨大，微軟很長時間都並無更新Trident內核，這致使了兩個後果——一是Trident內核曾經幾乎與W3C標準脫節（2005年），二是Trident內核的大量 Bug等安全性問題沒有獲得及時解決，而後加上一些致力於開源的開發者和一些學者們公開本身認爲IE瀏覽器不安全的觀點，也有不少用戶轉向了其餘瀏覽器，Firefox和Opera就是這個時候興起的。非Trident內核瀏覽器的市場佔有率大幅提升也導致許多網頁開發人員開始注意網頁標準和非IE瀏覽器的瀏覽效果問題。
是代碼徹底公開，所以，其可開發程度很高，全世界的程序員均可覺得其編寫代碼，增長功能。由於這是個開源
內核，所以受到許多人的青睞，Gecko內核的瀏覽器也不少，這也是Geckos內核雖然年輕但市場佔有率可以迅速
提升的重要緣由。 事實上，Gecko引擎的由來跟IE不無關係，前面說過IE沒有使用W3C的標準，這致使了微軟內部一些開發人員的不滿；他們與當時已經中止更新了的 Netscape的一些員工一塊兒創辦了Mozilla，以當時的Mosaic內核爲基礎
從新編寫內核，因而開發出了Geckos。不過事實上，Gecko 內核的瀏覽器仍然仍是Firefox (火狐) 用戶最多，
因此有時也會被稱爲Firefox內核。此外Gecko也是一個跨平臺內核，能夠在Windows、 BSD、Linux和Mac OS X
中使用。
實際上這是一個動態內核，與前面幾個內核的最大的區別就在腳本處理上，Presto有着天生的優點，頁面的所有或者部分都可以在迴應腳本事件時等狀況下被從新解析。
此外該內核在執行Javascrīpt的時候有着最快的速度，根據在同等條件下的測試，Presto內核執行同等Javascrīpt所需的時間僅有Trident和Gecko內核的約1/3（Trident內核最慢，不過二者相差沒有多大）。
那次測試的時候由於Apple機的硬件條件和普通PC機不一樣因此沒有測試WebCore內核。只惋惜Presto是商業引擎，使用Presto的除開Opera之外，只剩下NDSBrowser、Wii Internet Channle、Nokia 770網絡瀏覽器等，這很大程度上限制了Presto的發展。
因此Webkit也是自由軟件，同時開放源代碼。在安全方面不受IE、Firefox的制約，因此Safari瀏覽器在國內仍是很安全的。
限於Mac OS X的使用不普遍和Safari瀏覽器曾經只是Mac OS X的專屬瀏覽器，這個內核自己應該說市場範圍並不大；但彷佛根據最新的瀏覽器調查代表，該瀏覽器的市場甚至已經超過了Opera的Presto了——固然這一方面得益於蘋果轉到x86架構以後的人氣暴漲，另外也是由於Safari 3終於推出了Windows版的緣故吧。
Mac下還有OmniWeb、Shiira等人氣很高的瀏覽器。
google的chrome也使用webkit做爲內核。
WebKit 內核在手機上的應用也十分普遍，例如 Google 的手機 Gphone、 Apple 的 iPhone， Nokia’s Series 60 browser 等所使用的 Browser 內核引擎，都是基於 WebKit。
Web頁面運行在各類各樣的瀏覽器當中，瀏覽器載入、渲染頁面的速度直接影響着用戶體驗簡單地說，頁面渲染就是瀏覽器將html代碼根據CSS定義的規則顯示在瀏覽器窗口中的這個過程。先來大體瞭解一下瀏覽器都是怎麼幹活的：
1. 用戶輸入網址（假設是個html頁面，而且是第一次訪問），瀏覽器向服務器發出請求，服務器返回html文件；
2. 瀏覽器開始載入html代碼，發現<head>標籤內有一個<link>標籤引用外部CSS文件；
3. 瀏覽器又發出CSS文件的請求，服務器返回這個CSS文件；
4. 瀏覽器繼續載入html中<body>部分的代碼，而且CSS文件已經拿到手了，能夠開始渲染頁面了；
5. 瀏覽器在代碼中發現一個<img>標籤引用了一張圖片，向服務器發出請求。此時瀏覽器不會等到圖片下載完，而是繼續渲染後面的代碼；
6. 服務器返回圖片文件，因爲圖片佔用了必定面積，影響了後面段落的排布，所以瀏覽器須要回過頭來從新渲染這部分代碼；
7. 瀏覽器發現了一個包含一行Javascript代碼的<script>標籤，趕快運行它；
8. Javascript腳本執行了這條語句，它命令瀏覽器隱藏掉代碼中的某個html
9. 終於等到了</html>的到來，瀏覽器淚流滿面……
10. 等等，還沒完，用戶點了一下界面中的「換膚」按鈕，Javascript讓瀏覽器換了一下<link>標籤的CSS路徑；
11. 瀏覽器召集了在座的各位
求了新的CSS文件，從新渲染頁面。
瀏覽器天天就這麼來來回回跑着，要知道不一樣的人寫出來的html和css代碼質量良莠不齊，說不定哪天跑着跑着就掛掉了。好在這個世界還有這麼一羣人——頁面重構工程師，平時挺不起眼，也就幫視覺設計師們切切圖啊改改字，其實背地裏仍是幹了很多實事的。前端
說到頁面爲何會慢？那是由於瀏覽器要花時間、花精力去渲染，尤爲是當它發現某個部分發生了點變化影響了佈局，須要倒回去從新渲染，內行稱這個回退的過程叫reflow。程序員
reflow幾乎是沒法避免的。如今界面上流行的一些效果，好比樹狀目錄的摺疊、展開（實質上是元素的顯示與隱藏）等，都將引發瀏覽器的 reflow。鼠標滑過、點擊……只要這些行爲引發了頁面上某些元素的佔位面積、定位方式、邊距等屬性的變化，都會引發它內部、周圍甚至整個頁面的從新渲染。一般咱們都沒法預估瀏覽器到底會reflow哪一部分的代碼，它們都彼此相互影響着。web
reflow問題是能夠優化的，咱們能夠儘可能減小沒必要要的reflow。好比開頭的例子中的<img>圖片載入問題，這其實就是一個能夠避免的reflow——給圖片設置寬度和高度就能夠了。這樣瀏覽器就知道了圖片的佔位面積，在載入圖片前就預留好了位置。chrome
另外，有個和reflow看上去差很少的術語：repaint，中文叫重繪。 若是隻是改變某個元素的背景色、文字顏色、邊框顏色等等不影響它周圍或內部佈局的屬性，將只會引發瀏覽器repaint。repaint的速度明顯快於 reflow（在IE下須要換一下說法，reflow要比repaint 更緩慢）。後端
3、從瀏覽器的渲染原理講CSS性能(http://hi.baidu.com/zhoumm1008/blog/item/03fa88f97fe5ddebfd037f4b.html)瀏覽器
平時咱們幾乎天天都在和瀏覽器打交道，寫出來的頁面頗有可能在不一樣的瀏覽器下顯示的不同。苦逼的前端攻城師們爲了兼容各個瀏覽器而不斷地去測試和調試，還在腦子中記下各類遇到的BUG及解決方案，而咱們好像並無去主動地關注和了解下瀏覽器的工做原理。若是咱們對此作一點了解，我想在項目過程當中就能夠根據它有效的避免一些問題以及對頁面性能作出相應的改進。今天咱們主要根據瀏覽器的渲染原理對CSS的書寫性能作一點改進（固然還有JS本篇文章暫不考慮，後面的文章會作介紹），下面讓咱們一塊兒來揭開瀏覽器的渲染原理這一神祕的面紗吧：安全
最終決定瀏覽器表現出來的頁面效果的差別是：渲染引擎 Rendering Engine（也叫作排版引擎），也就是咱們一般所說的「瀏覽器內核」，負責解析網頁語法（如HTML、JavaScript）並渲染、展現網頁。相同的代碼在不一樣的瀏覽器呈現出來的效果不同，那麼就頗有多是不一樣的瀏覽器內核致使的。
咱們來看一下加載頁面時瀏覽器的具體工做流程（圖一）：
（圖一）
一、解析HTML以重建DOM樹（Parsing HTML to construct the DOM tree ）：渲染引擎開始解析HTML文檔，轉換樹中的標籤到DOM節點，它被稱爲「內容樹」。
二、構建渲染樹（Render tree construction）：解析CSS（包括外部CSS文件和樣式元素），根據CSS選擇器計算出節點的樣式，建立另外一個樹 —- 渲染樹。
三、佈局渲染樹（Layout of the render tree）: 從根節點遞歸調用，計算每個元素的大小、位置等，給每一個節點所應該出如今屏幕上的精確座標。
四、繪製渲染樹（Painting the render tree） : 遍歷渲染樹，每一個節點將使用UI後端層來繪製。
主要的流程就是：構建一個dom樹，頁面要顯示的各元素都會建立到這個dom樹當中，每當一個新元素加入到這個dom樹當中，瀏覽器便會經過css引擎查遍css樣式表，找到符合該元素的樣式規則應用到這個元素上。
注意了：css引擎查找樣式表，對每條規則都按從右到左的順序去匹配。 看以下規則：
| 1 | #nav li {} |
看起來很快，實際上很慢，儘管這讓人有點費解#_#。咱們中的大多數人，尤爲是那些從左到右閱讀的人，可能猜測瀏覽器也是執行從左到右匹配規則的，所以會推測這條規則的開銷並不高。在腦海中，咱們想象瀏覽器會像這樣工做：找到惟一的ID爲nav的元素，而後把這個樣式應用到直系子元素的li元素上。咱們知道有一個ID爲nav的元素，而且它只有幾個Li子元素，因此這個CSS選擇符應該至關高效。
事實上，CSS選擇符是從右到左進行匹配的。瞭解這方面的知識後，咱們知道這個以前看似高效地規則實際開銷至關高，瀏覽器必須遍歷頁面上每一個li元素並肯定其父元素的id是否爲nav。
| 1 | *{} |
額，這種方法我剛寫CSS的也寫過，卻不知這種效率是差到極點的作法，由於*通配符將匹配全部元素，因此瀏覽器必須去遍歷每個元素，這樣的計算次數多是上萬次！
| 1 | ul#nav{} ul.nav{} |
在頁面中一個指定的ID只能對應一個元素，因此沒有必要添加額外的限定符，並且這會使它更低效。同時也不要用具體的標籤限定類選擇符，而是要根據實際的狀況對類名進行擴展。例如把ul.nav改爲.main_nav更好。
| 1 | ul li li li .nav_item{} |
對於這樣的選擇器，以前也寫過，最後本身也數不過來有多少後代選擇器了，何不用一個類來關聯最後的標籤元素，如.extra_navitem，這樣只須要匹配class爲extra_navitem的元素，效率明顯提高了
對此，在CSS書寫過程當中，總結出以下性能提高的方案：
- 避免使用通配規則 如 *{} 計算次數驚人！只對須要用到的元素進行選擇
- 儘可能少的去對標籤進行選擇，而是用class 如：#nav li{},能夠爲li加上nav_item的類名，以下選擇.nav_item{}
- 不要去用標籤限定ID或者類選擇符 如：ul#nav,應該簡化爲#nav
- 儘可能少的去使用後代選擇器，下降選擇器的權重值 後代選擇器的開銷是最高的，儘可能將選擇器的深度降到最低，最高不要超過三層，更多的使用類來關聯每個標籤元素
- 考慮繼承 瞭解哪些屬性是能夠經過繼承而來的，而後避免對這些屬性重複指定規則
選用高效的選擇符，能夠減小頁面的渲染時間，從而有效的提高用戶體驗（頁面越快，用戶固然越喜歡^_^）,你能夠看一下CSS selectors Test，這個實驗的重點是評估複雜選擇符和簡單選擇符的開銷。也許當你想讓渲染速度最高效時，你可能會給每一個獨立的標籤配置一個ID，而後用這些ID寫樣式。那的確會超級快，也超級荒唐！這樣的結果是語義極差，後期的維護難到了極點。
但說到底，CSS性能這東西對於小的項目來說可能真的是微乎其微的東西，提高可能也不是很明顯，但對於大型的項目確定是有幫助的。並且一個好的CSS書寫習慣和方式可以幫助咱們更加嚴謹的要求本身。
- 1. 不一樣內核瀏覽器的差別以及瀏覽器渲染簡介
- 2. 不一樣內核瀏覽器的差別以及瀏覽器渲染(轉)
- 3. 不同內核瀏覽器的差異以及瀏覽器渲染簡介(轉)
- 4. 不同內核瀏覽器的差異以及瀏覽器渲染簡介
- 5. 【轉】不一樣內核瀏覽器的差別以及瀏覽器渲染簡介
- 6. 不一樣內核瀏覽器的差別以及瀏覽器渲染簡介(轉)
- 7. 瀏覽器的渲染原理簡介
- 8. 瀏覽器工做原理 （一） ： 瀏覽器渲染原理 & 瀏覽器內核
- 9. 瀏覽器渲染原理簡介
- 10. 瀏覽器內核及渲染流程
- 更多相關文章...
- • Opera 瀏覽器 - 瀏覽器信息
- • XSLT 瀏覽器 - XSLT 教程
- • Docker容器實戰(七) - 容器眼光下的文件系統
- • Docker容器實戰(六) - 容器的隔離與限制
-
每一个你不满意的现在，都有一个你没有努力的曾经。