Field guide
Read browser readiness in three layers
Use specifications, implementation guidance, and compatibility evidence to make a decision you can explain.
Write down the exact feature
Begin with a sentence about the interaction you want to ship. A useful example is: animate a change inside the current page while keeping the underlying update functional. That is more precise than adopting view transitions. The API family includes both same-document changes and transitions during navigation between documents, so one broad label can conceal several different support questions.
Keep that sentence beside the implementation. It defines what evidence you need and prevents a promising demo from quietly expanding the scope. If the design later adds cross-document navigation, treat that as another capability to evaluate.
Sources: MDN: View Transition API
Specification: understand the contract
A specification describes the behavior being defined: the objects involved, the steps an operation follows, and the conditions that matter. For a dialog, the HTML Standard distinguishes showing the element from showing it modally. That distinction changes whether the surrounding document is blocked from interaction. Reading the relevant section helps you identify the behavior your design actually requires.
Use the specification to resolve terminology and edge cases. Keep its status and scope in view, especially when following an evolving draft. Its existence is one piece of evidence; you still need implementation guidance and compatibility information before deciding where to use it.
Sources: WHATWG HTML: the dialog element
Implementation: follow the whole interaction
An implementation guide translates the feature into something you can build. Look for the entry point, the update sequence, and the behavior when the enhancement cannot run. MDN's startViewTransition() example checks for the method and performs the underlying change directly when it is absent. That is a useful pattern because the content update has its own working path.
Browser documentation can also explain an implementation in depth. Keep the browser and feature scope attached to those examples. A successful demonstration should lead to a small reproduction of your own interaction, including keyboard use, interrupted actions, and whatever content your page really contains.
Sources: MDN: startViewTransition() basic usage, Chrome for Developers: View transitions
Support: inspect the relevant rows
Compatibility evidence answers a narrower question: which versions implement the particular method, property, or value you plan to use? Open the detailed table and read its notes. For view transitions, inspect startViewTransition() and the cross-document @view-transition rule separately. Support for one entry point does not settle the other.
Baseline offers a helpful summary across its defined browser set. MDN explicitly says it does not replace accessibility, usability, performance, or other testing. Map the compatibility evidence to the environments your work needs to serve. Keep older browser requirements and embedded browser contexts visible instead of letting a summary badge make that decision implicitly.
Sources: MDN: startViewTransition() compatibility, MDN: @view-transition compatibility, MDN: Baseline compatibility
Leave a decision someone can revisit
Finish with a compact record: the exact capability, the sources and date checked, the environments to test, and the behavior when the capability is missing. A CSS.supports() result can help select a code path, but that test has a defined scope. It does not demonstrate that your whole interface behaves well.
Our editorial recommendation is to adopt a feature when its benefit is clear and the remaining checks are explicit. A later reader should be able to repeat the reasoning without reconstructing a launch announcement or guessing which version of a broad feature family you meant.
Sources: MDN: CSS.supports()
Write a decision for one concrete state change
Use this fictional task to practice turning a feature label into a bounded release decision: a button switches two example resource cards between list and grid layouts on the same page. The card titles and destination links must remain available, and the switch must remain usable by keyboard. Navigation between documents is outside this exercise. This is a proposed check, not a tested demonstration.
In Browser Feature Explorer, find View transitions and open its adoption checklist. Write “same-document list/grid switch; two cards; direct update is the fallback” in the notes. Add the browser versions you intend to test, then use the guide’s existing documentation and compatibility links to investigate that exact entry point. Do not treat a compatibility row as evidence that keyboard focus or repeated actions worked.
Prepare three runs of your own implementation: enhancement enabled, the direct-update fallback selected, and reduced motion requested. Start each with the same two cards and list layout. Activate Grid using the keyboard, return to List, and repeat the change quickly. For each run, record whether the expected cards and links remain, which element has focus, and whether an interrupted animation leaves the latest requested layout usable.
Leave a checklist item unmarked until you have evidence for it. If one run cannot be exercised, record that limitation instead of treating another run as equivalent. Download adoption notes to preserve the scope and remaining checks. The explorer exports all eight feature records, even when the screen is filtered to one; marked checks are your record, not automated validation. Keep screenshots or reproduction files beside that export when available.
Continue with Open Browser Feature Explorer.
Related guides
Primary references
Useful Tomorrow home · All guides and studies · Awesome Patel’s publication profile