Når du utformer en nettside, særlig dens hero-seksjon, står du overfor et vanlig dilemma:
Hvordan sikre at innholdet strekkes til hele skjermhøyden på alle enheter?
Du har kanskje prøvd ut 100vh (viewport height) for å fylle skjermen. Dette fungerer supert på desktop, men som du sikkert har oppdaga, så er det ikke rett frem på mobil — adressefeltet forstyrrer en perfekt layout.
Kanskje de nye, kule CSS-størrelsene svh, lvh og dvh kan løse problemet?
svh, dvh og lvh
svh (small viewport height) gir en størrelse som er det minste versjonen av skjermen, altså med adressefelt. Dermed er denne perfekt til en hero-seksjon, hvor du kan forvente at en person kommer inn fra en annen side, og fortsatt har adressefeltet åpent.
Motsatsen til svh, er lvh (large viewport height). Den antar at adressefeltet ikke er synlig, og vil dermed ta størst mulig plass. I praksis er dette helt likt vh.
dvh kan se ut til å være det beste fra to verdener: Den sjekker om adressefeltet er vist eller ikke, og vil dermed få størrelsen til svh eller lvh.
Dette høres jo gull ut, men har også en nedside. Siden den beregner størrelse idet du slipper scrollen, kan du få uønskelige layout-shifts ved scrolling. En annen ting er at dvh beregner størrelse, og kan derfor kreve mer ytelse.
– Det suverent beste fargeverktøyet!
Så hva skal du velge?
Hva er konklusjonen — skal du alltid gå for svh?
Ved hero-seksjoner, elementer som er på toppen av visningen, kan det gi mening å bruke svh, siden adressefeltet mest sannsynlig fortsatt er åpent.
Men i min erfaring er ikke dette nødvendigvis rett for andre elementer. For eksempel ville jeg lage en fullskjerm-modal, og med 100svh så alt bra ut mens adressefeltet var der. Men da jeg scrollet oppover, var ikke lenger adressefeltet der, og det dukket opp et uønsket mellomrom.
Jeg prøvde igjen med 100vh, og aksepterte overflow ved synlig adressefelt. Men så oppdaget jeg at 100vh ikke nødvendigvis oppfører seg på forventet måte i Safari iOS, se for eksempel Matt Smiths artikkel her.
Jeg ble ikke overbevist da jeg så at noen av løsningene fikk det til å fungere på Safari, men introduserte feil på Chrome. Jeg var heller ikke ivrig etter å beregne adressefelt med JavaScript, så jeg så etter andre løsninger.
«Ytelse var også en bekymring.»
dvh gjenbesøkt
Selv med potensielle ytelse- og layoutshifts, ble jeg da oppfordret til å teste dvh.
Til min lettelse så min fullskjerm-modal bra ut på ulike nettlesere, med eller uten adressefelt. Og de fryktede layoutshiftene var lite merkbart av to grunner: bakgrunnen er mindre synlig på grunn av modal-backdrop. Og siden modalen er minst fullskjerm, er det ikke nødvendigvis scrollbar, og dermed ikke noe som kan trigge layoutshifts.
Ytelse var også en bekymring, men i min testing oppdaget jeg ikke noen svakheter. Kanskje dette har årsak i at ofte er det bare én modal som er synlig. Hadde jeg brukt dvh på flere elementer på samme side, kunne det kanskje ha ført til problemer. Det må mer testing til for å finne ut av dette.
Alle disse enhetene er forøvrig godt støttet i ulike nettlesere, se caniuse. Du kan også legge til fallback for sikkerhetsskyld:
height: 100vh; // For backwards compatibility
height: 100dvh;Ingenting er alltid rett
Med nye web-størrelser kommer flere muligheter og flere tradeoffs å ta stilling til.
Det er dessverre vanskelig å si at én størrelse alltid er rett, og det trengs testing i ulike scenarier, elementer og enheter for å sikre at oppførselen er som forventet.
Om du vil se mer av disse enhetene i action, har Kevin Powell en fin liten oppsummering av disse enhetene i hans YouTube-video.
Hva er din erfaring med disse nye enhetene — har du brukt dvh?
