Decide on open design proposals

[pepijngieles]

Decide on open design proposals

Let's go through the list together, and per item decide do, don't, or park. Tick the box once a decision is made, and note the outcome in a comment. When an item becomes real work, split it back out into its own issue and link it here. The original issues are closed as duplicates of this one.

Color and tokens

• Add a --secondary-strong token (--secondary-strong als token toevoegen? #114)
  Investigate whether a stronger variant of secondary is needed, and if so how to define it in the token set. Currently unclear what the concrete use case is, so start there.

• Change default focus style from grey to blue (Change default focus style from grey to blue #131)
  Focus rings are grey, which reads as low priority and is easy to miss when tabbing through a form. Blue matches the interaction colour used elsewhere. Contrast needs checking on all surfaces, including muted and destructive backgrounds.

• Add signal colors to Badge (Add signal colors to Badge component #138)
  Badge has no success, warning or info variant, so status is now communicated with custom colours outside the system. Reuse the existing destructive and warning tokens and add what is missing, with the same opacity approach.

• Use a blue signal color for the Highlight variant of Alert (Use a blue signal color for Highlight variant of Alert #142)
  Highlight is based on --primary, which breaks down when primary is a non-informational colour such as green. A dedicated blue info token keeps the meaning intact regardless of theme, set up like the destructive and warning tokens.

Dialog

• Support multiple widths for Dialog (Support multiple widths for Dialog #133)
  One fixed width is too narrow for content-heavy dialogs and too wide for short confirmations. Define a small set of named sizes rather than free-form widths, so the choice stays a design decision instead of a one-off override.

• Add a leading icon slot to the Dialog header (Add a leading icon slot to the Dialog header #132)
  An icon next to the title can signal intent, for example a warning or success state. Needs a decision on alignment relative to the title and behaviour when the title wraps to two lines.

• Investigate inconsistent heading font sizes in Dialog and Alert Dialog (Investigate inconsistent heading font sizes in Dialog and Alert Dialog #134)
  Heading sizes differ between the two in Figma without an obvious reason. Find out whether this is intentional, inherited from the shadcn kit, or drift, and align with the type scale unless there is a reason to keep them apart.

• Align Dialog footer background color between Figma and dev (Align Dialog footer background color between Figma and Dev #135)
  The footer has a background colour on one side and not on the other. Decide which is correct and update the other side.

Forms and controls

• Align Select height with the other controls (Align Select height (40px) with other controls (36px) or the other way around #139)
  Select is 40px while Input, Button and the rest are 36px, which shows as soon as they sit next to each other in a form row. Decide which height becomes the standard and apply it everywhere.

• Move the form field description between label and field (Move form field description between label and field #141)
  The description now sits below the field, where it is only read after the input has been filled in. Placing it between label and field means it is read before typing starts and stays visible when a mobile keyboard or autocomplete menu pops up. Error messages stay below the field, so check the consequences there.

• Define a loading state pattern for entire forms and dialogs (Define loading state pattern for entire forms and dialogs #137)
  There is no agreed pattern for what happens while a whole form or dialog is submitting. Decide where the spinner lives (submit button, header, or overlay), whether everything gets disabled, and how to avoid layout shift. Document it as a pattern rather than solving it per component.

• Evaluate adding counts to Checkbox for filter use cases (Evaluate adding counts to Checkbox for filter use cases #140)
  Filter lists commonly show the number of matching results per option. Decide whether this belongs in Checkbox, in a separate filter pattern, or stays a composition the consumer builds, and what happens when a count is loading or zero.

• InputOTP: support filled combined with a second state in Figma (InputOTP: support filled combined with a second state in Figma #136)
  Filled cannot be combined with focus or error in Figma, so those combinations cannot be shown in a design. Fixing it means restructuring the variant properties so filled becomes an independent boolean. Weigh the effort against how often the combinations are actually needed.

• Checkbox line-height: none breaks multi-line labels (Checkbox line-height:none doesn't work for multi line labels #143)
  With line-height: none the label no longer aligns correctly once it wraps to a second line. Decide on the right line-height for the label and how the checkbox aligns to the first line of text.

Layout

• Add a condensed list variant without spacing between items (Add a condensed list variant without spacing between items #130)
  Item Group adds spacing between items, which works for scannable overviews but wastes vertical space in dense contexts. Add a variant where items sit directly against each other, and decide whether this becomes a prop on Item Group or a separate component.