Skip to content
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

Merged
merged 8 commits into from
Feb 24, 2025
Merged

Update view-transitions.mdx #10951

merged 8 commits into from
Feb 24, 2025

Conversation

alexgagnon
Copy link
Contributor

Description (required)

Add additional note about behavior in browsers that don't support View Transitions.

Related issues & labels (optional)

Yes

alexgagnon

Copy link

netlify bot commented Feb 13, 2025

Deploy Preview for astro-docs-2 ready!

Built without sensitive environment variables

Name Link
🔨 Latest commit 97e72d0
🔍 Latest deploy log https://app.netlify.com/sites/astro-docs-2/deploys/67bbc5f87853ef00084c774d
😎 Deploy Preview https://deploy-preview-10951--astro-docs-2.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@astrobot-houston
Copy link
Contributor

astrobot-houston commented Feb 13, 2025

Lunaria Status Overview

🌕 This pull request will trigger status changes.

Learn more

By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.

You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

File Note
en/guides/view-transitions.mdx Source changed, localizations will be marked as outdated.
Warnings reference
Icon Description
🔄️ The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

@astrobot-houston
Copy link
Contributor

Hello! Thank you for opening your first PR to Astro’s Docs! 🎉

Here’s what will happen next:

  1. Our GitHub bots will run to check your changes.
    If they spot any broken links you will see some error messages on this PR.
    Don’t hesitate to ask any questions if you’re not sure what these mean!

  2. In a few minutes, you’ll be able to see a preview of your changes on Netlify 🥳.

  3. One or more of our maintainers will take a look and may ask you to make changes.
    We try to be responsive, but don’t worry if this takes a few days.

@sarah11918
Copy link
Member

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 animate setting to kick in. And then, the existing example is a second one, to show if you want to override the default fallback. This feels like the right way to add the new information you want to bring.

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!

@sarah11918 sarah11918 added the improve or update documentation Enhance / update existing documentation (e.g. add example, improve description, update for changes) label Feb 14, 2025
Copy link
Contributor Author

@alexgagnon alexgagnon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@alexgagnon
Copy link
Contributor Author

alexgagnon commented Feb 16, 2025

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.

@sarah11918
Copy link
Member

However, I do feel having some more explicit information about browser differences at the top is important.

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.

 Astro supports view transitions with just a few lines of code. View transitions update your page content without the browser’s normal, full-page navigation refresh and provide seamless animations between pages. Where [browser support for the View Transition API](https://developer.mozilla.org/en-US/docs/Web/API/View_Transition_API#browser_compatibility) is lacking, Astro allows you to [control fallback strategies](#fallback-control) for the best possible experience for all visitors.  

What about an intro something like that?

@alexgagnon
Copy link
Contributor Author

Yeah that's perfect :). Would you like me to update the PR or close it and it can be updated in the main repo?

@sarah11918
Copy link
Member

@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!

Copy link
Member

@sarah11918 sarah11918 left a 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! 🥳

@sarah11918 sarah11918 added the Merge Queue Approved and ready to be merged (wait for feature release if also labelled M-O-R)! label Feb 23, 2025
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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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:

@sarah11918 sarah11918 merged commit ef9179a into withastro:main Feb 24, 2025
5 of 6 checks passed
ArmandPhilippot added a commit to ArmandPhilippot/astro-docs that referenced this pull request Feb 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improve or update documentation Enhance / update existing documentation (e.g. add example, improve description, update for changes) Merge Queue Approved and ready to be merged (wait for feature release if also labelled M-O-R)!
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants