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()