整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
lt;title> - 定義了HTML文檔的標題
使用 <title> 標簽定義HTML文檔的標題
<base> - 定義了所有鏈接的URL
使用 <base> 定義頁面中所有鏈接默認的鏈接目標地址。
<meta> - 提供了HTML文檔的meta標記
使用 <meta> 元素來描述HTML文檔的描述，關鍵詞，作者，字符集等。
HTML <head> 元素
<head> 元素包含了所有的頭部標簽元素。在 <head>元素中你可以插入腳本（scripts）, 樣式文件（CSS），及各種meta信息。
可以添加在頭部區域的元素標簽為: <title>, <style>, <meta>, <link>, <script>, <noscript>, and <base>.
HTML <title> 元素
<title> 標簽定義了不同文檔的標題。
<title> 在 HTML/XHTML 文檔中是必須的。
<title> 元素:
定義了瀏覽器工具欄的標題
當網頁添加到收藏夾時，顯示在收藏夾中的標題
顯示在搜索引擎結果頁面的標題
一個簡單的 HTML 文檔:
<!DOCTYPE html><html><head> <meta charset="utf-8"> <title>文檔標題</title></head><body>文檔內容......</body></html>
HTML <base> 元素
<base> 標簽描述了基本的鏈接地址/鏈接目標，該標簽作為HTML文檔中所有的鏈接標簽的默認鏈接:
<head>
<base target="_blank">
</head>
HTML <link> 元素
<link> 標簽定義了文檔與外部資源之間的關系。
<link> 標簽通常用于鏈接到樣式表:
<head>
<link rel="stylesheet" type="text/css" href="mystyle.css">
</head>
HTML <style> 元素
<style> 標簽定義了HTML文檔的樣式文件引用地址.
在<style> 元素中你需要指定樣式文件來渲染HTML文檔:
<head>
<style type="text/css">
body {background-color:yellow}
p {color:blue}
</style>
</head>
HTML <meta> 元素
meta標簽描述了一些基本的元數據。
<meta> 標簽提供了元數據.元數據也不顯示在頁面上，但會被瀏覽器解析。
META元素通常用于指定網頁的描述，關鍵詞，文件的最后修改時間，作者，和其他元數據。
元數據可以使用于瀏覽器（如何顯示內容或重新加載頁面），搜索引擎（關鍵詞），或其他Web服務。
<meta>一般放置于 <head>區域
<meta> 標簽- 使用實例
為搜索引擎定義關鍵詞:
<meta name="keywords" content="HTML, CSS, XML, XHTML, JavaScript">
為網頁定義描述內容:
<meta name="description" content="Free Web tutorials on HTML and CSS">
定義網頁作者:
<meta name="author" content="Hege Refsnes">
每30秒中刷新當前頁面:
<meta http-equiv="refresh" content="30">
HTML <script> 元素
<script>標簽用于加載腳本文件，如： JavaScript。
<script> 元素在以下章節會詳細描述。
HTML head 元素
| 標簽 | 描述 |
|---|---|
| <head> | 定義了文檔的信息 |
| <title> | 定義了文檔的標題 |
| <base> | 定義了頁面鏈接標簽的默認鏈接地址 |
| <link> | 定義了一個文檔和外部資源之間的關系 |
| <meta> | 定義了HTML文檔中的元數據 |
| <script> | 定義了客戶端的腳本文件 |
| <style> | 定義了HTML文檔的樣式文件 |
如您還有不明白的可以在下面與我留言或是與我探討QQ群308855039，我們一起飛！
當下瀏覽器內核主要有 Webkit、Blink 等。本文分析注意是自 2001 年 Webkit 從 KHTML 分離出去并開源后，各大瀏覽器廠商魔改 Webkit 的時期，這些魔改的內核最終以 Chromium 受眾最多而脫穎而出。本文就以 Chromium 瀏覽器架構為基礎，逐層探入進行剖析。
這里以一個面試中最常見的題目從 URL 輸入到瀏覽器渲染頁面發生了什么？開始。
這個很常見的題目，涉及的知識非常廣泛。大家可先從瀏覽器監聽用戶輸入開始，瀏覽器解析 url 的部分，分析出應用層協議 是 HTTPS 還是 HTTP 來決定是否經過會話層 TLS 套接字，然后到 DNS 解析獲取 IP，建立 TCP 套接字池 以及 TCP 三次握手，數據封裝切片的過程，瀏覽器發送請求獲取對應數據，如何解析 HTML，四次揮手等等等等。 這個回答理論上可以非常詳細，遠比我提到的多得多。
本文試圖從瀏覽器獲取資源開始探究 Webkit。如瀏覽器如何獲取資源，獲取資源時 Webkit 調用了哪些資源加載器（不同的資源使用不同的加載器），Webkit 如何解析 HTML 等入手。想要從前端工程師的角度弄明白這些問題，可以先暫時拋開 C++源碼，從瀏覽器架構出發，做到大致了解。之后學有余力的同學再去深入研究各個底層細節。
本文的路線循序漸進，從 Chromium 瀏覽器架構出發，到 Webkit 資源下載時對應的瀏覽器獲取對應資源如 HTML、CSS 等，再到 HTML 的解析，再到 JS 阻塞 DOM 解析而產生的 Webkit 優化 引出瀏覽器多線程架構，繼而出于安全性和穩定性的考慮引出瀏覽器多進程架構。
Chromium瀏覽器架構
（Chromium 瀏覽器架構）
我們通常說的瀏覽器內核，指的是渲染引擎。
WebCore 基本是共享的，只是在不同瀏覽器中使用 Webkit 的實現方式不同。它包含解析 HTML 生成 DOM、解析 CSS、渲染布局、資源加載器等等，用于加載和渲染網頁。
JS 解析可以使用 JSCore 或 V8 等 JS 引擎。我們熟悉的谷歌瀏覽器就是使用 V8。比如比較常見的有內置屬性 [[scope]] 就僅在 V8 內部使用，用于對象根據其向上索引自身不存在的屬性。而對外暴露的 API，如 __proto__ 也可用于更改原型鏈。實際上 __proto__ 并不是 ES 標準提供的，它是瀏覽器提供的（瀏覽器可以不提供，因此如果有瀏覽器不提供的話這也并不是 b ug）。
Webkit Ports 是不共享的部分。它包含視頻、音頻、圖片解碼、硬件加速、網絡棧等等，常用于移植。
同時，瀏覽器是多進程多線程架構，稍后也會細入。
在解析 HTML 文檔之前，需要先獲取資源，那么資源的獲取在 Webkit 中應該如何進行呢？
HTTP 是超文本傳輸協議，超文本的含義即包含了文本、圖片、視頻、音頻等等。其對應的不同文件格式，在 Webkit 中 需要調用不同的資源加載器，即 特定資源加載器。
而瀏覽器有四級緩存，Disk Cache 是我們最常說的通過 HTTP Header 去控制的，比如強緩存、協商緩存。同時也有瀏覽器自帶的啟發式緩存。而 Webkit 對應使用的加載器是資源緩存機制的資源加載器 CachedResoureLoader 類。
如果每個資源加載器都實現自己的加載方法，則浪費內存空間，同時違背了單一職責的原則，因此可以抽象出一個共享類，即通用資源加載器 ResoureLoader 類。 Webkit 資源加載是使用了三類加載器：「特定資源加載器，資源緩存機制的資源加載器 CachedResoureLoader 和 通用資源加載器 ResoureLoader」。
既然說到了緩存，那不妨多談一點。
資源既然緩存了，那是如何命中的呢？答案是根據資源唯一性的特征 URL。資源存儲是有一定有效期的，而這個有效期在 Webkit 中采用的就是 LRU 算法。那什么時候更新緩存呢？答案是不同的緩存類型對應不同的緩存策略。我們知道緩存多數是利用 HTTP 協議減少網絡負載的，即強緩存、協商緩存。但是如果關閉緩存了呢？ 比如 HTTP/1.0 Pragma:no-cache 和 HTTP/1.1 Cache-Control: no-cache。此時，對于 Webkit 來說，它會清空全局唯一的對象 MemoryCache 中的所有資源。
資源加載器內容先到這里。瀏覽器架構是多進程多線程的，其實多線程可以直接體現在資源加載的過程中，在 JS 阻塞 DOM 解析中發揮作用，下面我們詳細講解一下。
瀏覽器是多進程多線程架構。
對于瀏覽器來講，從網絡獲取資源是非常耗時的。從資源是否阻塞渲染的角度，對瀏覽器而言資源僅分為兩類：「阻塞渲染」如 JS 和 「不阻塞渲染」如圖片。
我們都知道 JS 阻塞 DOM 解析，反之亦然。然而對于阻塞，Webkit 不會傻傻等著浪費時間，它在內部做了優化：啟動另一個線程，去遍歷后續的 HTML 文檔，收集需要的資源 URL，并發下載資源。最常見的比如<script async>和<script defer>，其 JS 資源下載和 DOM 解析是并行的，JS 下載并不會阻塞 DOM 解析。這就是瀏覽器的多線程架構。
JS async defer
總結一下，多線程的好處就是，高響應度，UI 線程不會被耗時操作阻塞而完全阻塞瀏覽器進程。
關于多線程，有 GUI 渲染線程，負責解析 HTML、CSS、渲染和布局等等，調用 WebCore 的功能。JS 引擎線程，負責解析 JS 腳本，調用 JSCore 或 V8。我們都知道 JS 阻塞 DOM 解析，這是因為 Webkit 設計上 GUI 渲染線程和 JS 引擎線程的執行是互斥的。如果二者不互斥，假設 JS 引擎線程清空了 DOM 樹，在 JS 引擎線程清空的過程中 GUI 渲染線程仍繼續渲染頁面，這就造成了資源的浪費。更嚴重的，還可能發生各種多線程問題，比如臟數據等。
另外我們常說的 JS 操作 DOM 消耗性能，其實有一部分指的就是 JS 引擎線程和 GUI 渲染線程之間的通信，線程之間比較消耗性能。
除此之外還有別的線程，比如事件觸發線程，負責當一個事件被觸發時將其添加到待處理隊列的隊尾。
值得注意的是，多啟動的線程，僅僅是收集后續資源的 URL，線程并不會去下載資源。該線程會把下載的資源 URL 送給 Browser 進程，Browser 進程調用網絡棧去下載對應的資源，返回資源交由 Renderer 進程進行渲染，Renderer 進程將最終的渲染結果返回 Browser 進程，由 Browser 進程進行最終呈現。這就是瀏覽器的多進程架構。
多進程加載資源的過程是如何的呢？我們上面說到的 HTML 文檔在瀏覽器的渲染，是交由 Renderer 進程的。Renderer 進程在解析 HTML 的過程中，已搜集到所有的資源 URL，如 link CSS、Img src 等等。但出于安全性和效率的角度考慮，Renderer 進程并不能直接下載資源，它需要通過進程間通信將 URL 交由 Browser 進程，Browser 進程有權限調用 URLRequest 類從網絡或本地獲取資源。
?
近年來，對于有的瀏覽器，網絡棧由 Browser 進程中的一個模塊，變成一個單獨的進程。
?
同時，多進程的好處遠遠不止安全這一項，即沙箱模型。還有單個網頁或者第三方插件的崩潰，并不會影響到瀏覽器的穩定性。資源加載完成，對于 Webkit 而言，它需要調用 WebCore 對資源進行解析。那么我們先看下 HTML 的解析。之后我們再談一下，對于瀏覽器來說，它擁有哪些進程呢？
對于 Webkit 而言，將解析半結構化的 HTML 生成 DOM，但是對于 CSS 樣式表的解析，嚴格意義 CSSOM 并不是樹，而是一個映射表集合。我們可以通過 document.styleSheets 來獲取樣式表的有序集合來操作 CSSOM。對于 CSS，Webkit 也有對應的優化策略---ComputedStyle。ComputedStyle 就是如果多個元素的樣式可以不經過計算就確認相等，那么就僅會進行一次樣式計算，其余元素僅共享該 ComputedStyle。
共享 ComputedStyle 原則：
(1) TagName 和 Class 屬性必須一樣。
(2)不能有 Style。
(3)不能有 sibling selector。
(4)mappedAttribute 必須相等。
對于 DOM 和 CSSOM，大家說的合成的 render 樹在 Webkit 而言是不存在的，在 Webkit 內部生成的是 RenderObject，在它的節點在創建的同時，會根據層次結構創建 RenderLayer 樹，同時構建一個虛擬的繪圖上下文，生成可視化圖像。這四個內部表示結構會一直存在，直到網頁被銷毀。
RenderLayer 在瀏覽器控制臺中 Layers 功能卡中可以看到當前網頁的圖層分層。圖層涉及到顯式和隱式，如 scale()、z-index 等。層的優點之一是只重繪當前層而不影響其他層，這也是 Webkit 做的優化之一。同時 V8 引擎也做了一些優化，比如說隱藏類、優化回退、內聯緩存等等。
瀏覽器進程包括 「Browser 進程、Renderer 進程、GPU 進程、NPAPI 插件進程、Pepper 進程」等等。下面讓我們詳細看看各大進程。
?
注意：如果頁面有 iframe，它會形成影子節點，會運行在單獨的進程中。
?
我們僅僅在圍繞 Chromium 瀏覽器來說上述進程，因為在移動端，畢竟手機廠商很多，各大廠商對瀏覽器進程的支持也不一樣。這其實也是我們最常見的 H5 兼容性問題，比如 IOS margin-bottom 失效等等。再比如 H5 使用 video 標簽做直播，也在不同手機之間會存在問題。有的手機直播頁面跳出主進程再回來，就會黑屏。
以 Chromium 的 Android 版為例子，不存在 GPU 進程，GPU 進程變成了 Browser 進程的線程。同時，Renderer 進程演變為服務進程，同時被限制了最大數量。
為了方便起見，我們以 PC 端谷歌瀏覽器為例子，打開任務管理器，查看當前瀏覽器中打開的網頁及其進程。
打開瀏覽器任務管理器
當前我打開了 14 個網頁，不太好容易觀察，但可以從下圖中看到，只有一個 Browser 進程，即第 1 行。但是打開的網頁對應的 Renderer 進程，并不一定是一個網頁對應一個 Renderer 進程，這跟 Renderer 進程配置有關系。比如你看第 6、7 行是每個標簽頁創建獨立 Renderer 進程，但是藍色光標所在的第 8、9、10 行是共用一個 Renderer 進程，這屬于為每個頁面創建一個 Renderer 進程。因為第 9、10 行打開的頁面是從第 8 行點擊鏈接打開的。第 2 行的 GPU 進程也清晰可見，以及第 3、4、5 行的插件進程。
瀏覽器進程
關于，Renderer 進程和打開的網頁并不一定是一一對應的關系，下面我們詳細說一下 Renderer 進程。當前只有四種多進程策略：
Single process 突然讓我聯想到零幾年的時候，那會 IE 應該還是單進程瀏覽器。單進程就是指所有的功能模塊全部運行在一個進程，就類似于 Single process。那會玩 4399 如果一個網頁卡死了，沒響應，點關閉等一會，整個瀏覽器就崩潰了，得重新打開。所以多進程架構是有利于瀏覽器的穩定性的。雖然當下瀏覽器架構為多進程架構，但如果 Renderer 進程配置為 Process-per-site-instance，也可能會出現由于單個頁面卡死而導致所有頁面崩潰的情況。
故瀏覽器多進程架構綜上所述，好處有三：
(1)單個網頁的崩潰不會影響這個瀏覽器的穩定性。
(2)第三方插件的崩潰不會影響瀏覽器的穩定性。
(3)沙箱模型提供了安全保障。
Webkit 使用三類資源加載器去下載對應的資源，并存入緩存池中，對于 HTML 文檔的解析，在阻塞時調用另一個線程去收集后續資源的 URL，將其發送給 Browser 進程，Browser 進程調用網絡棧去下載對應的本地或網絡資源，返回給 Renderer 進程進行渲染，Renderer 進程將最終渲染結果(一系列的合成幀)發送給 Browser 進程，Browser 進程將這些合成幀發送給 GPU 從而顯示在屏幕上。 (文中有部分不嚴謹的地方，已由 lucifer 指出修改)
大家也可以關注我的公眾號《腦洞前端》獲取更多更新鮮的前端硬核文章，帶你認識你不知道的前端。
目前，在兩大主流移動智能操作系統iOS和Android上，默認的瀏覽器內核都是WebKit，而且分別以Framework的方式推出了UIWebKit和WebView組件，使得第三方開發者可以據此構建自己的瀏覽器或使用Web技術展現內容的各種復雜應用。
近日，Safari 15.4為WebKit添加了70多個新增功能，其中包含新的Web技術、更新和修復，這也是在2022年推出的第一個大型WebKit版本。Safari 15.4目前適用于macOS Monterey 12.3、iPadOS和iOS 15.4。具體新增特性如下：
WebKit通過<img>元素的加載（loading）屬性添加了對延遲加載圖像的支持，為Web開發人員提供了一種簡單的方法來指示瀏覽器延遲加載的某些圖像。
經過多年關于可訪問性標準化的辯論，如今終于有了解決方案，WebKit增加了對<dialog>元素和：：Background偽元素的支持。<dialog>元素提供了一種強大的方法來創建覆蓋和模態。
WebKit還增加了對全局自動聚焦屬性的支持，允許開發人員在頁面加載或顯示<對話框>時指示哪個元素應該是焦點。
2022年CSS的新增功能為Web開發人員構建代碼提供了革命性的新方法，使代碼重用、創建設計系統以及與復雜應用程序集成變得更加容易。 首先，登陸Safari，WebKit添加了對:has()偽類的支持。這個選擇器滿足了人們長期以來對“父選擇器”的渴望（這是一種基于元素內容有條件地應用CSS規則的方法）。長期以來，人們一直認為采用這樣的選擇器是不可能的，但WebKit團隊找到了一種高度優化性能的方法，并提供了一種不會降低頁面速度的靈活解決方案。 WebKit增加了對級聯層（Cascade Layers）的支持，這是一種將樣式組織到層中的強大方法，可以在每個層內獨立計算特異性。
Web開發人員可以創建一個“框架”層和一個“自定義”層——將所有CSS從第三方框架分配到“框架”層，并在“自定義”層中編寫自己的代碼。他們可以指定自定義層中的所有內容都應該優于框架層中的所有內容，無論每個層中使用的選擇器的特殊性如何。級聯層幾乎同時出現在所有主要瀏覽器中，并包含在Interop 2022中，這讓它成為未來Web開發人員會重視的工具。
WebKit還通過contains屬性添加了對CSS Containment的支持——所有四種類型：大小、布局、樣式和繪制。
Web開發人員非常需要一種類似于現有視口單元，但能在移動設備上工作得更好的工具，因為在移動設備上，隨著用戶滑動頁面，瀏覽器視口的尺寸會發生變化。
新的視口單元就是這種解決方案。100svh是指可能的最小視口高度的100%，100lvh是指最大可能視口高度的100%。100dvh指的是動態視口高度的100%——這意味著該值將隨著用戶滑動移動設備的屏幕而改變。
還有其他新的視口單元——svw、lvw和dvw在寬度方面也有相同的用途。為了涵蓋vmin和vmax的小型、大型和動態版本，svmin、svmax、lvmin、lvmax、dvmin和dvmax單元也要實現。為了支持邏輯維度，新的vi和vb在視口內聯維度和視口塊維度上與現有視口單元類似。svi、svb、lvi、lvb、dvi和dvb為小型、大型和動態版本的內聯維度和塊維度提供邏輯維度單元。
WebKit增加了對：focus visible偽類的支持，以僅在瀏覽器呈現焦點指示器時設置其樣式。
為了使原生表單控件更具可定制性，accent-color屬性為Web開發人員提供了一種更改表單控件用戶屬性（UI）特定部分顏色的方法。在macOS、iPadOS和iOS上，<input type="checkbox">、<input type="radio">、<progress>、<select>和帶有<datalist>的文本輸入類型支持強調色。此外，在iPadOS和iOS上，<input type="range">、<button>和<input type="button">支持強調色。
WebKit修復了具有alpha透明度的顏色之間插值的錯誤，改進了漸變支持。
此外，WebKit還添加了對calc()數學函數的支持，包括sin、cos、tan、e、pi、exp、log、atan、acos、asin和atan2。
Safari15.4中增添的幾個新WebKit功能豐富了Web排版的可能性。
WebKit添加了對字體調色板CSS屬性和@font-palette-values規則的支持。
font-palette屬性為Web開發人員提供了一種方法，可以選擇包含在彩色字體中的幾個不同的預定義調色板中的一個。例如，聲明字體的深色調色板用于網站的深色模式設計。@font-palette-values規則為Web開發人員提供了一種定義自己的自定義調色板的方法，用于重新設置彩色字體的顏色。
用于放大的大寫字母的顏色字體是Bradley Initials DJR Web，此處顯示的是其默認調色板、由Web開發人員創建的自定義調色板、包含在字體中的替代調色板，并且根據用戶的喜好移除了一些顏色。
WebKit添加了對text-decoration-skip-ink的支持，以控制下劃線和上劃線在通過字形上升和下降時呈現的形式。WebKit之前通過text-decoration-skip支持這一排版功能，但由于尚無其他瀏覽器支持short-hand，WebKit對long-hand的支持將更容易取消下劃線和上劃線。
此外，WebKit添加了對ic單元的支持，在排版CJK腳本時很有用。
為了減少對前綴的依賴，WebKit新支持了幾個CSS屬性和值，這些屬性和值僅在早期形式中可用。帶前綴的版本仍然有效，現在別名為無前綴的版本。Safari15.4添加了對以下內容的支持：
外觀，包括自動呈現
WebKit還刪除了非標準CSS屬性：-WebKit邊框擬合、-WebKit頁邊距折疊、-WebKit頁邊距頂部折疊、-WebKit頁邊距底部折疊、-WebKit折疊前頁邊距、-WebKit折疊后頁邊距以及-WebKit背景合成。
Web API是Web的應用程序編程接口，它可以擴展瀏覽器的功能，簡化復雜的功能，為復雜的代碼提供簡單的語法。所有瀏覽器都有一組內置的 Web API 來支持復雜的操作，并幫助訪問數據。
Safari 15.4包括對WebKit中Web API的許多升級，以幫助Web開發人員提供更好的用戶體驗。
對BroadcastChannel的支持允許來自源的選項卡、窗口、iframe和Worker相互發送消息。這可以實現跨多個選項卡同步站點的登錄狀態等體驗。
WebKit支持的另一個新機制是Web Locks API，它可以從選項卡、窗口、iFrame和Worker中的源節點作為異步鎖定控件來管理對資源的訪問。
開發人員還可以使用CSS滾動行為屬性或JavaScript中window.scroll()、window.scrollTo()和window.scrollBy()方法中的行為選項來控制元素的滾動行為。
這種新的支持使開發人員能夠在立即跳轉到視口中的某個位置或平滑地為滾動操作設置動畫之間進行選擇。
ResizeObserver API更新了對ResizeObserverEntry使用的ResizeObserverSize接口的支持，以幫助開發人員觀察元素的元素框大小屬性的變化。
StructuredClone(value)的添加提供了一個實用程序，該實用程序使用結構化克隆算法同步執行深度復制，以克隆和傳輸輸入值中的對象。
WebKit對文件系統訪問API和Origin Private File System的支持首先在Safari15.2中發布。Safari15.4在FileSystemFileHandle中引入了getFile()方法，可以更方便地從文件系統中讀取文件。此外，WebKit更新了WriteableStream以使用文件系統訪問API。
此次，JavaScript的新功能和更新為開發人員帶來了更多便利。其方便的新數組功能使得使用findLast()和findLastIndex()方法從數組末尾開始搜索變得更好。這些方法可幫助開發人員避免需要首先使用reverse()來改變數組的典型方法。
另外，JavaScript還支持at()方法訪問指定整數索引處的條目，特別是支持使用負整數從數組末尾開始。
let list = ['banana','cherry','orange','apple','kiwi'];
// Instead of this:
console.log(list[list.length-2]);
// It's as easy as:
console.log(list.at(-2));
新的語言工具對象Object.hasOwn()簡化了檢測對象何時具有屬性本身，即未繼承或不存在的屬性。
隨著標準流程定義了更多的國際化特性，WebKit繼續定期更新其Intl實現。最新版本包括使用Intl Enumeration API識別本地時區、排序規則、日歷、編號系統和貨幣的支持值。
更新到V2的Intl.Locale公開了新信息，其中包括日歷周數據（例如一周的第一天）、文本信息（例如書寫方向）以及其他區域相關的默認值（例如日歷、12小時或24小時周期），以及編號系統。
WebKit還將Intl.DisplayNames更新到V2，添加了對日歷和dateTimeField名稱以及語言顯示選項的支持。
添加到Intl.PluralRules的selectRange()方法為范圍（例如0-1項）提供了區域設置正確的復數形式。Intl.NumberFormat V3更新添加了formatRange()和formatRangetoParts()方法，用于使用區域設置感知約定以及新的useGrouping、roundingPriority、roundingIncrement、trailingZeroDisplay和signDisplay選項來格式化數字范圍。
最后，Intl.DateTimeFormat包括對四個新的時區名稱選項的支持：shortOffset、longOffset、shortGeneric和longGeneric。
對Web App Manifest和ServiceWorker的更新，改進了Safari中網站的用戶體驗，以及iOS和iPadOS上主屏幕上保存的Web應用程序。 Web App Manifest改進包括確保瀏覽器始終在頁面加載期間獲取清單文件，而不是在用戶從“共享”菜單中選擇“添加到主屏幕”。這種方法提高了可靠性，并且還允許清單文件定義Safari中網頁的特征。 此外，現在支持在Web應用清單文件中聲明圖標。當HTML頭部中沒有定義apple-touch-icon，并且用于聲明圖標的清單文件代碼省略“目的”鍵或包含“目的”時，Safari和iOS使用清單聲明的圖標。使用apple-touch-icon定義圖標優先于manifest聲明的圖標，以便為使用此技術為iOS定義特定圖標的Web應用程序提供一致的行為，這與其他移動平臺不同。 開發人員現在可以在ServiceWorker中啟用導航預加載，以提高加載性能，并避免阻塞網絡請求的ServiceWorker啟動延遲。還有新的支持允許用戶下載由ServiceWorker生成的文件。WebKit還提高了使用FormData和通過ServiceWorker的文件使用FormData文件的可靠性。
WebRTC協商API現在完全符合WebRTC 1.0規范，以支持WebRTC完美協商。這是一種解決在兩個遠程對等方在協商期間可能發生的潛在同步問題的方法。
WebKit添加了對音頻和視頻的帶內章節軌道的支持。帶內文本軌道在容器內為媒體本身提供字幕或章節標記信息，而不是在HTML中聲明或注入JavaScript。以前的版本，已經支持像CEA-608這樣的帶內字幕軌道。現在，帶內章節軌道也能獲得支持，其中“提示”代表章節的開始時間和標題。
WebKit在<video>上添加了對requestVideoFrameCallback()的支持，當有新的視頻幀可供顯示時，它允許調用者得到通知，并提供有關該幀的元數據。
Safari 15.4繼續致力于隱私保護，并進一步推動WebKit提出的以保護隱私的方式衡量廣告的網絡標準，它對隱私點擊衡量提供了三個更新：
添加了通過不可鏈接的令牌來預防轉化欺詐，以觸發商家網站上的事件。
Safari 15.4中的WebKit改進了對Level 3級別的內容安全策略的支持，增強了對內容加載的安全控制，并幫助Web開發人員降低跨站點腳本和其他漏洞的風險。已經更新內聯腳本、內聯樣式和eval執行的阻止資源沖突報告，以符合Web標準。
對“strict-dynamic”、“unsafe-hashes”和“report-sample”源表達式的新支持為開發人員提供了更大的靈活性。開發人員還可以使用對哈希源表達式的新支持，安全地在其頁面中包含外部JavaScript。
該版本還刪除了對XSS Auditor的支持，它已被CSP和COEP等現代跨域防御所取代。
使用WKWebView（包括iOS和iPadOS上的第三方瀏覽器）的開發人員可以利用新的WKPreferences進行額外的用戶體驗控制。iOS、iPadOS和macOS上的應用現在可以控制允許或阻止web內容使用全屏API。另一個新首選項允許啟用或禁用特定于站點的雜項，這是一組旨在提高Web兼容性的特定于站點的行為。 在iPadOS上，使用媒體源擴展的Web內容現在可以在WKWebView中使用。
在WebKit對擴展的跨瀏覽器互操作模型方面，Safari 15.4增加了對Web擴展的額外支持，包括對manifest_version3和相關API更改的支持。這些新功能包括：
并解決了幾個問題，其中包括：
Web Inspector的更新，為在樣式面板中處理CSS提供了有用的新工具，包括對級聯層和新的@layer規則集的直觀支持，從而可以輕松識別在哪個層中定義了規則。 當Flexbox和Grid使用align-content、align-items、align-self、justify-content、justify-items或justify-self時，還有新的CSS對齊控件可以直觀地識別和選擇理想值。 在樣式面板中添加新屬性或值時，Web Inspector提供了方便的自動完成選項。最新版本升級了自動完成，可以使用模糊匹配，從而更容易找到正確的選項。 當使用CSS自定義屬性或更廣為人知的CSS變量時，一種常見的做法是將它們添加到:root或html的選擇器規則中。不幸的是，這會導致頁面上的每個元素都有一長串繼承的CSS變量。Web Inspector可以通過多種方式幫助用戶處理此問題。首先，它會自動隱藏未使用的繼承CSS變量。然后，當需要查看它們時，可以使用一個按鈕將它們全部顯示出來。還可以使用過濾器工具來搜索正確的CSS變量，或者可以在計算面板中查看按值類型分組的所有適用CSS變量，從而允許折疊與其任務不相關的組。
眾所周知，WebKit是一個開源的瀏覽器排版引擎，其起源最早可追溯到始于1998年的KDE開源桌面環境項目的HTML Widget，后來進一步發展為KDE的標準組件、KHTML排版引擎和KJSJavaScript腳本引擎。
蘋果公司為開發自主的Safari瀏覽器，在對比了Gecko和KHTML之后，毅然選擇了后者。原因是相比Gecko的龐大臃腫，KHTML更加輕巧和清晰。蘋果公司將KHTML更名為WebCore，KJS更名為JavaScriptCore，兩者合起來作為WebKit。
2008年9月，谷歌公司推出了基于WebKit內核的Chrome瀏覽器，Chrome促成了瀏覽器技術的持續發展，WebKit也因此逐漸轉入更多開發者的視界，影響力和知名度與日俱增。
來源：51CTO技術棧
作者：武穆、李睿
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
