Løs iOS Safari's 100vh Overlap: En Komplet Guide

Har du nogensinde undret dig over, hvorfor din perfekt designede webside ser forkert ud på en iPhone, især i bunden af skærmen? Mange webudviklere støder på et frustrerende problem i iOS Safari, hvor indhold, der er designet til at fylde hele skærmen ved hjælp af CSS-enheden 100vh, ender med at blive overlappet af browserens navigationslinje eller værktøjslinje. Dette kan føre til afskåret indhold, unødvendige scrollbars eller en generelt dårlig brugeroplevelse. Denne artikel dykker ned i årsagen bag dette fænomen og præsenterer flere robuste løsninger, der kan hjælpe dig med at opnå det ønskede layout på iOS-enheder.

For at forstå problemets kerne, lad os forestille os en simpel webside med to absolut positionerede bokse: én øverst til venstre og én nederst til højre. Disse bokse er indkapslet i et element, der har en bredde på 100vw (100% af viewport-bredden) og en højde på 100vh (100% af viewport-højden). I et ideelt scenarie forventer man, at dette container-element vil strække sig over hele den synlige skærm. Men i iOS Safari viser virkeligheden sig at være anderledes. Den nederste boks kan ende med at være skjult bag browserens navigationslinje, hvilket indikerer, at 100vh ikke repræsenterer den 'faktiske' synlige højde, men snarere en højde, der inkluderer det område, som værktøjslinjerne dækker.

Hvad er Problemet med 100vh på iOS Safari?

Problemet med 100vh på iOS Safari er, at denne enhed beregner viewport-størrelsen uden at tage højde for højden af Safari-browserens dynamiske værktøjslinjer. Disse værktøjslinjer (adressefeltet øverst og navigationslinjen nederst) kan automatisk skjules eller vises, når brugeren scroller. Når de er synlige, optager de en del af skærmens fysiske højde. Men 100vh definerer viewporten som den maksimale mulige højde, hvis værktøjslinjerne var skjult, eller som et fast mål, der ikke dynamisk tilpasser sig. Dette betyder, at hvis du indstiller et element til height: 100vh;, og Safari-værktøjslinjen er synlig, vil dit indhold strække sig under værktøjslinjen. Dette tvinger brugeren til enten at scrolle for at få adresselinjen til at forsvinde automatisk, eller manuelt at skjule den for at få vist alt indhold. Denne opførsel afviger fra, hvordan mange udviklere forventer, at vh-enheden skal fungere, og skaber en udfordring for fuldskærmslayouts, modals eller lightboxes.

Hvorfor Opstår Dette Fænomen? En Intentional Designbeslutning

Måske den mest overraskende del af dette problem er, at det ikke er en fejl. Det er en fuldstændig intentional designbeslutning truffet af WebKit-udviklerne (motoren bag Safari). Benjamin Poulain, en WebKit-udvikler, har forklaret årsagen bag denne beslutning i forbindelse med en WebKit-bugticket. Han angiver, at dette design var et resultat af betydeligt arbejde for at opnå en bestemt effekt, nemlig at forhindre dårlig ydeevne og en "janky" (rykkende) brugeroplevelse.

Det grundlæggende problem er, at det synlige område ændrer sig dynamisk, når du scroller. Hvis browseren skulle opdatere CSS-viewport-højden i overensstemmelse hermed, ville det kræve, at layoutet opdateres kontinuerligt under scroll. Dette ville ikke kun se "elendigt" ud, da indholdet ville flytte sig uforudsigeligt, men det ville også være praktisk talt umuligt at opretholde en stabil framerate på 60 FPS, som er standarden på iOS. En konstant omberegning af layoutet ved hver scroll-begivenhed ville overbelaste de fleste websider og føre til en meget dårlig brugeroplevelse.

Frem for at droppe viewport-enheder på iOS, matche dokumentstørrelsen som før iOS 8, bruge den lille synlige størrelse eller den store synlige størrelse, valgte WebKit-teamet at bruge den større visningsstørrelse som det bedste kompromis. Deres data viste, at de fleste hjemmesider, der brugte viewport-enheder, i de fleste tilfælde så fine ud. Derfor er der ingen planlagt rettelse for dette – det er en bevidst afvejning mellem layoutnøjagtighed og flydende ydeevne.

Løsninger på Udfordringen

Selvom det kan virke nedslående, at problemet er intentionalt og ikke en fejl, er der heldigvis flere måder at omgå det på og sikre, at dit indhold vises korrekt på tværs af iOS Safari.

1. Den Enkle Løsning: Brug af 100%

Afhængigt af dit specifikke brugsscenarie kan det være tilstrækkeligt blot at bruge height: 100%; i stedet for 100vh. Denne løsning er ofte effektiv for faste eller sticky elementer, da 100% vil være relativ til den "rigtige" viewport, forudsat at forælderelementet, f.eks. <body> eller <html>, har en defineret højde, der strækker sig over hele skærmen. Hvis du har et element, der er positioneret absolut eller fast, og dets forælder er body eller html, som typisk er sat til at dække hele skærmen (f.eks. med height: 100% på html, body), så vil height: 100% på dit element ofte give den ønskede effekt, hvor det tilpasser sig den synlige viewport.

Dog er denne metode ikke altid velegnet. Hvis dit element er indlejret dybere i DOM-træet, og dets forælderelementer kun er lige så høje som det indhold, de indeholder, vil height: 100% blot gøre elementet lige så højt som dets forælder, hvilket ikke nødvendigvis er den fulde viewport-højde. Dette er ofte grunden til, at udviklere oprindeligt vælger 100vh.

2. De Eksperimentelle Enheder: stretch / -webkit-fill-available

CSS har introduceret et sæt nøgleord for intrinsic og extrinsic sizing, som udvider mulighederne for dimensionering med indholdsbaserede ("intrinsic") og kontekstbaserede ("extrinsic") størrelser. Et af disse nøgleord er stretch, som tidligere var kendt som fill, fill-available og dets præfikserede varianter som -moz-available og -webkit-fill-available. Denne funktionalitet kan udnyttes, og fordi CSS simpelthen ignorerer stilerklæringer, den ikke forstår, kan vi implementere fallbacks for alle disse mulige implementeringer:

.container {
 height: 100%;
 height: -moz-available;
 height: -webkit-fill-available;
 height: fill-available;
 height: stretch;
}

Dette sikrer en vis grad af kompatibilitet på tværs af browsere, selvom stretch og fill-available stadig har varierende support. Autoprefixer, et populært værktøj, vil automatisk kompilere stretch til -webkit-fill-available og -moz-available for at give bredere dækning. Denne løsning er ren CSS-baseret, men dens effektivitet afhænger stærkt af den specifikke browsers understøttelse.

3. JavaScript som Redningsplanke

JavaScript er ofte den "sidste udvej" for ting, der ikke er mulige med ren CSS. Ved at bruge JavaScript kan du dynamisk beregne den faktiske synlige viewport-højde og anvende den på dine elementer. Dette giver dig fuld kontrol og præcision, selvom det introducerer en afhængighed af JavaScript og potentielt kan medføre en kort "flash" af ukorrekt layout, før scriptet kører.

A. Med CSS Variabler

En elegant måde at bruge JavaScript på er at opdatere en CSS-variabel med den aktuelle window.innerHeight værdi, som repræsenterer den synlige højde af browserens vindue. Du kan derefter bruge denne variabel i din CSS.

const updateViewportHeight = () => {
 document.documentElement.style.setProperty('--viewport-height', `${window.innerHeight}px`);
};

window.addEventListener('resize', updateViewportHeight);
updateViewportHeight(); // Kald ved indlæsning for at sætte initial værdi

I din CSS kan du derefter forbruge denne variabel og inkludere en fallback for browsere, der ikke understøtter CSS-variabler eller @supports-reglen:

:root {
 --viewport-height: 100%; /* Fallback */
}

.container {
 height: 100vh; /* Standard fallback for ældre browsere */
 @supports (height: var(--)) { /* Tjek for CSS-variabel support */
 height: var(--viewport-height);
 }
}

Denne metode giver en meget dynamisk og responsiv løsning, da højden opdateres automatisk, når vinduet ændrer størrelse (f.eks. ved rotation af enheden).

B. Direkte DOM-Manipulation

Hvis du af en eller anden grund ikke kan bruge CSS-variabler i dit projekt (f.eks. på grund af specifikke browser support-krav), kan du også opdatere højden af dine berørte elementer direkte fra dit script:

const container = document.querySelector('.container');

const updateViewportElements = () => {
 if (container) {
 container.style.height = `${window.innerHeight}px`;
 }
};

window.addEventListener('resize', updateViewportElements);
updateViewportElements(); // Kald ved indlæsning for at sætte initial værdi

Denne tilgang er mere direkte, men kan blive mindre overskuelig, hvis du har mange elementer, der skal opdateres, eller hvis du foretrækker at holde styling så meget som muligt i CSS.

4. Den Moderne Løsning: dvh (Dynamic Viewport Height)

Den mest moderne og nok den mest elegante løsning på problemet med dynamiske værktøjslinjer er brugen af dvh-enheden, som står for "dynamic viewport height". Denne enhed er designet specifikt til at løse dette problem ved automatisk at tage højde for den plads, som browserens værktøjslinjer optager. dvh-enheden repræsenterer den faktiske synlige højde af viewporten, som den vises for brugeren, og tilpasser sig, når værktøjslinjerne skjules eller vises.

dvh-enheden nyder bred support i alle de nyeste browsere, hvilket gør den til det optimale valg for fremtidssikrede applikationer. For at sikre bagudkompatibilitet med ældre browsere, der muligvis ikke understøtter dvh, kan du bruge @supports CSS-reglen til at definere en fallback. Her er et eksempel på, hvordan du ville opsætte en klasse kaldet full-viewport-height, der tilpasser sig browserens viewport ved hjælp af dvh-enheden, men falder tilbage til vh, hvis browseren ikke understøtter den:

.full-viewport-height {
 height: 100vh; /* Fallback for browsere uden dvh support */
}

@supports (height: 100dvh) {
 .full-viewport-height {
 height: 100dvh; /* Den dynamiske højde for moderne browsere */
 }
}

Ved at anvende denne klasse på din container, vil indholdet nu strække sig over hele webstedets højde, selvom Safari-værktøjslinjen er synlig. Når brugeren scroller ned, eller værktøjslinjen skjules, tilpasser indholdet sig for at udfylde hele siden, hvilket sikrer, at dit indhold altid dækker viewporten som forventet. Dette er den reneste CSS-baserede løsning, da den kræver minimal kode og ingen JavaScript for at håndtere dynamikken.

Kan Man Skjule Safari Toolbar med JavaScript?

Et spørgsmål, der ofte opstår i forbindelse med dette emne, er, om det er muligt programmatisk at skjule Safari-værktøjslinjen ved hjælp af JavaScript. Desværre er svaret på dette tidspunkt et klart nej. Der er ingen offentlig API eller JavaScript-metode, der giver dig mulighed for at tvinge Safari til at skjule eller vise dens øverste adressebar eller nederste navigationslinje. Browserens UI-elementer er bevidst holdt uden for webudvikleres kontrol for at opretholde en ensartet og sikker brugeroplevelse.

Derfor er løsningerne, vi har diskuteret, fokuseret på at få dit indhold til at tilpasse sig tilstedeværelsen af disse værktøjslinjer, snarere end at kontrollere dem direkte. dvh-enheden er den mest effektive måde at opnå denne tilpasning på, da den automatisk justerer dit layouts højde baseret på den synlige viewport, uanset om værktøjslinjerne er synlige eller ej.

Sammenligning af Løsninger

For at give et hurtigt overblik over de forskellige løsninger, deres fordele og ulemper, er her en sammenligningstabel:

Ofte Stillede Spørgsmål (FAQ)

Hvorfor fungerer 100vh anderledes på iOS Safari end andre browsere?

100vh i iOS Safari beregnes ud fra den maksimale potentielle viewport-højde, dvs. når browserens dynamiske værktøjslinjer er skjulte. Dette er en bevidst designbeslutning fra WebKit-teamet for at sikre flydende ydeevne (60 FPS) og undgå layoutskift, når værktøjslinjerne dukker op eller forsvinder under scroll. Andre browsere kan dynamisk justere vh for at afspejle den aktuelle synlige viewport.

Er der en måde at tvinge Safari til at skjule adresselinjen eller navigationslinjen programmatisk?

Nej, på nuværende tidspunkt er der ingen JavaScript API eller CSS-egenskab, der giver webudviklere mulighed for at tvinge Safari til at skjule eller vise dens brugergrænseflade-elementer som adresselinjen eller den nederste navigationslinje. Dette er en sikkerheds- og brugervenlighedsfunktion, der er implementeret af browseren for at bevare en ensartet oplevelse og forhindre misbrug.

Hvad er den bedste løsning for fremtiden for at håndtere dette problem?

Den mest fremtidssikre og anbefalede løsning er brugen af CSS-enheden dvh (dynamic viewport height). Denne enhed er specifikt designet til at håndtere de dynamiske størrelser af viewporten, der opstår på grund af browserens UI-elementer, og den tilpasser sig automatisk. For at sikre bred kompatibilitet, bør du kombinere dvh med en vh fallback ved hjælp af @supports-reglen.

Kan jeg bruge dvh i alle browsere?

dvh-enheden understøttes af alle moderne browsere, herunder de seneste versioner af Chrome, Firefox, Safari og Edge. For at sikre, at din løsning også fungerer på ældre browsere, er det dog klogt at inkludere en fallback til vh eller en anden metode ved hjælp af @supports.

Skal jeg bruge JavaScript, hvis jeg bruger dvh?

Nej, en af de store fordele ved dvh er, at den er en ren CSS-løsning. Du behøver ikke JavaScript for at beregne eller opdatere højden, når du bruger dvh, da browseren selv håndterer den dynamiske justering. JavaScript-løsninger er primært relevante, hvis du skal understøtte meget gamle browsere, der ikke understøtter dvh, eller hvis du har meget specifikke og komplekse layoutkrav, som ikke kan løses med CSS alene.

Konklusion

Problemet med 100vh i iOS Safari er en velkendt udfordring for webudviklere, men som vi har set, er der flere effektive strategier til at håndtere det. Selvom der ikke findes en "one-size-fits-all" magisk løsning, er den moderne dvh-enhed uden tvivl det mest elegante og anbefalede valg for nye projekter. Den giver en ren CSS-baseret løsning, der automatisk tilpasser sig browserens dynamiske UI-elementer og sikrer, at dit indhold altid vises korrekt.

For ældre projekter eller specifikke krav kan 100%, stretch/-webkit-fill-available eller JavaScript-baserede løsninger stadig være relevante. Uanset hvilken metode du vælger, er det afgørende at udføre grundig test på tværs af forskellige iOS-enheder og browsere for at sikre, at dit design fungerer som forventet og leverer en problemfri brugeroplevelse. Ved at forstå årsagen bag problemet og anvende de rette løsninger kan du sikre, at dine websider altid ser professionelle og funktionsdygtige ud på alle iPhones.

Hvis du vil læse andre artikler, der ligner Løs iOS Safari's 100vh Overlap: En Komplet Guide, kan du besøge kategorien Teknologi.