ADR-DS-008: Spacing-system (faste breakpoints + density)

StatusBesluttet

Beslutning

Spacing bruker faste px-verdier på tre mobile-first breakpoints kombinert med et density-system (Compact/Default/Comfortable). Typografi bruker en rem-basert geometrisk skala uten density.

Faste spacing-steg per breakpoint

Spacing er faste px-verdier definert mobile-first på tre breakpoints:

• mobil (base)
• tablet (min-width: 768px)
• desktop (min-width: 1024px)

Trinnene 2xs–lg er konstante på alle breakpoints; kun xl–5xl øker på større skjermer. Tokens eksponeres som --ix-spacing-2xs til --ix-spacing-5xl.

Eksempel på Default:

Token	mobil	tablet (≥768px)	desktop (≥1024px)
--ix-spacing-md	16px	16px	16px
--ix-spacing-lg	24px	24px	24px
--ix-spacing-xl	32px	40px	48px
--ix-spacing-3xl	48px	64px	80px

Density

Density styres med data-density-attributtet (default, compact, comfortable) på et container-element, og gir hvert nivå sitt eget sett med faste px-verdier. Compact er tettere enn Default, Comfortable er luftigere.

Eksempel på --ix-spacing-md (mobil):

Compact	Default	Comfortable
12px	16px	24px

Typografi

Fontstørrelser bruker en geometrisk skala med ratio 1.125, men basen er fast 1rem og rem-basert — det betyr at brukeren kan endre fontstørrelse via nettleserinnstillinger og at typografien skalerer deretter. Trinnene er definert på .ix-body og eksponert som tokens (--ix-font-size-xs til --ix-font-size-5xl). Det finnes ingen density-nivåer og ingen breakpoint-variasjon for typografi.

Token	Verdi (base 1rem)
--ix-font-size-md	~16px (1rem)
--ix-font-size-3xl	~29px (1.125⁵ rem)

Kombinert

Density settes én gang på et container-element (data-density) og arves av alle komponenter inni.

Figma

Designere setter skjermstørrelse på frame og density for bruksområdet, og ser de beregnede verdiene direkte.

Drivere for beslutningen

• Forutsigbar layout — faste verdier per breakpoint er enklere å resonnere om enn fluid skalering
• Responsivitet uten at utviklere håndterer breakpoints manuelt (tokens bytter verdi automatisk)
• Ulike bruksområder krever fundamentalt ulik spacing (density)
• Spacing og fontstørrelse er bevisst uavhengige — brukeren kan endre font uten at layout brytes, i tråd med WCAG 1.4.4

Bakgrunn

Designsystemet brukes av team med fundamentalt ulike behov: nettbank og bedriftsløsninger trenger informasjonstett layout, mens salgssider og markedsføring trenger luft og rom. I tillegg skal komponenter automatisk tilpasse seg skjermstørrelse uten at utviklere manuelt håndterer breakpoints.

Et tradisjonelt 8px-grid løser ingen av disse problemene — det er ikke responsivt og gir ikke variasjon mellom bruksområder.

Problemstilling

Hvordan definerer vi et spacing-system som håndterer automatisk responsivitet og støtter fundamentalt ulike tetthetsbehov på tvers av bruksområder?

Konsekvenser

Hvem påvirkes?

Designere må forstå at verdiene ikke følger 8px-grid. Utviklere får automatisk responsivitet uten ekstra arbeid.

Ulemper

• Tre density-nivåer å forholde seg til (Compact, Default, Comfortable)
• Verdiene følger ikke et strengt 8px-grid på alle trinn — bevisst, men uvant for designere med 8px-bakgrunn
• Kun xl–5xl varierer per breakpoint; de mindre trinnene er konstante, noe som må kommuniseres slik at man ikke forventer at all spacing skalerer med skjermstørrelse

Tiltak mot ulemper

• Dokumentasjon forklarer systemet og hvilke trinn som varierer per breakpoint
• Figma-bibliotek gjør det enkelt å se faktiske verdier per skjermstørrelse og density

Forkastede alternativer

Fluid skalering med clamp()

Den opprinnelige implementasjonen: spacing og fontstørrelse skalerte flytende med viewport via clamp() og en calc()-basert base.

Forkastet fordi: Ga mindre forutsigbar layout — samme token kunne ha «alle» mellomverdier avhengig av viewport-bredde, noe som gjorde det vanskeligere å resonnere om og verifisere design. Faste steg per breakpoint gir designere og utviklere konkrete verdier å forholde seg til. (Density-systemet ble beholdt.)

Standard 8px-grid

Det dominerende spacing-systemet i designbransjen. Alle verdier er multipler av 8px.

Forkastet fordi: Løser ikke behovet for ulik tetthet mellom nettbank og salgssider (density). Vårt system er mobile-first per breakpoint og bruker density i stedet for et fast grid.

Kun viewport units (vw/vh)

Bruke viewport-relative enheter direkte for spacing.

Forkastet fordi: Gir ingen kontroll over minimums- og maksimumsstørrelser. Skaper tilgjengelighetsproblemer — brukere som bruker zoom vil ikke få økt spacing som forventet.

Faste steg uten density

Implementere faste breakpoint-verdier uten density-nivåer.

Forkastet fordi: Nettbank og salgssider har fundamentalt ulike tetthetsbehov som ett enkelt sett verdier ikke dekker.

Separate spacing-systemer per bruksområde

Ulike token-sett for nettbank, bedrift og markedsføring.

Forkastet fordi: Vanskelig å vedlikeholde — endringer må gjøres på tvers av systemer. Mister konsistensen som gjør at produkter fra SpareBank 1 ser ut som én familie.

Deltakere

Utarbeidet avTeam Designsystem