Fragment Plugin + Swup Themes
Closed this issue · 4 comments
We need to think about how we want to deal with the combination of fragment plugin + swup themes.
Describe the problem
When using the fragment plugin, the default animation needs to be targeted only for non-fragment-visits:
Before:
html.is-animating .transition-main {
/* ... */
}
After:
html:not([data-fragment-visit]).is-animating .transition-main {
/* ... */
}
Describe the proposed solution
Option 1: Tell people that when using fragment plugin, they should author their transition styles manually (e.g. "Don't use a swup theme when using the fragment plugin")
Option 2: Find a way (probably in @swup/theme
) to work nicely together with the fragment plugin
How important is this feature to you?
- Very important before we launch the fragment plugin
I think this is solved by the recent CSS API updates.
Let me look into it one more time
🧃
The themes would still interfere with the current transition duration detection for fragment visits. Take the fade theme for, example:
https://github.com/swup/fade-theme/blob/35e6fae9fd81aec229788bb6c9c386baff0051b0/src/index.css#L1-L8
The transition duration for .swup-transition-main
is set, regardless of the html
currently changing (.is-changing
).
So if a fragment visit's transition duration would be 200ms
, the visit would still take .4s
, because swup always waits for the longest transition duration of the current animationSelector
.
I think the solution would be to overwrite animationSelector
for fragment visits, and feed the current fragments as selector. So if the fragments for a visit would be ["#fragment-1", "#fragment-2"]
, the animationSelector
should be changed to #fragment-1, #fragment-2
for that visit.
This way, swup would ignore any transition-
classes for that visit and everything would be fine I guess 😅
This would also have the advantage that the fragment plugin wouldn't require scoping all default animations to html.is-changing
. I'll create an issue for overwriting the animationSelector
in the context.