Drawer: support arbitrary widths + collapse closed-panel grid column

[downsDrew]

Package: @accelint/design-toolkit@9.10.0 (Drawer / DrawerLayout)

Two related, sibling issues with the same component — filing together so they can be triaged in one place.

1. size prop is locked to three pixel values

Drawer.size is typed as 'small' | 'medium' | 'large', and styles.module.css hardcodes the three widths:

--drawer-size-small: 100px;
--drawer-size-medium: 200px;
--drawer-size-large: 400px;

Tablet-class consumers (~280–320px target) have no path. Today the only options are:

• CSS-module shadow override that targets [data-component=drawer][data-size=...] selectors — couples to internal data-attribute naming, brittle.
• patches/ entry per consumer — duplicates fixes across forks.

Asks (either is sufficient):

• Widen the size prop type to accept number or a token reference (e.g. --spacing-…) alongside the three named variants.
• OR add 'tablet-medium' / 'tablet-large' to the variant set with corresponding CSS custom properties so consumers can theme them.

2. Closed-state panels still allocate their grid column

<DrawerLayout> uses grid-template-columns: auto 1fr auto to host left / main / right panels. Closed panels translate off-screen via transform: translateX(100%) (or equivalent for top/bottom/left). transform is paint-only — the grid column still allocates the panel's intrinsic content width.

Concrete impact: consumers using push='left right' see the main column visually shifted inward by ~400px (the closed large drawer's content width) even when no drawer is open. Visually this looks like "the layout treats the drawer as if it's always open."

Reproducer:

1. <DrawerLayout push='left right'> with a single right-side <Drawer size='large'> whose open is false.
2. Place a footer or any content at the bottom of the main column.
3. Observe the footer is offset inboard by ~400px when the drawer is closed.

Suggested fix (CSS sketch — not yet validated in storybook): add width: 0; overflow: hidden to the closed state, transition width with a delay equal to --animation-duration-slow so the column collapses after the slide-out animation finishes (otherwise close looks like a jarring shrink before slide):

.drawer {
  @apply bg-surface-default text-body-m pointer-events-none relative flex flex-col;

  @variant motion-safe {
    transition:
      transform var(--animation-duration-slow) var(--animation-easing-standard),
      width 0ms linear var(--animation-duration-slow);
  }

  @variant open {
    transition:
      transform var(--animation-duration-slow) var(--animation-easing-standard),
      width 0ms linear;
  }

  @variant placement-right {
    @apply col-start-3 col-end-4 row-span-full;
    transform: translateX(100%);
    width: 0;
    overflow: hidden;

    @variant open {
      transform: translateX(0);
      width: auto;
      overflow: visible;
    }
  }
}

Mirror the same pattern for placement-left (width: 0), placement-top / placement-bottom (height: 0).

Validation suggestions:

• Existing Drawer.stories.tsx with an open/closed toggle: verify open → closed → open cycle has no flicker, no content overlap during transition frames, and that sibling content reclaims the column on close.
• Test all four placements.
• Test with push='left right' consumer wiring — that's the configuration that surfaces the issue most clearly.

Happy to validate / PR either piece if useful — let me know which direction makes sense for the API.

Versions

• Next.js 16.1.6 (App Router)
• React 19.1.0 with reactStrictMode: true
• Turbopack dev mode
• pnpm 10.9 hoisted node_modules

[downsDrew]

Following up after some exploration this week — wanted to share what we observed and shift the framing toward "we hit a thing, here's what we know and don't know" rather than prescribing a fix.

What triggered the original report: When we updated to design-toolkit 9.10 + map-toolkit 4.0 around 2026-04-30, three of our Next.js consumer apps started rendering as if the right drawer were always open — main column squeezed inboard by ~400px even with no drawer mounted, footer/sibling content shifted accordingly. We landed a CSS workaround on 2026-05-01 in each consumer's src/styles/global.css:

@layer components {
  .group\/drawer[data-placement='right']:not([data-open]),
  .group\/drawer[data-placement='left']:not([data-open]) {
    width: 0;
  }
  .group\/drawer[data-placement='top']:not([data-open]),
  .group\/drawer[data-placement='bottom']:not([data-open]) {
    height: 0;
  }
}

Force-collapses the closed drawer's intrinsic width so the auto-sized grid track collapses with it. Resolved the symptom; comment in the file says "drop when upstream lands the toolkit-side fix."

Where we're less sure: While exploring this before commenting, we tried reproducing against your storybook and the wagon-wheel recipe at coreux-recipes.accelint.dev/?path=/story/shapes-wagon-wheel--default. Wagon-wheel correctly shows grid-template-columns: 0px <main> 0px when the drawer is closed and 0px <main> 400px when open — full main width when closed, exactly what consumers want. So whatever's happening in our apps isn't a universal toolkit issue.

We initially thought class-hash differences (_layout_oy4q7_2 vs _layout_k6ani vs styles_layout__jZLMr) meant different CSS source; we now understand those are compilation artifacts of the same source built per-consumer. So we don't actually know what's different between our consumer setup and the recipe's that produces this behavior — could be rendered DOM children inside the drawer, prop pattern, React state, or something else we're holding wrong. We're using <DrawerLayout push='left right'> with <Drawer placement='right' size='large'> containing an entity-detail panel.

The honest ask: we hit a real symptom in three consumer apps and a workaround unblocked it, but we don't have the toolkit-internal context to diagnose the root cause confidently. Your investigation into what's different between our pattern and the recipe pattern would be more valuable than our prescription — and would let us drop the workaround once we understand it.

Forward-looking observation (not a request): as more AI agents and external consumers interact with the toolkit, we noticed the gap between "what the public source code shows" and "what the toolkit team knows about correct usage patterns" comes up. Things like why wagon-wheel's drawer correctly collapses while a raw DOM toggle in your default storybook story behaves differently, or what determines the panel's intrinsic width contribution to the grid track — that context is currently in human heads or transmitted through recipe-by-osmosis. Surfacing more of that in storybook docs / component JSDoc would meaningfully help AI and external consumers reason about these interactions without reverse-engineering from runtime measurements. (Sharing as one consumer's perspective, not pushing for action on this issue.)

Part-1 of the original issue (arbitrary drawer widths) is independent of all this — separate ergonomic FR around the 'small' | 'medium' | 'large' enum, unaffected by the closed-state question.