Open KermanX opened 5 months ago
Found a relative tweet about KaTex magic move: https://x.com/FreyaHolmer/status/1782498316330103180
Would https://developer.mozilla.org/en-US/docs/Web/API/View_Transitions_API be the universal solution? But I suppose in order to have good animations (like Shiki and KaTex), it has to be specific at some extent to know what to animate.
I think the major problem is that, compared to Reveal.js, the parsed slides in Slidev are Vue templates instead of HTML elements. The dynamic parts in the Vue template (e.g., v-for
) make it much harder to "diff" two slides - some information like key
is only known on client runtime, but it is very hard to diff and generate animations on the client.
Diff Vue template AST on the server.
Pros:
Cons:
v-for
may have to be considered as a whole without animation.Diff VNodes on the client after slide components are mounted. Then apply view-transition-name
to the elements.
Pros:
Cons:
view-transition-name
styles may get lost because they are added via DOM API instead of normal template code.Solution 1 seems more interesting to me because I think it is more valuable to have a solution that can animate as many elements as possible. I myself use a lot of equations in my slides, and it would be interesting if they could be animated.
However, if Solution 1 is too complex, I believe Solution 2 could be used, and in addition to that, a separate KaTeX Magic Move solution (similar to Magic Move) could be created (or an existing one could be used), allowing the animation of KaTeX equations.
In addition to this, a synchronization system for different "magic move blocks" could be implemented. This would be very useful for the second solution, where we would probably have more than one "magic block" (Magic Move, Universal Magic Move, KaTeX Magic Move) on the same slide. For example, we could define the starting click of the transition sequence for each "magic move block", or we could pass an array of clicks to define the moment (click) of each transition.
Originally posted by @lucaslrodri in https://github.com/slidevjs/slidev/issues/1515#issuecomment-2052058005
It would be nice if the universal
magic-move
were inspired by Reveal.js Auto-Animate. In summary, Auto-Animate considers matching elements if they have:id
(Priority - see thedata-auto-animate-id
attribute, explained here).src
attribute is compared.For situations where the automatic-matching algorithm is not feasible or does not provide the correct matching, you can add the
data-magic-id
property to the elements you want to animate. This property is prioritized over automatic matching.In addition to the features of Auto-Animate, the following considerations can be taken into account:
shiki-magic-move
algorithm.magic-move
in KaTeX equations. I believe that with this implementation, it's possible to create transitions like this one done in Manim. I'm not sure exactly how to do the implementation in this case, but I consider two possibilities:shiki-magic-move
.<span>
tags.\htmlData{magic-id=a}{x}
(or similar) to implement the transition functionality between elements with the sameid
.x
,y
),fill
,stroke
,d
(<path>
),width
andheight
(rect
)Finally, users can modify (or extend) the automatic-matching algorithm, as is possible in Reveal.js Auto-Animate, by writing a custom automatic matching function, opening up the possibility of implementing plugins based on the
magic-move
feature.