@astryxdesign/core 0.4.4 → 0.4.5-canary.1fdecb1

package/src/theme/derivedVarRegistry.ts

@@ -67,6 +67,10 @@ export const derivedVarRegistry: Record<string, DerivedVarEntry[]> = {
   ],
   field: [{property: 'borderRadius', vars: ['--_field-radius']}],
   hovercard: [{property: 'borderRadius', vars: ['--_hovercard-radius']}],
+  'number-input': [
+    {property: 'padding', expand: 'container'},
+    {property: 'borderRadius', vars: ['--_field-radius']},
+  ],
   popover: [{property: 'borderRadius', vars: ['--_popover-radius']}],
   'progressbar-mark': [
     {property: 'width', vars: ['--_progressbar-mark-width'], replaces: true},

package/src/theme/generateThemeRules.test.ts

@@ -584,3 +584,82 @@ describe('brutalist-style derived expansion', () => {
     expect(rule).toContain('--_dropdown-menu-padding: 4px');
   });
 });
+
+describe('physical padding longhands', () => {
+  const ruleFor = (
+    component: string,
+    base: Record<string, string>,
+    name = 'test-physical-padding',
+  ) =>
+    generateThemeRules(
+      defineTheme({name, components: {[component]: {base}}}),
+    ).find(r => r.includes(`.astryx-${component}`));
+
+  // `padding-top`/`padding-bottom` ARE the block edges in every horizontal
+  // writing mode, so the expansion can normalize them with no direction
+  // assumption. Without that, the padding lands raw on the element and the
+  // component's internals — the NumberInput stepper column, container bleed —
+  // read the default instead of what the theme set.
+  it.each([
+    ['paddingTop', {paddingTop: '14px'}, 'block-start'],
+    ['paddingBottom', {paddingBottom: '14px'}, 'block-end'],
+  ])('routes %s through the container expansion', (_label, base, edge) => {
+    const rule = ruleFor('card', base);
+    expect(rule).toContain(`--astryx-card-padding-${edge}: 14px`);
+    expect(rule).not.toMatch(/[{;]\s*padding-(top|bottom):/);
+  });
+
+  it('normalizes both block edges together, asymmetrically', () => {
+    const rule = ruleFor('number-input', {
+      paddingTop: '14px',
+      paddingBottom: '6px',
+    });
+    expect(rule).toContain('--astryx-number-input-padding-block-start: 14px');
+    expect(rule).toContain('--astryx-number-input-padding-block-end: 6px');
+  });
+
+  it.each(['card', 'dialog', 'section', 'number-input'])(
+    'reaches %s, which expands its padding',
+    component => {
+      expect(ruleFor(component, {paddingTop: '14px'})).toContain(
+        `--astryx-${component}-padding-block-start: 14px`,
+      );
+    },
+  );
+
+  // THE RTL GUARD. `paddingLeft` is inline-start in LTR and inline-end in RTL,
+  // and the tokens are consumed by logical properties, so mapping it would
+  // silently move the padding to the other edge in RTL. It stays physical —
+  // which is what the author wrote — and does not reach the tokens.
+  it('leaves the direction-relative inline pair physical', () => {
+    const rule = ruleFor('card', {paddingLeft: '20px', paddingRight: '8px'});
+    expect(rule).toContain('padding-left: 20px');
+    expect(rule).toContain('padding-right: 8px');
+    expect(rule).not.toContain('--astryx-card-padding-inline');
+  });
+
+  it('expands the block edges while leaving left physical', () => {
+    const rule = ruleFor('card', {paddingTop: '14px', paddingLeft: '20px'});
+    expect(rule).toContain('--astryx-card-padding-block-start: 14px');
+    expect(rule).toContain('padding-left: 20px');
+  });
+
+  // The shorthand-plus-override case was the worst one: the tokens carried
+  // 10px while the element painted 14px on top, so every internal compensated
+  // by the wrong amount.
+  it('lets a physical longhand override the shorthand per edge', () => {
+    const rule = ruleFor('card', {padding: '10px', paddingTop: '14px'});
+    expect(rule).toContain('--astryx-card-padding-block-start: 14px');
+    expect(rule).toContain('--astryx-card-padding-block-end: 10px');
+    expect(rule).toContain('--astryx-card-padding-inline: 10px');
+    expect(rule).not.toMatch(/[{;]\s*padding(-top)?:/);
+  });
+
+  // A `vars` entry carries one value for the whole box, so a single physical
+  // edge must not feed it — only the container expansion takes these.
+  it('does not feed a single edge to a whole-box derived var', () => {
+    const rule = ruleFor('dropdown-menu', {paddingTop: '14px'});
+    expect(rule).toContain('padding-top: 14px');
+    expect(rule).not.toContain('--_dropdown-menu-padding');
+  });
+});

package/src/theme/generateThemeRules.ts

@@ -128,6 +128,34 @@ const PADDING_PROPS = new Set([
   'paddingInlineEnd',
 ]);
 
+/**
+ * Physical block-axis longhands, and the logical longhand each one *is* in
+ * every horizontal writing mode. Normalizing them costs no direction
+ * assumption, which is why they can join the container expansion.
+ *
+ * `paddingLeft`/`paddingRight` are deliberately absent. They are
+ * direction-relative — left is inline-start in LTR and inline-end in RTL — and
+ * the expansion's tokens are consumed by logical properties, so mapping them
+ * would put the padding on the opposite edge in RTL. They keep their physical
+ * meaning and land on the element as `padding-left`/`padding-right`; the cost
+ * is that a component's internals cannot see them.
+ */
+const PHYSICAL_BLOCK_PADDING_PROPS: Record<string, string> = {
+  paddingTop: 'paddingBlockStart',
+  paddingBottom: 'paddingBlockEnd',
+};
+
+/**
+ * Every padding spelling the container expansion consumes. Kept separate from
+ * PADDING_PROPS, which also routes longhands to `vars`-style derived entries —
+ * those carry one value for the whole box, so a single physical edge must not
+ * reach them.
+ */
+const CONTAINER_PADDING_PROPS = new Set([
+  ...PADDING_PROPS,
+  ...Object.keys(PHYSICAL_BLOCK_PADDING_PROPS),
+]);
+
 interface ParsedPadding {
   blockStart?: string;
   blockEnd?: string;
@@ -138,12 +166,14 @@ interface ParsedPadding {
 
 /**
  * Parse CSS padding shorthand/longhand into block/inline values.
- * Supports 1-3 value shorthands and logical properties.
+ * Supports 1-3 value shorthands, logical properties, and the physical block
+ * longhands normalized by PHYSICAL_BLOCK_PADDING_PROPS.
  */
 function parsePadding(props: [string, string][]): ParsedPadding {
   const result: ParsedPadding = {};
 
-  for (const [prop, value] of props) {
+  for (const [rawProp, value] of props) {
+    const prop = PHYSICAL_BLOCK_PADDING_PROPS[rawProp] ?? rawProp;
     switch (prop) {
       case 'padding': {
         const parts = value.trim().split(/\s+/);
@@ -377,13 +407,28 @@ function generateComponentRules(
             }
           }
         }
+        // A physical block longhand reaches the container expansion only. It
+        // names one edge, so it must not feed a `vars` entry above, which
+        // carries the padding for the whole box.
+        if (
+          prop in PHYSICAL_BLOCK_PADDING_PROPS &&
+          getDerivedVars(component, 'padding').some(
+            e => e.expand === 'container',
+          )
+        ) {
+          containerExpanded = true;
+        }
       }
 
       // Container padding expansion: replace padding props with
       // component-scoped container tokens for layout integration.
       if (containerExpanded) {
-        const paddingProps = props.filter(([p]) => PADDING_PROPS.has(p));
-        const nonPaddingProps = props.filter(([p]) => !PADDING_PROPS.has(p));
+        const paddingProps = props.filter(([p]) =>
+          CONTAINER_PADDING_PROPS.has(p),
+        );
+        const nonPaddingProps = props.filter(
+          ([p]) => !CONTAINER_PADDING_PROPS.has(p),
+        );
         const parsed = parsePadding(paddingProps);
         const containerTokens = expandContainerPadding(component, parsed);
         finalProps = [...nonPaddingProps, ...containerTokens];

package/src/utils/plainDate.test.ts

@@ -13,6 +13,7 @@ import {
   plainDateDayOfWeek,
   plainDateAddMonths,
   plainDateAddDays,
+  plainDateDiffDays,
   plainDateToInstant,
   plainDateFromInstant,
   plainDateIsBefore,
@@ -312,6 +313,55 @@ describe('plainDateAddDays', () => {
   });
 });
 
+describe('plainDateDiffDays', () => {
+  it('counts whole days forward', () => {
+    expect(
+      plainDateDiffDays(
+        {year: 2026, month: 1, day: 10},
+        {year: 2026, month: 1, day: 17},
+      ),
+    ).toBe(7);
+  });
+
+  it('is negative when the second date is earlier', () => {
+    expect(
+      plainDateDiffDays(
+        {year: 2026, month: 1, day: 10},
+        {year: 2026, month: 1, day: 3},
+      ),
+    ).toBe(-7);
+  });
+
+  it('is zero for the same day', () => {
+    expect(
+      plainDateDiffDays(
+        {year: 2026, month: 6, day: 15},
+        {year: 2026, month: 6, day: 15},
+      ),
+    ).toBe(0);
+  });
+
+  it('counts across month and year boundaries', () => {
+    expect(
+      plainDateDiffDays(
+        {year: 2025, month: 12, day: 30},
+        {year: 2026, month: 1, day: 2},
+      ),
+    ).toBe(3);
+  });
+
+  it('ignores DST — every calendar day counts once across a spring-forward', () => {
+    // US DST 2026 begins Mar 8. The gap Mar 7 → Mar 9 is two calendar days
+    // even though one of them is 23 hours long.
+    expect(
+      plainDateDiffDays(
+        {year: 2026, month: 3, day: 7},
+        {year: 2026, month: 3, day: 9},
+      ),
+    ).toBe(2);
+  });
+});
+
 describe('plainDateToInstant / plainDateFromInstant', () => {
   it('converts a PlainDate to midnight in the requested timezone', () => {
     expect(

package/src/utils/plainDate.ts

@@ -88,6 +88,18 @@ export function plainDateAddDays(pd: PlainDate, n: number): PlainDate {
   return plainDateFromDate(d);
 }
 
+/**
+ * Whole calendar days from `a` to `b`, ignoring time of day. Positive when
+ * `b` is after `a`, negative when before. Uses UTC midnight so DST shifts
+ * never add or drop a day.
+ */
+export function plainDateDiffDays(a: PlainDate, b: PlainDate): number {
+  const msPerDay = 24 * 60 * 60 * 1000;
+  const aUTC = Date.UTC(a.year, a.month - 1, a.day);
+  const bUTC = Date.UTC(b.year, b.month - 1, b.day);
+  return Math.round((bUTC - aUTC) / msPerDay);
+}
+
 /**
  * The wall-clock fields an instant reads as in a given zone.
  *