Introduktion
Et breakpoint er en betingelse i et responsivt webdesign, hvor layoutet ændrer sig. Det er ofte en bestemt bredde på browserens visningsområde. Når bredden passerer punktet, kan kolonner blive stablet, menuen skifte form, typografien justeres eller elementer flyttes.
Breakpoints bruges som en del af responsivt design. De gør det muligt at tilpasse samme HTML-indhold til mobil, tablet, bærbar og store skærme. Et breakpoint er altså ikke en separat mobilside. Det er et sted, hvor de gældende layoutregler ændres.
Et typisk CSS-eksempel er en media query som @media (min-width: 768px). Reglerne inde i blokken gælder, når visningsområdet er mindst 768 pixels bredt. Tallet er ikke en universel tabletgrænse. Det er blot den værdi, designeren har valgt for det konkrete layout.
Breakpoints hænger tæt sammen med mobile-first. Ved en mobile-first tilgang starter CSS med den smalle visning og tilføjer mere plads eller flere kolonner ved minimumsbredder. En desktop-first løsning gør ofte det modsatte og forenkler layoutet ved maksimumsbredder.
Et godt breakpoint vælges, fordi indholdet har brug for det. Hvis tre produktkort bliver klemt, en overskrift får en grim ombrydning, eller navigationen ikke længere kan være på én linje, er der en konkret grund til at ændre layoutet. En liste over populære enheder er et dårligere udgangspunkt, fordi skærmstørrelser ændrer sig.
Sådan bruger du det i praksis
Byg først et fleksibelt grundlayout med procentbredder, grid, flexbox, flydende billeder og fornuftige maksimumsbredder. Træk derefter browservinduet langsomt smallere og bredere. Tilføj et breakpoint dér, hvor indholdet ikke længere fungerer, i stedet for at starte med fem tilfældige tal.
Hold antallet begrænset. Et projekt kan sagtens have tre eller fire hovedbreakpoints og enkelte komponentbaserede undtagelser. Hvis hver sektion har syv egne bredder, bliver løsningen vanskelig at forstå og vedligeholde. Ofte kan et bedre grid eller clamp() fjerne behovet for ekstra regler.
Test de bredder, der ligger mellem de kendte enheder. Et design kan se fint ud på 375 pixels og 1440 pixels, men falde fra hinanden ved 820 eller 1100. Browserens responsive værktøjer er gode, men brug også rigtige telefoner og tablets, når centrale funktioner skal godkendes.
Tænk på indholdets rækkefølge. Når to kolonner bliver til én, skal den vigtigste information stadig komme først. CSS kan flytte elementer visuelt, men skærmlæsere og tastaturnavigation følger ofte dokumentets rækkefølge. Derfor hænger breakpoints også sammen med webtilgængelighed.
Kontrollér navigation, formularer, tabeller, kort, popups og hero-sektioner separat. Det er ofte komponenterne, der afslører problemerne, ikke den almindelige brødtekst. En tabel kan kræve vandret scroll, mens en formular måske blot skal gå fra to kolonner til én.
Dokumentér breakpoint-værdierne i projektets designsystem eller CSS-variabler, hvis teknologien tillader det. Navne som small, medium og large er lettere at genbruge end tilfældige værdier spredt over mange filer.
Eksempel
En forside har tre servicekort i samme række. Ved 1440 pixels er hvert kort 360 pixels bredt. Ved 900 pixels bliver de cirka 260 pixels, og overskrifterne bryder over tre linjer. Ved 760 pixels er knapperne presset helt ud mod kanten.
Designeren kunne tilføje regler ved 1200, 1100, 1000, 900 og 800 pixels. I stedet ændres grid’et, så det automatisk fordeler kort med en minimumsbredde på 280 pixels. Der tilføjes ét breakpoint, hvor tre kolonner naturligt bliver til to, og et andet hvor to bliver til én.
Resultatet fungerer på flere mellemstørrelser uden særregler. Ved 1024 pixels vises to kort øverst og ét nedenunder. Det er måske ikke perfekt symmetri, men det er læsbart og stabilt. Indholdet bestemmer skiftet, ikke navnet på en enhed.
På en webshop kan produktgitteret bruge samme princip, mens filtrene får et særskilt breakpoint. På store skærme står de i venstre side. Når de begynder at tage for meget plads, bliver de samlet i en tydelig filterknap. Ændringen sker, når den praktiske balance tipper.
Efter implementeringen testes både visning og hastighed. Breakpoints kan få browseren til at hente forskellige billeder, men dårlig opsætning kan stadig sende en billedfil på 2.400 pixels til mobilen. Derfor kontrolleres også billedkomprimering og responsive billedstørrelser.
Faldgrube
Den klassiske fejl er at kalde breakpoints “iPhone”, “iPad” og “desktop”. Enheder findes i mange bredder, kan roteres, og browseren kan ligge i et delt vindue. Navngiv værdierne efter layoutets behov, ikke efter et produkt, der snart bliver afløst.
En anden fejl er at skjule vigtigt indhold på små skærme, fordi det er besværligt at placere. Mobilbrugeren har ikke nødvendigvis mindre behov for pris, vilkår eller kontakt. Layoutet skal prioritere og omforme indholdet, ikke blot fjerne det.
Pas også på breakpoint-jagt. Når en enkelt overskrift ombryder grimt, kan løsningen være en kortere formulering, en mere passende bredde eller fleksibel typografi. En ny media query er ikke altid det mest robuste svar.
Endelig kan CSS-regler overlappe og skabe overraskelser. En regel ved 768 pixels bliver måske overskrevet af en senere regel ved 720 pixels. Hold rækkefølge, specificitet og navngivning enkel, og fjern gamle nødløsninger, når komponenten bliver bygget om.
Godt at vide
Media queries kan reagere på mere end bredde. De kan blandt andet tage højde for orientering, inputtype, reduceret bevægelse og farvetema. Ikke alle disse betingelser kaldes breakpoints i daglig tale, men de bruger samme idé: designet tilpasser sig en egenskab ved brugerens miljø.
Container queries gør det muligt at tilpasse en komponent efter den plads, dens beholder har, frem for hele browserens bredde. Det er nyttigt i designsystemer, hvor samme kort kan ligge i både en bred hovedkolonne og en smal sidebar.
Et breakpoint påvirker ikke automatisk Core Web Vitals, men et tungt eller ustabilt responsivt design kan. Store billeder, layoutskift og skjulte komponenter, der stadig indlæses, kan gøre mobiloplevelsen langsom.
Brug ikke kun screenshots til test. Klik menuen, udfyld formularen, åbn fejlbeskeder og zoom teksten. Layoutet kan se pænt ud og stadig være svært at bruge. Det er funktionerne mellem breakpoints, der afgør kvaliteten.
Vores guide om brugervenlige hjemmesider går videre end skærmbredder. Et responsivt layout skal understøtte en klar vej, men indhold, prioritering og microcopy skal også være på plads.
Browserzoom og større tekst kan få layoutet til at ramme et breakpoint tidligere eller skabe problemer mellem de planlagte værdier. Test derfor med 200 procent zoom og ændrede tekstindstillinger. En løsning, der kun fungerer med præcis standardtypografi, er ikke særligt robust.
Indhold på flere sprog kan også ændre behovet. En kort dansk knap kan blive betydeligt længere på tysk eller fransk. Breakpoints bør ikke skjule oversættelsesproblemet; komponenterne skal kunne rumme realistisk tekst eller have regler for forsvarlig ombrydning.
Når et design ændres, bør gamle media queries ryddes op. Det er almindeligt, at fem års rettelser ligger oven på hinanden, så ingen ved, hvilken regel der vinder. En komponentvis gennemgang kan reducere CSS-mængden og gøre næste justering langt mindre risikabel.
Notér hvilke komponenter et hovedbreakpoint påvirker. Det gør det lettere at kontrollere konsekvenserne, når værdien ændres. At flytte grænsen fra 768 til 800 pixels kan se harmløst ud, men påvirke menu, produktgrid, formular og footer på samme tid.
Overvej også pointer-enheder. En bred tablet med touch har ikke samme præcision som en bærbar med mus, selv om bredden ligner. Media features som hover og pointer kan bruges til at tilpasse interaktioner, men grundfunktionen bør stadig virke uden hover.
Print er et andet miljø, hvor layoutregler kan skifte. En print media query kan fjerne navigation, vise linkadresser og tilpasse bredder til papir. Det er ikke et almindeligt skærmbreakpoint, men viser at responsivitet handler om mediet, ikke kun mobil kontra desktop.
Den almindelige hjemmeside og webshoppen kan bruge de samme grundprincipper, men komponenterne er forskellige. Produktfiltre, kurv og tabeller presser ofte layoutet tidligere end en enkel serviceside.
Senest opdateret