Universal Magic Move

[kermanx]

Originally posted by @lucaslrodri in #1515 (comment)

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:

• The same id (Priority - see the data-auto-animate-id attribute, explained here).
• The same node type and identical texts (or other identical attributes if necessary).
• For images, videos, and iframes, the src attribute is compared.
• The order in which the element appears in the DOM is also taken into consideration.

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:

• Code Blocks: Uses the shiki-magic-move algorithm.
• Equations: It would be interesting to implement 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:
  • The matching algorithm could take into account the LaTeX code combined with the Diff Match Patch algorithm, similar to shiki-magic-move.
  • Another option would be to take into account the rendered result of KaTeX, considering <span> tags.
  • ID implementation: Use raw HTML notation \htmlData{magic-id=a}{x} (or similar) to implement the transition functionality between elements with the same id.
• SVG: Smooth transitions between SVGs allow animating more complex shapes like diagrams and charts. In this case, we use the same rules explained earlier. In addition to CSS properties, SVG properties can be taken into account, such as:
  • Position (x, y),
  • fill, stroke,
  • d (<path>),
  • width and height (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.

[kermanx]

Found a relative tweet about KaTex magic move: https://x.com/FreyaHolmer/status/1782498316330103180

[antfu]

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.

[kermanx]

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.

Solution 1

Diff Vue template AST on the server.

Pros:

• Allow to provide custom animations based on source code. For example, mix in shiki-magic-move and KaTeX animations.

Cons:

• Dynamic content like those generated via v-for may have to be considered as a whole without animation.
• Implementation may be complex, since Vue template AST is more complex than HTML.

Solution 2

Diff VNodes on the client after slide components are mounted. Then apply view-transition-name to the elements.

Pros:

• Supports dynamic content. Simpler implementation.
• Simpler implementation

Cons:

• Cannot mix in shiki-magic-move or KaTeX animations.
• Applied view-transition-name styles may get lost because they are added via DOM API instead of normal template code.

[lucaslrodri]

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.