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，並載入足夠的標記後。跨文件檢視轉換不會改變：First Contentful Paint 所需的內容會維持不變。首次轉譯後，瀏覽器可以並漸進式轉譯新收到的內容。
您可以選擇阻止轉譯，直到 DOM 中出現特定元素為止。如果您想確保新頁面能確實參與觀看轉換的元素，這個做法就十分方便。
方法是使用下列連結代碼：
<link rel="expect" blocking="render" href="#elementId">
這會覆寫瀏覽器用來決定首次轉譯時間的瀏覽器經驗法則：首次轉譯會延遲到指定元素出現在 DOM 樹狀結構中。
這項手動封鎖功能內建了一些保護措施，例如，如果看到 </html> 結尾標記，但未顯示封鎖元素，就不會再封鎖轉譯。此外，您也可以新增自己的逾時邏輯，隨時移除封鎖屬性。
請謹慎使用轉譯封鎖功能。請依個案評估封鎖轉譯功能的影響。根據預設，除非您可積極評估及評估這項行為對成效指標的影響，否則請避免使用 blocking=render。
誤解 5：建立快照的程序很慢或成本高昂
雖然 View Transition API 準備新檢視表並取得其快照，但使用者仍會看到舊的檢視表。因此，使用者看到舊網頁所需的時間，會比未發生檢視轉換效果稍微久一點。這種延遲是可以忽略的，但實際上只有幾個畫面。以 Chrome 為例，pageswap 的影響最多有兩個：一個用於執行邏輯，再加上一個用來確保快照經過合成及快取的額外影格。
此外，快照的資料會直接擷取自合成器，因此不必執行額外的版面配置或重新繪製步驟，即可取得快照資料。
額外的誤解：這是 View Transitions API
談到觀看轉換時，大家通常會使用「View Transitions API」。答錯了。這個 API 稱為「View Transition API」，單點「Transition」。
這個誤解的部分來自部分文章，包括使用錯誤字詞的專屬 DCC 相關文件。
要記住正確名稱的技巧，就是使用 (一個) View Transition API 建立 (一或多個) 檢視轉場效果。