fix: support numeric values for CSS logical properties in useTransform

[reeseo3o]

Issue

• [BUG] useTransform doesn't work well with padding-block using numbers and other logical values #3413

Summary

useTransform did not correctly convert numeric values to pixel units when used with CSS logical properties (e.g. paddingBlock, paddingInline, marginBlock, marginInline), causing styles to update incorrectly.

This PR fixes the missing px conversion so CSS logical properties are handled consistently with other CSS properties.

Root Cause

CSS logical properties were missing from the internal px conversion mappings (numberValueTypes and pxValues).

As a result, numeric values returned from useTransform were written to the DOM without units and treated as invalid CSS.
Because CSS allows unitless 0, intermediate values were ignored, making updates appear to jump from 0 to the final value.

Solution

CSS logical properties were added to both px conversion paths.

Updated files

• packages/motion-dom/src/value/types/maps/number.ts
• packages/motion-dom/src/animation/waapi/utils/px-values.ts

Numeric values returned from useTransform are now converted to "px" before being applied to the DOM.

As-is / To-be

As-is

• Numeric values not converted to px
• Intermediate values ignored
• Values appear to jump during scroll

2025-12-27.11.27.31.mov

To-be

• Numeric values converted to pixel strings
• Intermediate values applied correctly
• Smooth updates during scroll

2025-12-27.11.31.44.mov

[shinseongsu]

Great PR! While you're at it, would it be possible to add support for the inset shorthand and its related logical properties?

Since they share the same shorthand logic as margin and padding, including them would ensure much better consistency. Specifically, I suggest adding the following properties to px-values.ts and number.ts

inset
insetBlock
insetBlockStart
insetBlockEnd
insetInline
insetInlineStart
insetInlineEnd

As-is

Current Issue Currently, when using CSS variables within these shorthand properties, they are not parsed correctly, as shown in the screenshots below

2025-12-28.3.22.24.mov

To-be

Expected Behavior By adding these to px-values.ts and number.ts, Framer Motion should be able to parse them correctly

2025-12-28.3.24.57.mov

I also noticed that #3413 is very similar to this. Since you're already "under the hood" and working on this part of the code, maybe we could bundle them together? It’d be awesome to have all these layout shorthands supported at once—it would make the CSS variable support so much more robust!

What do you think about tossing these into your PR?

[reeseo3o]

Great PR! While you're at it, would it be possible to add support for the inset shorthand and its related logical properties?

Since they share the same shorthand logic as margin and padding, including them would ensure much better consistency. Specifically, I suggest adding the following properties to px-values.ts and number.ts

inset
insetBlock
insetBlockStart
insetBlockEnd
insetInline
insetInlineStart
insetInlineEnd

As-is

Current Issue Currently, when using CSS variables within these shorthand properties, they are not parsed correctly, as shown in the screenshots below

2025-12-28.3.22.24.mov

To-be

Expected Behavior By adding these to px-values.ts and number.ts, Framer Motion should be able to parse them correctly

2025-12-28.3.24.57.mov
I also noticed that #3413 is very similar to this. Since you're already "under the hood" and working on this part of the code, maybe we could bundle them together? It’d be awesome to have all these layout shorthands supported at once—it would make the CSS variable support so much more robust!

What do you think about tossing these into your PR?

Good catch! I agree this should be supported as well.

Since the inset* properties share the same shorthand logic and root cause,
I'll add them to the px conversion mappings in this PR for consistency.

Thanks for sharing the examples!