Independent transform polyfill. Always include?

[mattgperry]

Hi all

Motion Concept C supports animating individual transforms (yey!)

// Vanilla
animate(element, { x: 100, rotate: 90 })

// React
<animated.div initial={{ scale: 0 }} style={{ scale: 1 }} />

Unfortunately, this feature relies on a browser supporting CSS.registerProperty (o no)

Chromium browsers already support this API, but as for Safari and Firefox - who knows. To take a progressive enhancement approach, Motion will instantly animate in browsers that don't support CSS.registerProperty.

I didn't feel like this was quite good enough so over the last couple weeks I've been pottering on tiny number-only polyfill that can animate these values in every browser.

The good news is that it's quite small, around 1kb. But this could grow in size if we chose to support non-numeric CSS variables.

However, relative to the rest of the API, that's quite big. It bumps vanilla Motion from 1.7 to 2.7kb, and Motion for React from 3kb to 4kb.

So there's two approaches we could take. One, always include the polyfill. This will be the better DX. Alternatively, offer the polyfill as an optional extra. This would mean smaller bundle sizes by default but a little more scaffolding for people who wanted to opt-in to this behaviour.

Here's what the API might look like:

// Always include polyfill - 2.7kb
import { animate } from "motion"

animate(element, { x: 100 })

// Optional polyfill - 1.7kb + optional 1kb
import { animate, animateNumber, setMotionGlobals } from "motion"

/**
 * Set polyfill. You'd only have to do this once.
 * If polyfill isn't set, independent transform animations
 * become instant transitions
 */
setMotionGlobals({
  independentTransformPolyfill: animateNumber
})

animate(element, { x: 100 })

I'm interested in hearing other people's thoughts in this trade-off between bundlesize and DX. What do you think?

[lunelson]

Is it possible to include a global stylesheet that accomplishes the creation of the CSS properties that you want to animate, and might this have better browser support?

[lunelson]

The support spectrum for CSS @property is the same as the CSS.registerProperty API I assume, so using CSS won't let you control their inheritability and expected and default units like the better API does; but maybe you can adapt your JS API around simple custom properties (implicitly non-inheritable) with defaults like this:

* {
  --motion-translatex: 0px;
  --motion-translatey: 0px;
  --motion-translatez: 0px;
  --motion-rotatex: 0deg;
  --motion-rotatey: 0deg;
  --motion-rotatez: 0deg;
  --motion-skewx: 0deg;
  --motion-skewy: 0deg;
  --motion-skewz: 0deg;
  --motion-scalex: 1;
  --motion-scaley: 1;
  --motion-scalez: 1;
}

[okikio]

The WAAPI can only animate css vars. that are given an explicit type, that's why @property and CSS.registerProperty are so important, they let you specify the type, a css variable supports.

[lunelson]

@okikio Ah OK got it. I figured that was probably the catch 😁

[mattgperry]

I settled on always including it. It does bump the bundlesize to 3kb overall but I decided the number polyfill adds a few other benefits, for instance it could be possible to run one as a "shadow" animation to a WAAPI animation to provide extra lifecycle methods like onRepeat. Also it could be exposed directly

animateKeyframes((output) => {}, [0, 1])

At this point you can easily provide tree-shakable advanced APIs like this:

animateKeyframes((output) => {}, color("#fff", "#000"))

[lunelson]

Glad to hear it! FWIW my 2¢ was otherwise going to be that as a user I'd probably prefer to deal with one support spectrum if possible (browsers supporting WAAPI, or not), rather than have to worry about overlapping ones, and I'd recommend polyfilling supporting APIs where necessary

[subtleGradient]

FWIW, 4k wasn't even a big deal in 2007. Nowadays it's beyond totally fine

[mattgperry]

I think that's true if you're making a product and you know your audience but when it's a library you don't even know the product so the audience could be anywhere in the world on any awful connection. Having said that I think the first release will be about 3.2kb for animate and 3.8 for timeline so I'm quite happy with that!

[lunelson]

Aside: I came across this post from Stefan Judis a while ago which notes that the upcoming CSS spec for individual transform properties has a built-in default order, which seemed worth keeping in mind in terms of alignment of this API.

[mattgperry]

That’s a good shout, we definietly do transform before scale but I’ll check rotate/scale and align before 1.0