-
Notifications
You must be signed in to change notification settings - Fork 441
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
Rename meta tag used to enable view transitions to turbo-view-transition #1380
base: main
Are you sure you want to change the base?
Conversation
ad3c458
to
fb4bc81
Compare
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.
This looks good! I agree we shouldn't hold on to the meta tag, now that the standards have moved on (but also that we should keep it around for a while, for compatibility).
I would extend the tests to cover both cases, as you say. Probably easiest to make two versions of the fixtures, and then extend the current view transition tests to cover both sets.
The only other suggestion I have is: it would be even nicer if we could detect the behavior from the @view-transition
CSS. Then we wouldn't need a setting at all, and the Turbo-enabled behavior would match the default browser behavior.
The rule itself should be present as a CSSViewTransitionRule
in the stylesheets, so we'd at least have access that way. But I don't know if there are practical problems with detecting it in all cases. What do you think, is it something you've looked into?
The CSS rule describes the behavior for MPA view transitions, on the one hand to me this feels a little weird to piggy back this config but for a SPA, because ultimately we use the SPA api ( on the other hand it kinda makes sense as Turbo is designed to be dropped on a regular MPA and enhance it instantly without much special config. However I have no idea if it is even possible to detect the presence of the rule from JS, I need to look into it |
Ah yes indeed inside If you confirm we should go this direction rather than the meta config, I will update the PR accordingly |
@Intrepidd I definitely think that's worth a shot, yes. For me, one of the nicest parts of Turbo is that, as you say, you just drop it in and it can make things better. With browsers supporting MPA view transitions, this would be a case where dropping in Turbo would make something "worse" until you manually opt-back in with the setting. But if we can reliably detect that option from the stylesheet, then the MPA view transitions will continue to work alongside the rest of Turbo's features, without having to explicitly set anything. The fact that Turbo uses the SPA to do it is just an aspect of how Turbo is making page navigations more SPA-like already. |
@kevinmcconnell So one problem I'm seeing is that in order to check for the presence of the rule it seems I need to access the This doesn't play well with page snapshots because we have the current document, and the current and incoming snapshots, but obviously no document yet for the incoming page. I've tried playing with document.implementation.createDocument but the created document Any idea ? |
See #1379
I guess I should add tests for the backwards compatibility, could they be in a different file, with different fixtures, for easier removability when we decide to drop it ?