-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update view-transitions.mdx #10951
Update view-transitions.mdx #10951
Conversation
✅ Deploy Preview for astro-docs-2 ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
Lunaria Status Overview🌕 This pull request will trigger status changes. Learn moreBy default, every PR changing files present in the Lunaria configuration's You can change this by adding one of the keywords present in the Tracked Files
Warnings reference
|
Hello! Thank you for opening your first PR to Astro’s Docs! 🎉 Here’s what will happen next:
|
Thanks for making a PR to update the docs, @alexgagnon ! This is a helpful piece of information to add! I've made an edit where I think your ideas could best go. (I didn't delete your note at this time, but my addition is meant to replace your note.) Firstly, it's never great docs when we have multiple notes in a row! 😅 We can't just have a bunch of stuff competing for people's attention at the top of the page! So, we always try to work content in where on the page it belongs. You correctly identified, and even linked to, the appropriate section, so this is really the place where your information goes! 🙌 Instead of a note, I've added more context to the explanation of fallback content, and added another example to illustrate. (It might not be the best one, so please suggest something better!). I think the new version gets your information across, and shows being explicit about transitions, relying on Astro's built-in fallback I'll also note that it's not practical to be listing which browsers do or don't have support while things are constantly changing. Especially when these are not updates that we control or necessarily even know about, it puts our docs at risk of being outdated when someone else updates their feature set. So, we would not list browsers, but instead only refer to "browsers without support." I thought somewhere we had a link to a "current browser support status page" but I don't see it in this guide page of our docs. That would be a thing we could link to so people can always see the most updated status of browser support. But we are not going to try to keep up with any kind of list ourselves. 😅 So see what you think of the general shape of my suggestion, and maybe suggest a more realistic example, and let's figure out how to not use a note at the top of the page, but get all the info you want right here! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Sorry I missed your note, I'll re-review when I get a chance. However, I do feel having some more explicit information about browser differences at the top is important. I develop primarily on Firefox. When I went through the existing docs and it talks about how all you need to do is add ClientRouter and it will "just work", it did not work. It took me 2 hours to figure out why: that Firefox doesn't support view transitions, and because of that I then needed to read the fallback section more closely, and even in that section it wasn't super clear that because i was using an unsupported browser, it wouldn't work unless I specifically added a name or animation directive. This is probably worse for people for older versions of safari in iOS, who unless they're using an emulator would not even know that the behavior was different until they published and got feedback. Just hoping that by putting it at the top we can save other devs wasted time. |
I get that, and in fact, I think maybe the first bit could instead be rewritten because a lot has changed since these docs were first written... both in Astro, and in what native browser view transitions do.
What about an intro something like that? |
Yeah that's perfect :). Would you like me to update the PR or close it and it can be updated in the main repo? |
@alexgagnon Update it here! So that means that this PR would have an updated initial paragraph, as well as new content to the fallback section, and we'd be all good I think! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, I think this looks great and is much improved! Thank you @alexgagnon for your efforts and patience, and welcome to Team Docs! 🥳
The `<ClientRouter />` router works best in browsers that support View Transitions (i.e. Chromium browsers), but also includes default fallback support for other browsers. Even if the browser does not support the View Transitions API, Astro will still provide in-browser navigation using one of the fallback options for a comparable experience. | ||
The `<ClientRouter />` router works best in browsers that support View Transitions (i.e. Chromium browsers), but also includes default fallback support for other browsers. Even if the browser does not support the View Transitions API, Astro's client router can still provide in-browser navigation using one of the fallback options. | ||
|
||
Depending on browser support, you may need to explicitly set the `name` or `animate` [`transition` directives](#transition-directives) on the elements you wish to navigate for a comparable experience across all browsers: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depending on browser support, you may need to explicitly set the `name` or `animate` [`transition` directives](#transition-directives) on the elements you wish to navigate for a comparable experience across all browsers: | |
Depending on browser support, you may need to explicitly set the `name` or `animate` [`transition` directives](#transition-directives) on the elements you wish to animate for a comparable experience across all browsers: |
Description (required)
Add additional note about behavior in browsers that don't support View Transitions.
Related issues & labels (optional)
ViewTransitions Default Behaviour doesn't work on Firefox astro#13064
Yes
alexgagnon