feat: ✨ add sd-drawer

[mariohamann]

Description

Drawers slide in from a container to expose additional options and information.

https://shoelace.style/components/drawer

API

Coming from https://github.com/solid-design-system/figma/issues/54#issue-1811521181
https://www.figma.com/file/HHBbD5kdSWjiD8H1lA8jHf/Drawer?type=design&node-id=0-1&mode=design&t=0SAKc9ip7D2bSSNT-11

Overview

Props

Slots

Hand-off

https://www.figma.com/file/yN3BI0cWA3AlcrKWEpBIP5/Drawer?type=design&node-id=1103-913&mode=design&t=Ck5DjbhRklpiyyuc-11

Components detailed requirements

• Proceed with this branch: https://github.com/solid-design-system/solid/tree/feat/sd-drawer
• Props
  • open
  • label (behavior tbd see "open questions")
  • placement (left, right)
  • contained prop (only for testing purposes)
• CSS-Properties
  • --width (width of the drawer and NOT the overlay)
  • remove all shoelace properties
• Slots
  • default (no name)
  • header
  • footer
• Stories
  • open (a button should be provided to open)
  • slots
  • scrolling → to show that big content doesn't make the element bigger)
  • Mouseless interactive story
  • Initial focus (https://shoelace.style/components/drawer#customizing-initial-focus)
• Parts
  • same as Shoelace but change header-actions to e. g. header-content
• Migration guide

// ui-offcanvas-panel
  @Prop({ reflect: true, mutable: true }) open: boolean;

  @Prop({ reflect: true }) darken: boolean; // this won't be provided any more 

  @Prop() position: 'left' | 'right' = 'left';

  @Prop() activeBelow: number; // → placement

  @Prop() closeOutside: boolean; // this won't be provided 

  @Event() offcanvasTrigger: EventEmitter<{id: string}>; // this won't be provided any more 
// ui-offcanvas-trigger
// -> not needed anymore, just trigger with methods

// ui-offcanvas-provider
// → not needed anymore

Technical Information

• feat: ✨ add sd-scrollable #289 is still not ready but not blocking the sd-drawer => just make it scrollable without any indicator

open questions

• what about the label? is it required? only for screen readers?
• what with the initial focus? shouldnt it be inside the drawer? @coraliefeil can you ask your A11y contact about the expected behavior?

DoR

• Item has business value
• Item has been estimated by the team
• Item is clear and well-defined
• Item dependencies have been identified

DoD

• Documentation has been created/updated (if applicable)
• Migration Guide has been created/updated (if applicable)
• Relevant E2E tests (Features, A11y, Bug fixes) are created/updated
• Relevant stories (Features, A11y) are created/updated
• Implementation works successfully on feature branch

[coraliefeil]

@azraefendic
It is advisable to jump directly to the first element (This is expected behaviour usability-wise.). You just have to weigh it against the effort. But it is not a barrier as long as you can focus into the drawer.

[van-nguyen-ht]

@azraefendic @mariohamann
Hi guys, I've updated the documentation per discussed. To achieve negative margin for the button, the left padding is left empty while an extra padding can be turn on/off depending on either a button is used in the Header slot or not.

Here's the current build

[coraliefeil]

Got this answer from my dev colleague:

Depends on label and function. Basically, it is never wrong to provide information. In case of doubt, this has to be done via ARIA, but usually the label is somehow missing in the "normal" UX.

@karlbaumhauer @mariohamann FYI