# Responsiv design
## Hva det er
Responsiv design er praksisen med å bygge én side der oppsettet tilpasser seg
skjermen den leses på, fra en smal telefon holdt på høykant til en bred skjerm
på et skrivebord, i stedet for å bygge et eget nettsted for hver type enhet. Den
lengre formen, responsiv webdesign, svarer til tittelen på artikkelen som ga
fenomenet navn: Ethan Marcottes Responsive Web Design, publisert 25. mai 2010 i
A List Apart. Han hentet ideen fra det han beskrev som en framvoksende disiplin
kalt responsiv arkitektur, der vegger og installasjoner bøyer seg, gir etter og
utvider seg når folk nærmer seg dem.
Marcotte kalte flytende grid, fleksible bilder og media queries «the three
technical ingredients for responsive web design». Et flytende grid gir kolonnene
bredder i forhold til plassen som er tilgjengelig, i stedet for i faste piksler,
slik at oppsettet strekker seg og trekker seg sammen med vinduet. Et fleksibelt
bilde får aldri bli bredere enn kolonnen det står i. En media query lar et
stilark ombestemme seg der forholdstall alene slutter å virke: når tre kolonner
blir for smale til å lese, går siden for eksempel over til én.
Spesifikasjonen Media Queries Level 4, et W3C Candidate Recommendation Draft
datert 19. februar 2026, definerer en media query som et logisk uttrykk som
enten er sant eller usant, en test av en eller annen side ved nettleseren eller
enheten som viser dokumentet. Testen responsive oppsett lener seg på, er
`width`, som for en skjerm er bredden på viewporten, rullefeltet medregnet.
Lengder i en query er de samme CSS-lengdene som overalt ellers, så en piksel er
her en CSS-piksel, ikke en fysisk, og `em` måles fra nettleserens opprinnelige
skriftstørrelse, som leseren selv kan endre, aldri fra en størrelse siden selv
setter.
Ingenting av dette virker på en telefon med mindre siden ber om det. Uten et
viewport-metaelement legger mobilnettlesere opp siden som om skjermen var et
skrivebordsvindu, typisk 980 til 1024 CSS-piksler bredt, og skalerer så
resultatet ned, slik at alle media queries ser en stor skjerm. CSS
Viewport-utkastet kaller det et tiltak for sider som bare er laget for store
skjermer, unødvendig for sider som fungerer godt på små, og linjen
`width=device-width, initial-scale=1` i eksempelet nedenfor er måten en side
sier at den er en av dem på.
## Hvorfor det er viktig
Marcottes argument handlet like mye om vedlikehold som om utseende. I stedet for
å skreddersy frakoblede design til et stadig voksende antall enheter foreslo han
å behandle dem som fasetter av den samme opplevelsen. Én side, én adresse og ett
stilark betyr at en rettelse når alle lesere samtidig, og at en ny
skjermstørrelse ikke krever et nytt nettsted, fordi oppsettet aldri ble skrevet
for en bestemt størrelse.
Zoom er grunnen mange team undervurderer. Når man zoomer inn, blir CSS-pikselen
større, så viewporten, målt i CSS-piksler, blir smalere. Web Content
Accessibility Guidelines 2.2, en W3C-anbefaling siden 12. desember 2024, krever
på nivå AA i suksesskriterium 1.4.10 Reflow at innhold kan brukes uten rulling i
to retninger ved en bredde tilsvarende 320 CSS-piksler, og retningslinjene sier
selv at det er dette et vindu på 1280 CSS-piksler blir ved 400 prosent zoom. For
alle media queries på siden sitter en leser som zoomer nettleseren på en bærbar
til 400 prosent, foran en skjerm på 320 piksler. W3Cs forklaring av kriteriet
påpeker at nettsteder ofte bruker responsiv design for å passe til mindre
viewporter, og at innhold som passer i en liten viewport, hjelper folk som
zoomer inn på større enheter, ikke bare folk med telefoner.
Datamengden er den tredje grunnen. HTML-standarden nevner tre ulike grunner til
å tilby flere filer for ett bilde: valg etter viewport, art direction og valg
etter bildeformat. Et fotografi som fyller bredden på en telefon, trenger langt
færre piksler enn det samme fotografiet over hele bredden på en stor skjerm, og
med `srcset` og `sizes` kan nettleseren hente den mindre filen uten noe skript.
Bredden er ikke det eneste en side kan reagere på. Media Queries Level 4
beskriver også den primære pekeenheten: `(pointer: coarse)` treffer en pekeenhet
med begrenset presisjon, for eksempel en berøringsskjerm, og `(hover: none)`
treffer en primær pekeenhet som ikke kan holdes over et element, eller ingen
pekeenhet i det hele tatt. Marcottes artikkel foreslo allerede å bruke media
queries til å gi lenker større mål å treffe på små skjermer.
## Slik ser det ut i praksis
En liste med kort som viser én kolonne på en telefon, to på et nettbrett på
tvers og tre på en bred skjerm, begynner med viewport-linjen og et bilde
nettleseren selv kan velge:
```html
```
Stilarket bærer oppsettet:
```css
.cards {
display: grid;
grid-template-columns: 1fr;
gap: 1rem;
}
@media (width >= 40em) {
.cards {
grid-template-columns: repeat(2, 1fr);
}
}
@media (width >= 64em) {
.cards {
grid-template-columns: repeat(3, 1fr);
}
}
.cards img {
max-width: 100%;
height: auto;
}
```
Gridet er den flytende delen: kolonner på `1fr` deler den bredden som finnes, så
ingenting har en fast størrelse. De to media queries er bryterne, og fordi de er
skrevet i `em`, følger de leserens standard skriftstørrelse. En leser som har
valgt en større standardskrift, får den ene kolonnen ved vindusbredder der andre
allerede ser to, og det er nettopp det de lengre linjene ville trenge. Den siste
regelen holder hvert bilde inne i kolonnen sin.
Attributtet `sizes` forteller nettleseren, før den har lagt opp noe, hvor bredt
bildet skal vises: den første betingelsen som er sann, vinner, og den siste
verdien gjelder når ingen er det. Ved en viewport på 39em er den første
betingelsen sann, så bildet regnes som 39em bredt; ved 41em er det den andre, og
bildet regnes som halve viewporten, 20,5em. Det litt bredere vinduet trenger den
mindre filen, fordi oppsettet har endret seg, og HTML-standarden går gjennom den
samme effekten i sitt eget eksempel. Ut fra disse tallene og `w`-angivelsene i
`srcset` regner nettleseren ut hvilken pikseltetthet hver fil ville gi på denne
skjermen, og den kan velge hvilken som helst av dem ut fra skjermens
pikseltetthet, zoomnivået og muligens nettverket. Attributtene `width` og
`height` lar den sette av plass til bildet før filen er lastet ned.
[En porteføljeside om å gjøre nettstedets nettlesersjekker raskere](/nb/portfolio/a-safety-net-that-no-longer-costs-half-an-hour/)
viser den samme ideen omsatt til en test. I arbeidet fra august 2026 fikk
sjekkene som styrer en hodeløs nettleser, én felles viewport-tabell med tjueto
vindusformer, utledet fra hver media query stilarket faktisk inneholder, og
layoutsjekken, som ser på siden ved hver vindusform designet tegner opp, gikk
derfor fra 95 sekunder til 405. Formene kommer fra stilarket, ikke fra en liste
over enheter, så det er de bruddpunktene designet faktisk har, sidene blir
sjekket ved.
## Hvor det går galt
**Bruddpunkter som spør etter enheten.** Marcottes eksempler fra 2010 brukte
`max-device-width`, bredden på hele skjermen. Media Queries Level 4 erklærer nå
`device-width`, `device-height` og `device-aspect-ratio` foreldet, sier at
forfattere ikke må bruke dem, og påpeker at de ofte brukes som en stedfortreder
for å oppdage mobile enheter, selv om de ikke sier noe om hvor mye plass siden
faktisk har. Spør heller etter `width`, og legg hvert bruddpunkt der innholdet
slutter å fungere, ikke der en populær telefon tilfeldigvis slutter.
**Et hull mellom to bruddpunkter.** Et stilark med `(max-width: 320px)` for ett
oppsett og `(min-width: 321px)` for det neste ser komplett ut, men
spesifikasjonen påpeker at en viewport mellom 320 og 321 piksler bred treffer
ingen av dem, og brøkdeler av piksler forekommer: de kommer fra skjermer med
pikseltettheter som ikke er hele tall, og fra zoom. Ved de breddene gjelder
ingen av de to blokkene. Bruk intervallsyntaksen, `(width <= 320px)` og
`(width > 320px)`, slik at hver bredde havner i nøyaktig én av dem.
**Zoom slått av.** En viewport-linje med `user-scalable=no` eller med en
`maximum-scale` under 2 stryker i W3Cs testregel for suksesskriterium 1.4.4
Resize Text, som krever at tekst kan forstørres til 200 prosent. Regelen påpeker
at skrivebordsnettlesere ignorerer elementet, og at de fleste moderne
mobilnettlesere enten ignorerer det som standard eller tilbyr en
tilgjengelighetsinnstilling som tillater zoom likevel, slik at bare lesere med
eldre mobilnettlesere fortsatt rammes. Utelat begge egenskapene, og få heller
oppsettet til å tåle zoom. En mindre skrift i et smalt bruddpunkt krever samme
omtanke: W3Cs forklaring av Reflow tillater det, men bare hvis leseren fortsatt
på en eller annen måte kan få teksten opp i dobbel normal størrelse.
**Bilder som overser oppsettet.** Med `w`-angivelser i `srcset` og ingen `sizes`
lar HTML-standarden nettleseren gå ut fra at bildet fyller hele viewporten, så
et bilde som vises i en tredjedel av skjermen, kan laste ned en fil omtrent tre
ganger bredere enn nødvendig. Prosenter er ikke tillatt i `sizes`; bruk `vw`. Og
når `srcset` bruker `w`-angivelser, ignorerer nettlesere som forstår `srcset`,
attributtet `src`, så en endring av bare `src` endrer ingenting for de fleste
lesere. Skriv `sizes` slik at det stemmer med CSS-en, og endre begge samtidig
når oppsettet endres. Å velge bilder med et skript er ingen løsning: standarden
advarer om at bildet da kan bli lastet ned to ganger, eller ikke i det hele tatt
for lesere som har slått av skript.
**Ett bredt element får hele siden til å rulle sidelengs.** En datatabell, en
lang kodelinje eller en innbygging med fast bredde kan være bredere enn 320
CSS-piksler og få hele siden til å rulle sidelengs, slik at hvert avsnitt må
leses ved å rulle fram og tilbake. W3Cs forklaring av Reflow unntar innhold som
trenger to dimensjoner, for eksempel datatabeller, kart og video, men ikke
avsnittene rundt det. Legg tabellen i en egen beholder som ruller for seg selv
med `overflow-x: auto`, og gi bilder og video `max-width: 100%`, slik at bare
den delen som trenger det, ruller.
**Å ta en smal skjerm for en berøringsskjerm.** En bærbar som er zoomet til 400
prosent, er smal og har en mus; et stort nettbrett er bredt og har ingen hover i
det hele tatt. Oppsettet hører til `width`, mens målstørrelser og hovereffekter
hører til `pointer` og `hover`. Media Queries Level 4 råder forfattere til også
å vurdere `any-pointer` og `any-hover`, fordi en enhet kan ha mer enn én måte å
peke på.
## Les mer
- [Responsive Web Design](https://alistapart.com/article/responsive-web-design/)
— Ethan Marcottes artikkel fra 25. mai 2010, som ga tilnærmingen navn og
beskrev de tre ingrediensene.
- [Media Queries Level 4](https://www.w3.org/TR/mediaqueries-4/)
— `width`-egenskapen, intervallsyntaksen, relative enheter, pointer og hover,
og hvorfor `device-width` er foreldet.
- [HTML Standard: Images](https://html.spec.whatwg.org/multipage/images.html)
— `srcset`, `sizes`, de tre grunnene til flere filer og det gjennomregnede
eksempelet med 29em og 32em.
- [Understanding Success Criterion 1.4.10: Reflow](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html)
— hvorfor 320 CSS-piksler, hvordan zoom henger sammen med det, og hvilket
innhold som er unntatt.
- [Meta viewport allows for zoom](https://www.w3.org/WAI/standards-guidelines/act/rules/b4f0c3/)
— W3Cs testregel for `user-scalable` og `maximum-scale`, med merknaden om
nettleserstøtte.
- [CSS Viewport Module Level 1](https://www.w3.org/TR/css-viewport-1/)
— viewport-metaelementet, egenskapene, og hvorfor mobilnettlesere går ut fra
en skrivebordsbredde.