✅ Deploy Preview forsvelteplot ready!

Name	Link
🔨 Latest commit	8dc39e3
🔍 Latest deploy log	https://app.netlify.com/projects/svelteplot/deploys/68f3f0bd3951020008e2f37a
😎 Deploy Preview	https://deploy-preview-233--svelteplot.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to yourNetlify project configuration.

📦 Preview package for this PR is published!

Version:0.5.0-pr-233.0

Install it with:

npm install svelteplot@pr-233# or install the specific versionnpm install svelteplot@0.5.0-pr-233.0

📦 Preview package for this PR is published!

Version:0.5.0-pr-233.1

Install it with:

npm install svelteplot@pr-233# or install the specific versionnpm install svelteplot@0.5.0-pr-233.1

@bothness following your initiative in#231 I tried how far I would get with CSS-based transitions in SveltePlot. The CSS transitions do work fine, but I had to find a solution for allowing to pass a Svelte transitions for grid lines and axis ticks so we can also animate ticks getting introduced and ticks leaving the DOM.

The syntax is still a draft, but we can experiment with it.

consttIn=[fade,{duration:300,delay:500}];consttOut=[fade,{duration:500}];setPlotDefaults({axis:{ tIn, tOut},grid:{ tIn, tOut},})

you can see it in action here:https://svelte.dev/playground/71f57033f5124a638a66c3a647650dae?version=5.41.0

However this approach has its limitations, as some marks can't be simply transitioned via CSS.

For instance, and SVG path cannot yet animate its path string via CSS, so if the plot includes a line mark, the transitions break, as you cansee here. Similarly, CSS transitions obviously also don't work with with canvas-rendered marks, asdemonstrated here.

That's why so far I have always resorted to (manual)domain transitions using Tween fromsvelte/motion, like shown inthis example.

So there are a few questions:

1. Should we introduce the tick transitions anyway for situations where pure CSS-based transitions suffice? I assume that CSS-only transitions are more performant than re-computing all positions and paths for every frame during a transition.
2. Should we at some point handle domain transitions automatically inside SveltePlot to make this easier to use?
3. How do we feel about thetIn|tOut=[fn, options] syntax in general? I was hoping that at some point Svelte will make it easier to pass transitions through custom components so we don't have to invent our own syntax.
4. Is this something we want to expand to other marks? Having a way to animate dots entering an leaving a plot would be nice, right?
5. How do we feel about following down the path of solving the SVG path transitions using custom animations, similar to themorphTo function from animejs?

Hi@gka. Thanks for taking this onboard!

I'm not sure if there's a route to supporting CSS transitions for all mark types, but there's a surprisingly large subset where there's a potential... And perhaps a possibility to polyfill others using appropriate JS libraries(?)

I worked on a proof-of-concept chart library with CSS transitions a while back (using Lit, but same principles apply in Svelte), and it's even possible to do things like a bar chart race.
https://stackblitz.com/edit/lit-charts?file=package.json

With regards to path transitions, there's definitely some level of support in Chromium and Firefox, but apparently not yet Safari. I haven't tested what the limits are as yet, but definitely it works fine when the number of vertices on a line remains constant.
https://developer.mozilla.org/en-US/docs/Web/CSS/d

My apologies@gka.

I read your post in a hurry and skipped over some of the details.

I should have some time to investigate a bit further and think through your questions over the coming week. But you're right that this obviously won't cover scenarios like canvas.

However, I did manage to get your path example to work in my Chromium browser using a transition on the d property of the path:
https://svelte.dev/playground/ded86aadc041475bbf567fbce76e236f?version=5.41.0

Update: This example also works for me in Firefox. On Safari 17.6 on MacOS Sonoma I don't seem to get any transitions on either the axes or the paths (there should be support in Safari for transitioning the axis transforms, but seems it supports fewer cases than other browsers).

@gka I had a chat with a couple of colleagues about the points you raised above. The context is that we've just started a process of overhauling our rather limitedsvelte-charts library, and are hoping to use SveltePlot as a core to build a much wider range of templates on top of. This existing library was largely focused on being able to run dynamic/animated charts for scrollytelling articles (see examples inthis template).

Alongside looking for a core library to build around, we've also been doing experiments with CSS chart transitions with generally very good results in terms of performance (like theLit example above), so it would be great to kill two birds with one stone if high performance transitions were supported out-of-the-box in SveltePlot.

With regards to your specific questions:

1. Since CSS transitions work with SveltePlot to some degree already, it would seem like there's little loss in making sure that they can be supported more widely wherever it's possible to do so (eg. in the case of the axis ticks/lines) without making larger changes that might add undue complexity or hit performance elsewhere.
2. I would suggest that whether to handle transitions more globally is probably ultimately a question for you as the owner of this project, though I suspect that having a built-in approach to transitions (whether that's using CSS, Svelte tweening or a hybrid approach) could be a major selling point for SveltePlot.
3. ThetIn|tOut syntax looks really promising to us, but can totally understand the risk that any library-specfic syntax or implementation might get overtaken by future Svelte developments.
4. Definitely would be great to enable other kinds of transitions. Definitely there are nuances that have to be handled in many of these cases. (Eg. for new points "entering" the chart - as for axis ticks - it's useful for the new points/ticks to enterbefore the domain and scale are updated, allowing them to transition from the location that theywould have been in before the update).
5. Re path transitions, I guess it depends a lot on how tightly integrated with SveltePlot the implementation can be. I haven't used anime.js before, but have previously made use offlubber.js, which worked nicely with Svelte tween to interpolate from one path string to another (basic example here, and an anactual article using it here). I guess this approach may work as a kind of polyfill for future improvements to CSS path transitions?

I would be happy to have a chat to discuss the above and how best to contribute to these efforts, and generally to the development of SveltePlot. Please do feel free to DM me on that front!

Thanks for your feedback@bothness!

I think I'd like to explore this idea further. A few more observations:

• In my draft users have to provide separate transitions for ticks and grid lines when in reality you almost always want to synchronize them. This makes we wonder if the entire transition business should be abstracted a bit more. For instance, there could be a global transition property in the plot through which users provide the easing function and duration, and the rest is automatically handled in the marks. By not relying on the pure CSS functions fromsvelte/transition this also makes it easier to implement custom non-CSS fallback transitions internally.
• One drawback of such a global transition prop would be that scenarios get more complicated where you want to transition some marks while disabling transitions in other marks. I guess marks could still have a localtransition prop that can be set tofalse in these cases.
• Good point about ticks/gridlines/points entering the plot at the pre-transition position to then fade and move simultaneously. I would even say this is a necessary requirement as otherwise the in-between states during a transition are "breaking" the scales (as entering grid lines are drawn at the wrong positions). This is another strong argument for implementing our own transitions internally rather than relying onsvelte/transition.