Personal Research

ibm-carbon

4 min read

IBM Carbon

1. Why this system is relevant

Carbon supports high-density product UI and more expressive web/editorial experiences without exposing one global “density mode.” It is useful precisely because it solves the boundary through component sizes plus task/region-specific typography strategies. The same Button, TextInput, and DataTable retain their identity while choosing explicit sizes.

2. Density terminology

Carbon uses productive and expressive for typography and interaction moments, and named component sizes such as extra small through 2XL. It does not present these as a single global compact/comfortable density scale. Data table and control documentation speaks in row/control sizes. Type sets Typography strategies

3. Density model

  • Density is primarily component-specific: consumers select a size for Button, TextInput, and DataTable.
  • Productive and expressive type strategies may coexist across page regions or tasks, but Carbon says type styles should remain consistent within a discrete task, component, or region.
  • There is no evidence of a context provider or token mode that automatically changes every descendant component’s geometry.
  • Coexistence is straightforward because size is passed per component; consistency must be governed compositionally rather than inherited globally.

4. Token architecture

The implementation path is:

component size prop → size modifier class → Carbon layout/spacing/type tokens → rendered component

Component Sass uses Carbon’s shared layout sizing utilities and spacing tokens, but selects concrete maps/classes by component size. Productive/expressive typography tokens form a parallel semantic type layer. This is a governed component system with explicit variants rather than theme-level density aliases.

ComponentPublic sizes and metrics
Buttonextra small 24px; small 32px; medium 40px; large productive 48px; large expressive 48px; XL 64px; 2XL 80px
Text inputsource supports xs, sm, md, lg; documented form guidance commonly uses 32/40/48px for small/medium/large
Data table rowxs 24px; sm 32px; md 40px; lg 48px; xl 64px

The button Sass uses layout.use('size', $min: 'xs', $default: 'lg', $max: '2xl'). Data-table CSS has explicit row modifier classes and 24/32/40/48/64px geometry. Shared spacing tokens are selected by each component rather than globally revalued. Button styles Data-table styles _button.scss _data-table.scss

6. Typography behaviour

Carbon explicitly distinguishes productive and expressive type. Productive UI has a 14px base and fixed headings suited to dense product layouts; expressive moments use a 16px base and more fluid headings for web/editorial pages. Size variants can also alter a component’s typography, but there is no rule that every smaller control switches the entire surrounding type ramp. Type sets

7. Representative component examples

  • Button: React accepts size="xs|sm|md|lg|xl|2xl"; isExpressive applies only to the large/default context. Action kind (primary, secondary, danger, etc.) remains orthogonal.
  • Text input: React accepts size="xs|sm|md|lg"; the same field semantics receive a size class.
  • Data table: <Table size="xs|sm|md|lg|xl"> propagates row height. The header should match row size; XL supports two lines.
  • Cards/dialogs/navigation: these do not inherit a universal density. Their layout is composed from component and spacing choices appropriate to the region.

Button.tsx TextInput.tsx Table.tsx

8. Design/Figma implementation

Carbon publishes Figma kits in which component configurations are selected as variant properties. Public Carbon guidance also discusses Figma modes for themes, but no evidence was found that component density is a global Figma variable mode. The verifiable mechanism for these examples is component variants/properties. Designing with Carbon

9. Code implementation

<Button kind="primary" size="lg">Continue</Button>
<Button kind="primary" size="sm">Continue</Button>
<TextInput id="name" labelText="Name" size="sm" />
<Table size="xs">…</Table>

Semantic kind and component identity stay stable; the explicit size prop changes the modifier class and resolved metrics. There is no required global theme switch.

10. Accessibility constraints

Carbon’s smallest rows and controls can be 24px, so a dense selection does not automatically meet a 44px touch recommendation. Carbon icon guidance recommends 44px interactive touch targets and allows padding to make the target larger than the icon. Data tables retain keyboard interaction and should keep header/row sizes aligned; responsive behavior is a separate concern. Carbon icon usage WCAG target minimum

11. Limitations / unavailable evidence

  • Productive/expressive is a typography/content strategy, not a synonym for compact/comfortable component density.
  • Current Carbon v11 blends parts of the historical type sets; the public documentation still preserves productive/expressive use-case distinctions.
  • Exact internal Figma-library construction is not public enough to map every code size to a specific authoring variable.
  • Because density is not inherited, system-level consistency depends on composition guidance and product decisions.

Graph View

Backlinks