You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/content/docs/tips/css.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -189,5 +189,5 @@ Same hold for the auto-generated view transition name example: it works for all
189
189
## Conclusion
190
190
I'm still exploring paths and alternatives but this would be my current recommendations:
191
191
1. For complex pages, ensuring the uniqueness of view transition names might be easier if you assign them dynamically in the browser using JavaScript, or in a page global action on the server.
192
-
2. Placing your view transition animation definitions in a global CSS file can be a good approach. This ensures that both the old and new pages use the same definitions, so you do not have to worry about where to put them. Just make sure your keyframe and view transition names are either globally unique or intentionally the same.
192
+
2. Placing your view transition animation definitions in a global CSS file can be a good approach. This ensures that both the old and new pages use the same definitions, so you do not have to worry about where to put them. Just make sure your keyframe and view transition names are either globally unique or intentionally the same. Just make sure that the @view-transition at-rule occurs in the first few bytes of the CSS file. Otherwise the browser might ignore it.
193
193
3. Utilizing [view transition classes and types](/basics/styling/#with-classes) can help decouple usage from definitions, making your code more flexible."
0 commit comments