Forstå 100vh og nye viewport-enheder

Hvad betyder 100vh i HTML og CSS?

I webudvikling, især når man arbejder med CSS, støder man ofte på enheder, der definerer størrelser og dimensioner. En af disse enheder, som har vundet stor popularitet, er vh, der står for "viewport height". Enheden 100vh betyder specifikt, at et element skal optage 100% af browserens synlige højde, også kendt som viewporten. Dette er utroligt nyttigt, når man ønsker at et element, som f.eks. en header eller en sektion, skal fylde hele skærmbilledet og give en imponerende visuel oplevelse. Det giver en følelse af dybde og kan virkelig fange brugerens opmærksomhed.

Forestil dig en hjemmeside, hvor du vil have en stor, indbydende billedheader, der strækker sig fra top til bund af skærmen. Ved at sætte elementets højde til height: 100vh; opnår du netop dette. Det er en simpel, men effektiv måde at skabe et fuldskærms layout på, som kan give din hjemmeside et moderne og professionelt udseende. Mange webdesignere bruger denne teknik til at fremhæve vigtigt indhold eller skabe en dramatisk effekt.

Udfordringen med mobile browsere og 100vh

Selvom 100vh er en kraftfuld enhed, har den en markant ulempe, især når man ser på hjemmesider på mobile enheder som smartphones. Problemet opstår især i browsere som Safari på iOS. Årsagen er, at mobile browsere ofte har dynamiske brugergrænsefladeelementer, såsom navigationslinjer og værktøjslinjer, der enten vises eller skjules, når brugeren interagerer med siden (f.eks. ved at scrolle).

Safari på iOS er kendt for at prioritere at give mest muligt plads til indholdet ved at skjule sine værktøjslinjer, når man scroller ned. Dette lyder umiddelbart som en god ting, men det skaber et problem for 100vh-enheden. Når du sætter et elements højde til 100vh, beregner browseren højden baseret på viewporten, uden at tage højde for de UI-elementer, der kan dække for en del af skærmen.

Forestil dig et element med height: 100vh;. På en desktop-browser vil det fylde hele skærmen. Men på en iOS-enhed med Safari, kan den nederste værktøjslinje overlappe bunden af dit element, hvilket betyder, at en del af dit indhold bliver skjult. Dette er ikke, hvad man forventer, når man designer med 100vh, og det kan føre til en dårlig brugeroplevelse, hvor vigtigt indhold bliver utilgængeligt.

Dette fænomen er ikke unikt for Safari; det kan også observeres i iOS-versionen af Chrome. Andre browsere på iOS, som Brave, DuckDuckGo, Firefox og Opera, håndterer det ofte anderledes og tager højde for de dynamiske værktøjslinjer på en måde, der undgår dette overlap.

Hvorfor opstår problemet med Safari?

Apple har valgt en tilgang, hvor viewportens højde forbliver konstant, selv når værktøjslinjerne vises eller skjules. De begrunder dette med at undgå "jankiness" – altså pludselige og uventede ændringer i layoutet, når UI-elementerne skifter. Ved at holde viewport-højden konstant, sikrer de, at elementernes positionering forbliver stabil. Men konsekvensen er, at når værktøjslinjerne er synlige, vil et element sat til 100vh faktisk være højere end det synlige område, og den nederste del vil blive dækket.

Dette rejser et interessant spørgsmål: Hvordan løser man dette problem uden at ty til JavaScript, som kan føles som en "hacky" løsning og blander layoutlogik med funktionalitet?

Traditionelle løsninger og deres begrænsninger

Før introduktionen af nye viewport-enheder, var der forskellige metoder til at forsøge at omgå dette problem. En af dem var at bruge JavaScript til dynamisk at beregne og sætte elementets højde baseret på `window.innerHeight`. Dette fungerer, men som nævnt, er det ikke altid den mest elegante løsning, og det kan potentielt introducere små visuelle ryk (jankiness), når viewport-højden ændrer sig.

En anden potentiel løsning, der blev undersøgt, var brugen af `-webkit-fill-available`. Selvom dette kan være nyttigt i visse situationer, var det ikke altid en perfekt pasform, især hvis man også skulle tage højde for andre elementer, som f.eks. en fast header på hjemmesiden.

En almindelig metode var også at bruge `calc()` funktionen i CSS til at trække en fast højde fra 100vh. For eksempel, hvis din side-header var 6rem høj, kunne du skrive: min-height: calc(100vh - 6rem);. Dette hjalp med at justere højden, men det løste ikke grundlæggende problemet med, hvordan Safari fortolkede 100vh i forhold til de dynamiske værktøjslinjer.

Introduktion af nye Viewport-enheder: dvh, svh, lvh

Heldigvis har webudviklingsverdenen budt på nye og forbedrede CSS-enheder, der specifikt er designet til at håndtere disse dynamiske viewport-situationer. Disse nye enheder blev introduceret for at give udviklere mere kontrol og præcision, når de designer layouts til moderne enheder.

Der er tre primære nye viewport-enheder:

• 100dvh (dynamic viewport height): Denne enhed tager højde for ændringer i viewport-højden. Den justerer sig automatisk, når værktøjslinjer vises eller skjules. Dette lyder som den ideelle løsning, da den reagerer på ændringerne i brugergrænsefladen.
• 100svh (small viewport height): Denne enhed antager, at værktøjslinjerne altid er fuldt synlige og udvidede. Den beregner viewport-højden baseret på den mindste mulige synlige højde. Dette sikrer, at intet indhold bliver dækket af værktøjslinjer.
• 100lvh (large viewport height): Denne enhed antager, at værktøjslinjerne er skjulte eller minimeret. Den beregner viewport-højden baseret på den maksimale mulige synlige højde.

Hvornår skal man bruge hvad?

Lad os se på, hvordan disse nye enheder kan anvendes for at løse Safari-problemet:

Brug af 100dvh:

Man kunne blive fristet til at bruge 100dvh, da den lyder mest "dynamisk". Ved at kombinere den med en @supports feature query, kan man sørge for, at moderne browsere bruger den nye enhed, mens ældre browsere falder tilbage på 100vh:

.element { min-height: 100vh; } @supports (height: 100dvh) { .element { min-height: 100dvh; } } 

Problemet med 100dvh er, at når værktøjslinjerne skjules (og viewporten bliver højere), vil elementet også strække sig. Dette kan føre til, at indholdet forskydes, hvilket skaber den "jankiness", som Safari forsøger at undgå. Selvom det løser overlap-problemet, kan det introducere et nyt visuelt problem.

Brug af 100svh:

For at opnå et stabilt layout, der altid er fuldt synligt uden overlap, er 100svh ofte den mest pålidelige løsning. Den sikrer, at elementet passer inden for den mindste mulige viewport-højde, hvilket betyder, at det aldrig vil blive dækket af værktøjslinjer. Selvom elementet måske ikke udnytter den fulde højde, når værktøjslinjerne er skjulte, opnår man et konsistent og forudsigeligt resultat.

.element { min-height: 100vh; } @supports (height: 100svh) { .element { min-height: 100svh; } } 

Med denne kode vil elementet altid være synligt, selv når værktøjslinjerne er aktive i Safari. Når værktøjslinjerne skjules, vil elementet forblive den samme størrelse, i stedet for at udvide sig. Dette giver en mere stabil brugeroplevelse.

Brug af 100lvh:

100lvh bruges, når man ønsker at designe til den maksimale viewport-højde, antagende at alle UI-elementer er skjulte. Dette kan være nyttigt i specifikke designscenarier, men for generel brug, især på mobile enheder, kan det føre til overlappende indhold, hvis værktøjslinjerne er synlige.

Praktisk anvendelse og resultater

Mange webdesignere har fundet, at brugen af 100svh i kombination med calc() og @supports giver den bedste balance mellem æstetik og funktionalitet på tværs af forskellige browsere og enheder. Det sikrer, at brugeroplevelsen er forudsigelig og fri for ubehagelige overraskelser, som f.eks. skjult indhold.

Selvom nogle browsere som Firefox og Brave måske ignorerer 100svh og fortsætter med at bruge deres egen dynamiske håndtering, er effekten for de fleste brugere minimal, især hvis man betragter den samlede trafikfordeling. Den vigtigste pointe er at kunne levere en stabil oplevelse til den største brugerbase.

Sammenligningstabel: Viewport-enheder

Ofte Stillede Spørgsmål (FAQ)

Hvad er viewporten i CSS?

Viewporten er det synlige område af en webside i browseren. Dens størrelse kan variere afhængigt af enheden (desktop, tablet, mobil) og browserens indstillinger.

Hvorfor er 100vh problematisk på mobil?

På mobile browsere med dynamiske UI-elementer (som f.eks. navigationslinjer i Safari), kan disse elementer overlappe eller skjule en del af skærmen. Da 100vh beregnes uden at tage højde for disse elementer, kan det føre til, at indhold bliver skjult.

Hvornår bør jeg bruge 100svh i stedet for 100vh?

Du bør overveje at bruge 100svh, når du designer layouts, hvor det er kritisk, at alt indhold altid er synligt, og du vil undgå overlap med browserens UI-elementer, især på mobile enheder.

Er 100dvh altid den bedste løsning?

Ikke nødvendigvis. Selvom 100dvh er designet til at være dynamisk, kan det føre til uønskede layout-ændringer, når viewport-højden ændrer sig. For et mere stabilt design er 100svh ofte at foretrække.

Hvad med browserunderstøttelse for de nye enheder?

Understøttelsen for de nye viewport-enheder (dvh, svh, lvh) er generelt god i moderne browsere. Det anbefales dog stadig at bruge @supports feature queries for at sikre bagudkompatibilitet og en ensartet oplevelse på tværs af browsere.

Konklusion

CSS viewport-enheder, især 100vh, har revolutioneret måden, vi bygger responsive layouts på. Men som med mange nye teknologier, opstår der udfordringer, når de anvendes i komplekse miljøer som mobile browsere. Problemet med 100vh i Safari på iOS understreger vigtigheden af at forstå, hvordan forskellige browsere fortolker og implementerer CSS-standarder.

Introduktionen af dvh, svh og lvh giver webudviklere de værktøjer, de behøver for at navigere disse udfordringer. Ved at vælge den rette enhed, som f.eks. 100svh til at sikre synlighed, eller ved at bruge feature queries til at tilbyde progressive forbedringer, kan man skabe robuste og brugervenlige weboplevelser, der ser godt ud på alle enheder. Det er en konstant læringsproces, men med disse nye værktøjer er vi bedre rustet til at bygge fremtidens web.

Hvis du vil læse andre artikler, der ligner Forstå 100vh og nye viewport-enheder, kan du besøge kategorien Teknologi.