View Transition API 是網路開發領域的重大突破。無論您的網站是單頁或多頁，這項強大的 API 都能讓您在檢視畫面之間建立流暢的轉場效果，打造吸引使用者的原生體驗。目前可在 Chrome 中使用，不久後 Safari 也將提供相同的文件檢視轉場效果。
越來越多人開始研究 View Transition API，因此我們想澄清一些誤解。
誤解 1：View Transition API 會擷取螢幕截圖
執行檢視畫面轉場時，API 會擷取內容的舊狀態和新狀態快照。這些快照會轉為動畫，詳情請參閱說明文件的「這些轉場效果的運作方式」一節。
雖然您可以將舊快照稱為螢幕截圖，但新快照並非螢幕截圖，而是節點的即時呈現。您可以將其視為已取代的元素。
::view-transition
└─ ::view-transition-group(root)
└─ ::view-transition-image-pair(root)
├─ ::view-transition-old(root) 👈 Screenshot
└─ ::view-transition-new(root) 👈 Live representation
有了這個即時功能，這類示範才能運作：在檢視畫面轉換期間，系統會持續播放來自新快照的影片。
相關邏輯和 CSS 的詳細資訊請參閱說明文件。
迷思 2：擷取多個元素會導致多個檢視畫面轉場效果執行
擷取多個元素時，快照程序會擷取所有舊狀態和新狀態。除了 :root 元素，如果您擷取 .box，就會得到這個虛擬樹狀結構：
::view-transition
└─ ::view-transition-group(root)
| └─ ::view-transition-image-pair(root)
| ├─ ::view-transition-old(root)
| └─ ::view-transition-new(root)
└─ ::view-transition-group(box)
└─ ::view-transition-image-pair(box)
├─ ::view-transition-old(box)
└─ ::view-transition-new(box)
雖然這個樹狀結構包含多個快照組合，但只會執行單一檢視畫面轉場效果。
目前，Chrome 只能同時執行每個文件的一個檢視畫面轉場效果。請嘗試在這個示範中快速點按，啟動新的檢視畫面轉場效果。您會發現，當新的轉場動畫開始時，目前的轉場動畫會跳到結尾。
誤解 3：由於瀏覽器支援，因此無法實作檢視畫面轉場效果
許多開發人員擔心無法實作檢視畫面轉場效果，因為這項功能僅支援 Chrome。好消息是，Safari 正在處理這項問題，並會在即將推出的 Safari 18 版本中納入這項功能。
不過，請不要因為瀏覽器支援不穩定，就放棄實作轉場效果。檢視轉場效果是漸進式增強的絕佳素材。原始說明文件會分享將此方法加入程式碼的方法。
function handleClick(e) {
// Fallback for browsers that don't support this API:
if (!document.startViewTransition) {
updateTheDOMSomehow();
return;
}
// With a View Transition:
document.startViewTransition(() => updateTheDOMSomehow());
}
如果瀏覽器支援同一個文件的檢視畫面轉場效果，您就會看到經過強化的動畫版本。如果瀏覽器不支援，您就會看到目前的體驗。隨著越來越多瀏覽器支援檢視畫面轉場效果，更多使用者將能自動體驗這項功能強化版。
跨文件檢視畫面轉場也適用相同的規則。不支援這類功能的瀏覽器會在剖析樣式表時忽略 CSS 選擇加入功能。
這份個案研究詳細說明瞭這種做法如何成功應用於電子商務
錯誤觀念 4：檢視轉場會中斷逐步轉譯
有人聲稱檢視畫面轉場會中斷增量算繪。這並非事實：跨文件檢視轉場效果已指定為不會破壞網站的這項基本層面。
瀏覽器會在取得「足夠」的內容後開始轉譯網頁。在大多數瀏覽器中，這表示在載入 <head> 中的所有樣式表單、剖析 <head> 中的所有轉譯阻斷 JavaScript，以及載入足夠的標記之後。跨文件檢視畫面轉場不會改變這項情況：首次顯示內容所需的內容不會變更。第一次轉譯完成後，瀏覽器會逐漸轉譯新收到的內容。
您可以選擇在 DOM 中出現特定元素前，先阻止轉譯。如果您想確保參與檢視畫面轉場的元素會出現在新頁面上，這項功能就很實用。
如要這麼做，請使用這個連結標記：
<link rel="expect" blocking="render" href="#elementId">
這會覆寫瀏覽器用來決定何時執行首次算繪的分析法：首次算繪會延遲，直到指定元素出現在 DOM 樹狀結構中為止。
這個手動封鎖功能內建了一些保護機制。舉例來說，如果系統看到結尾 </html> 標記，但未看到阻擋元素，則算繪作業就不會再遭到阻擋。此外，您也可以自行新增逾時邏輯，隨時移除阻擋屬性。
顯然，您應謹慎使用轉譯阻斷功能。阻斷轉譯的影響必須視個案情況評估。根據預設，除非您能主動評估並評估 blocking=render 對使用者的影響，例如評估對成效指標的影響，否則請避免使用 blocking=render。
錯誤觀念 5：快照程序速度緩慢或成本高昂
當 View Transition API 準備新檢視畫面並取得快照時，使用者仍可看到舊檢視畫面。因此，使用者會比沒有檢視轉場效果時多看到舊版網頁一點。不過，這項延遲時間非常短，實際上只有幾格。舉例來說，在 Chrome 中，pageswap 的影響最多只會造成兩個過時的畫面：一個用於執行邏輯，另一個用於確保快照已完成合成及快取。
此外，快照的資料會直接從合成器取得，因此不需要額外的版面配置或重繪步驟，就能取得快照資料。
額外誤解：這是 View Transitions API
談論檢視畫面轉場時，大家通常會提到「View Transitions API」。這項資訊不正確。這個 API 稱為「View Transition API」，請注意「Transition」這個單數字詞。
這個錯誤觀念源自於某些文章 (包括我們在 DCC 上的文件) 使用錯誤的術語。
要記住正確的名稱，訣竅就是使用 (一個) View Transition API 建立 (一或多個) 檢視畫面轉場效果。