Mi az a CSS dvh?

Miért okozott gondot a 100vh?

A vh egység definíció szerint a viewport magasságának egy százaléka. Asztali gépen ez teljesen egyértelmű: a böngészőablak tartalmi területe nem változik görgetés közben.

Mobilon viszont igen. A címsor és az alsó navigációs sáv lefelé görgetve összecsukódik, felfelé görgetve újra megjelenik — a látható terület tehát folyamatosan mozog. A böngészőknek dönteniük kellett, mit jelentsen ilyenkor a vh, és a legtöbben azt választották, hogy rögzítik a legnagyobb lehetséges értéket: azt, amikor a böngésző felülete teljesen összecsukódott.

Ennek két látható következménye lett:

• egy height: 100vh szekció alja induláskor a képernyő alá lóg,
• a „pontosan egy képernyő magas” dizájn mégis görgethetővé válik,
• a hero aljára tervezett gomb vagy scroll-jelzés kicsúszik a látótérből.

Évekig kerülő megoldásokkal éltünk: JavaScriptből mértük a valódi magasságot, és egy CSS változóba írtuk (--vh), majd calc()-csal szoroztuk vissza. Működött, de egy layout-alapproblémát oldott meg futásidejű kóddal.

A viewport egységek új családja

A CSS ma már nem egyetlen viewport-magasságot ismer, hanem hármat — mert mobilon valóban három különböző értelmes válasz létezik a kérdésre, hogy „mekkora a képernyő”.

• svh (small viewport height) — a legkisebb látható magasság, vagyis amikor a böngésző minden felülete látszik.
• lvh (large viewport height) — a legnagyobb látható magasság, amikor a címsor és a navigáció összecsukódott. Ez az, amit a legtöbb böngésző vh-ként ad vissza.
• dvh (dynamic viewport height) — a pillanatnyi érték, ami görgetés közben követi a böngésző felületének mozgását.

A három érték sorrendje mindig ugyanaz: svh ≤ dvh ≤ lvh. A 100dvh tehát nem egy fix szám, hanem egy élő érték, ami e két szélső határ között mozog: mindig annyi, amennyi hely éppen tényleg rendelkezésre áll.

A vh azt mondja meg, mekkora lehet a képernyő. A dvh azt, mekkora most.

Gyorsreferencia: melyiket mikor?

Ha csak egy dolgot viszel el ebből a cikkből, ez a táblázat legyen az. A többi szakasz lényegében ezt bontja ki.

Ökölszabálynak jó: dizájnhoz dvh, garanciához svh. Ha valaminek mindig látszania kell, ne a dinamikus értékre bízd.

A leggyakoribb eset: a hero szekció

Az alapvető használat pontosan olyan egyszerű, amilyennek látszik:

.hero {
    min-height: 100dvh;
}

Két apró, de fontos részlet van ebben a három sorban. Az egyik a min-height a height helyett: így ha a tartalom mégis magasabb lenne egy képernyőnél, nem vágódik le, hanem szépen kifut. A másik, hogy a dvh már a fallback nélkül is helyes eredményt ad ott, ahol támogatott.

Ha régebbi böngészőket is ki kell szolgálnod, a fallback egyetlen extra sor. A CSS a legutolsó értelmezhető szabályt alkalmazza, így a dvh-t nem ismerő böngésző egyszerűen átugorja a második deklarációt:

.hero {
    min-height: 100vh;  /* régebbi böngészők */
    min-height: 100dvh; /* mindenki más */
}

Nem kell hozzá @supports, nem kell hozzá JavaScript, és nem kell hozzá build lépés.

Hero fix fejléc alatt

A gyakorlatban a hero ritkán kezdődik a képernyő tetején — jellemzően van fölötte egy fix navigáció. A viewport egységek nyugodtan használhatók calc()-on belül, így a fejléc magassága egyszerűen levonható:

:root {
    --header-h: 4rem;
}

.hero {
    min-height: calc(100vh - var(--header-h));
    min-height: calc(100dvh - var(--header-h));
    display: grid;
    place-content: center;
}

A fejléc magasságát érdemes CSS változóban tartani: így ugyanaz az érték használható a scroll-margin-top-hoz, a mobilmenü pozicionálásához és a hero számításához is.

Receptek valós elrendezésekhez

A viewport egységeknél ritkán az a kérdés, hogy „mit jelent a dvh” — sokkal inkább az, hogy ebben a konkrét elrendezésben melyik a jó. Négy visszatérő eset, kész kóddal.

1. App-váz: fejléc, görgethető törzs, alsó sáv

Ez a klasszikus mobilapp-szerű felület: fent egy fejléc, lent egy navigációs sáv, közte görgethető tartalom. Itt nem dvh kell, hanem svh.

.app {
    height: 100svh;               /* soha nem ígér több helyet a valóságosnál */
    display: grid;
    grid-template-rows: auto 1fr auto;
}

.app__main {
    min-height: 0;                /* enélkül a grid-sor nem tud zsugorodni */
    overflow-y: auto;
}

Két dolog történik itt. Egyrészt a min-height: 0: grid és flex elrendezésben egy elem alapból nem zsugorodik a tartalma alá, így enélkül a görgethető sáv kilökné az alsó navigációt a képernyőről. Ez a leggyakoribb oka annak, ha „elméletileg jó” az elrendezés, mégis kilóg.

Másrészt a svh: mivel itt nem a dokumentum görget, hanem egy belső elem, a böngésző felülete jellemzően ki sem csukódik. A svh az egyetlen érték, ami ilyenkor garantáltan igaz marad.

2. Teljes képernyős szekciók scroll-snappel

Slide-szerű, egész képernyős szekciók, amik pattannak a helyükre. Itt is svh a helyes választás — méghozzá elvi okból:

.slides {
    height: 100svh;
    overflow-y: auto;
    scroll-snap-type: y mandatory;
}

.slides > section {
    height: 100svh;
    scroll-snap-align: start;
}

Ha a snap-pontok magassága görgetés közben változna, a böngésző a saját számításai ellen dolgozna: minden görgetés elmozdítaná a célpontot, amit épp el akar érni. Az eredmény ugráló, „visszarántós” görgetés. A svh fix érték, tehát minden slide biztosan elfér, és a snap kiszámítható marad.

3. Alulról felcsúszó lap (bottom sheet)

Itt viszont a dvh az igazi: egy fix pozíciójú overlay-nek pont az a dolga, hogy a pillanatnyilag látható területhez igazodjon.

.sheet {
    position: fixed;
    inset-inline: 0;
    bottom: 0;
    max-height: 85dvh;            /* marad egy sáv a háttérből */
    overflow-y: auto;
    padding-bottom: env(safe-area-inset-bottom, 0px);
}

A max-height a lényeg: a lap annyi helyet foglal, amennyit a tartalma kíván, de soha nem nő a képernyő 85%-a fölé. Rövid tartalomnál alacsony marad, hosszúnál görgethetővé válik — külön szabály nélkül.

4. Oldalsó menü (drawer)

És egy recept, amiben a legjobb megoldás az, hogy nincs benne viewport egység:

.drawer {
    position: fixed;
    top: 0;
    bottom: 0;                    /* nem kell magasságegység */
    inset-inline-start: 0;
    width: min(20rem, 80vw);
    overflow-y: auto;
}

A top: 0; bottom: 0 páros ugyanazt éri el, mint a height: 100dvh, csak a böngészőnek nem kell hozzá egy mozgó egységet újraszámolnia. Erről bővebben a következő szakaszban.

dvh vagy 100%? Mikor nem viewport egység kell

A viewport egységek annyira kézre esnek, hogy könnyű túlhasználni őket. Pedig a legtöbb „töltse ki a helyet” feladathoz egyáltalán nem a képernyő mérete kell.

Fix overlay: inset: 0 jobb, mint 100dvh

Egy teljes képernyős modál háttérrétegnél a height: 100dvh működik ugyan, de feleslegesen köti az elemet egy mozgó értékhez:

/* Működik, de fölösleges */
.overlay {
    position: fixed;
    top: 0;
    inset-inline: 0;
    height: 100dvh;
}

/* Jobb */
.overlay {
    position: fixed;
    inset: 0;
}

A második verzió a tartalmazó blokkhoz igazodik, nem egy egységhez — nincs benne számolás, nincs mit újraértékelni görgetés közben, és nem tud „egy pixellel mellé” menni.

Százalék: a szülőhöz igazodik, nem a képernyőhöz

A height: 100% a szülőelem magasságának a százaléka, és csak akkor működik, ha megszakítatlan magasságlánc vezet fel egészen a html elemig. Ezért élt évekig a jól ismert kezdősor:

html, body {
    height: 100%;
}

Ha ez a lánc megvan, a beágyazott elemeknél a 100% gyakran a helyesebb választás: a szülőjét tölti ki, nem a képernyőt. Egy kártyán belüli kép például akkor is helyesen viselkedik, ha a kártya fél képernyő magas.

A virtuális billentyűzet

Ez az a pont, ahol a legtöbb félreértés keletkezik, ezért érdemes pontosan érteni: a felugró mobilbillentyűzet alapértelmezés szerint nem változtatja meg a dvh értékét.

A böngésző ilyenkor a vizuális viewportot csökkenti — vagyis azt, amit épp látsz —, de a layout viewportot, amihez a CSS egységek igazodnak, változatlanul hagyja. Ennek a következménye a klasszikus hiba: egy 100dvh magas app-váz alsó gombja eltűnik a billentyűzet mögött, amikor a felhasználó egy mezőbe kattint.

A meta tag megoldás

A viewport meta tag interactive-widget beállításával megmondható a böngészőnek, hogy a billentyűzet a layout viewportot is zsugorítsa. Ekkor a dinamikus viewport egységek is követni fogják:

<meta name="viewport"
      content="width=device-width, initial-scale=1, interactive-widget=resizes-content">

Három érték létezik:

• resizes-visual — az alapértelmezés: csak a vizuális viewport zsugorodik,
• resizes-content — a layout viewport is zsugorodik, tehát a dvh is követ,
• overlays-content — a billentyűzet egyszerűen ráúszik, semmi nem változik.

Ez a beállítás az egész oldalra vonatkozik, tehát nem valami, amit egy komponens miatt érdemes bekapcsolni — akkor van értelme, ha az oldal jellemzően űrlap- vagy chat-szerű felület. A támogatottsága böngészőnként eltér, ezért kezeld progresszív fejlesztésként: működjön az oldal nélküle is.

Ha pontos érték kell: Visual Viewport API

Ahol tényleg a billentyűzet fölé kell pozicionálni valamit — chat beviteli mező, mobil űrlapnavigáció —, ott a Visual Viewport API adja a pontos számot:

const vv = window.visualViewport;

if (vv) {
    const sync = () => {
        document.documentElement.style
            .setProperty('--vvh', `${vv.height}px`);
    };
    vv.addEventListener('resize', sync);
    vv.addEventListener('scroll', sync);
    sync();
}

Igen, ez visszahozza a JavaScriptet — de most már csak erre az egy, tényleg speciális esetre, nem minden teljes képernyős szekcióhoz. Ez a különbség a régi --vh hackhez képest: ott a szabály volt JavaScriptes, itt a kivétel.

Biztonságos zónák: env(safe-area-inset-*)

A 100dvh megmondja, mekkora a látható terület — de nem azt, hogy annak mekkora része használható. A kivágás (notch), a lekerekített sarkok és az alsó gesztussáv mind a látható területbe esnek, mégsem érdemes tartalmat tenni alájuk.

Ehhez két dolog kell. Először a meta tagben engedélyezni a teljes képernyős kirajzolást:

<meta name="viewport"
      content="width=device-width, initial-scale=1, viewport-fit=cover">

Utána a env() függvénnyel lehet elkerülni a veszélyes zónákat:

.hero {
    min-height: 100dvh;
    padding-block-end: calc(2rem + env(safe-area-inset-bottom, 0px));
}

.bottom-bar {
    position: fixed;
    inset-inline: 0;
    bottom: 0;
    padding-bottom: env(safe-area-inset-bottom, 0px);
}

A második paraméter (0px) a fallback: enélkül a env() ismeretlen változónévvel érvénytelenné tenné az egész deklarációt olyan böngészőkben, amelyek nem ismerik. Mindig írd ki.

Amire érdemes figyelni

A dvh ereje egyben a korlátja is: az értéke tényleg változik görgetés közben, és a böngészőnek emiatt újra kell számolnia az elrendezést.

Ne animálj vele

Ha egy dvh-ban megadott magasság CSS átmenettel van ellátva, a böngésző felületének minden mozdulata elindít egy animációt. Az eredmény ugráló, akadozó layout. A méretváltozást itt hagyd azonnalinak.

/* Ez ugrálni fog mobilon */
.hero {
    min-height: 100dvh;
    transition: min-height 0.3s ease;
}

Vigyázz a tartalom eltolódásával

Ha egy hosszú oldal közepén van egy 100dvh magas blokk, akkor görgetés közben a magassága — és vele az utána következő tartalom pozíciója — elmozdul. Teljes képernyős szekciókat ezért érdemes az oldal elejére tenni, vagy svh-t használni középen.

Media query-ben inkább ne

Egy töréspont feltétele legyen stabil. Ha görgetés közben mozgó értéktől függ, a media query oda-vissza billeghet, és olyan hibákat okoz, amiket utólag nagyon nehéz reprodukálni. Media query-be svh vagy lvh való, a dvh maradjon az elrendezésben.

A frissítés nem feltétlenül képkockapontos

A specifikáció megengedi a böngészőknek, hogy a dinamikus viewport méretét ritkábban frissítsék, mint ahogy a felület ténylegesen mozog. Ez tudatos döntés: így nem kell minden képkockában újraszámolni az egész elrendezést. A gyakorlatban ez azt jelenti, hogy a dvh-ra elrendezésként lehet támaszkodni, de nem szabad rá olyat építeni, ami képkockapontos követést vár. Ahhoz a Visual Viewport API kell.

Iframe-ben a saját viewport számít

Egy iframe-en belül a viewport egységek az iframe méretéhez viszonyulnak, nem a befoglaló oldaléhoz. Beágyazott widgetnél ezért a 100dvh szinte biztosan nem azt jelenti, amit vársz — ott a százalék vagy a container query egységek a jó eszközök.

Nem csak magasság

Ugyanez a logika végigmegy az összes viewport egységen, nem csak a magasságon. Mindegyik megkapta a s, l és d előtagot:

• dvw — dinamikus viewport szélesség,
• dvmin és dvmax — a kettő közül a kisebb, illetve a nagyobb,
• dvi és dvb — inline és block irányú méret, írásirány-függetlenül.

A gyakorlatban a dvh az, amiért a család létrejött — a szélesség mobilon jóval ritkábban változik menet közben. A dvi és dvb akkor jön jól, ha az oldal több írásirányt is kiszolgál: függőleges írásmódban a „block irány” a vízszintes, és a logikai egységek ezt maguktól követik.

Migráció a JavaScriptes --vh hackről

Ha a projekted régebbi, jó eséllyel megvan még benne ez a kód — évekig ez volt a bevett megoldás:

// Régi megoldás — ez törölhető
const setVh = () => {
    document.documentElement.style
        .setProperty('--vh', `${window.innerHeight * 0.01}px`);
};

setVh();
window.addEventListener('resize', setVh);

.hero {
    height: calc(var(--vh, 1vh) * 100);
}

Az egész helyére ennyi kerül:

.hero {
    min-height: 100vh;
    min-height: 100dvh;
}

A csere lépésről lépésre:

1. keresd meg a kódbázisban a --vh, innerHeight és resize mintákat,
2. a calc(var(--vh) * 100) értékeket cseréld 100dvh-ra — vagy 100svh-ra ott, ahol garantált férőhely kell,
3. töröld a JavaScriptet és a resize eseményfigyelőt,
4. nézd át, hol maradt height olyan helyen, ahol min-height a helyes,
5. ellenőrizd valódi eszközön (lásd a következő szakaszt).

A csere nem csak kódsorokat spórol: a natív egység már az első festésnél helyes, míg a JavaScriptes változat mindig megvillant egy rossz magassággal, mielőtt lefutott.

Hogyan teszteld?

Ez a szakasz azért fontos, mert a dvh-val kapcsolatos hibák nagy része nem reprodukálható asztali böngészőben — beleértve a DevTools eszközszimulátorát is.

A mobilnézet-emuláció nem csukja össze a címsort, mert nincs is neki. Emiatt ott a svh, az lvh és a dvh mind ugyanazt az értéket adja, és pont az a jelenség marad láthatatlan, amit ki akarsz szűrni. Valódi eszköz kell hozzá: Androidon chrome://inspect, iOS-en a Safari Web Inspector.

Mérőléc a három egységhez

A leggyorsabb módszer, hogy tényleg lásd, mit ad vissza a három egység az adott eszközön: illessz be ideiglenesen ennyit.

// Ideiglenes mérőléc — élesbe ne menjen ki
const probe = (unit) => {
    const d = document.createElement('div');
    d.style.cssText = `position:fixed;visibility:hidden;height:100${unit}`;
    document.body.append(d);
    return d;
};

const p = { svh: probe('svh'), lvh: probe('lvh'), dvh: probe('dvh') };

const out = document.createElement('div');
out.style.cssText =
    'position:fixed;z-index:9999;top:0;left:0;padding:.4rem;' +
    'background:#000;color:#0f0;font:12px monospace';
document.body.append(out);

(function tick() {
    out.textContent =
        `svh ${p.svh.offsetHeight} · ` +
        `lvh ${p.lvh.offsetHeight} · ` +
        `dvh ${p.dvh.offsetHeight}`;
    requestAnimationFrame(tick);
})();

Görgess le és fel: a svh és az lvh értéke fix marad, a dvh pedig végigmegy a kettő között. Ha mind a három ugyanaz, akkor vagy asztali böngészőben vagy, vagy telepített PWA-ban — ott nincs mit követni. (Az offsetHeight egész pixelre kerekít, tehát 1 pixel eltérés normális.)

Tesztelési ellenőrzőlista

• iOS Safari: görgess le teljesen, majd vissza fel — nem vágódik le semmi?
• Android Chrome: ugyanez, plusz a lenti gesztussáv környéke,
• fókuszálj egy beviteli mezőre — a billentyűzet mögé kerül valami fontos?
• fordítsd el az eszközt fekvő módba — fekvőben a képernyő alacsony, egy 100dvh hero könnyen használhatatlanul zsúfolt lesz,
• ha PWA-ként telepíthető az oldal, nézd meg standalone módban is,
• kapcsold be a „csökkentett mozgás” beállítást, ha animáció is van a szekcióban.

Böngészőtámogatás

A dinamikus viewport egységeket a Safari 15.4, a Chrome 108, az Edge 108 és a Firefox 101 óta minden nagy böngésző támogatja. 2026-ban ez gyakorlatilag a teljes aktív felhasználói bázist lefedi, a fenti kétsoros vh fallback pedig a maradékot is rendezi.

Ha ennél többre van szükség — például egy egész elrendezés máshogy épül fel a két esetben —, a @supports is használható:

@supports (height: 100dvh) {
    .app {
        height: 100svh;
    }
}

A gyakorlatban erre ritkán van szükség: a két deklarációs fallback rövidebb, olvashatóbb, és ugyanazt éri el. A @supports akkor indokolt, ha a régi és az új változat szerkezetében tér el.

Ha eddig JavaScriptes --vh megoldást használtál, ezt nyugodtan kitörölheted: a natív egység pontosabb, gyorsabb, és nem villan meg az első festés előtt.

Ellenőrzőlista

Mielőtt élesítesz egy teljes képernyős elrendezést, fusd át ezt a listát:

• min-height szerepel height helyett, ahol a tartalom nőhet,
• a dvh-s sor fölött ott a vh fallback,
• ahol garantáltan el kell férni (app-váz, alsó sáv), svh van,
• scroll-snapnél svh van, nem dvh,
• fix overlaynél inset: 0 van magasságegység helyett,
• nincs transition vagy animáció dvh-ban megadott méreten,
• media query-ben nincs dvh,
• grid vagy flex görgethető sávján ott a min-height: 0,
• viewport-fit=cover esetén ki vannak téve a safe-area-inset paddingok,
• a billentyűzetes eset át van gondolva (interactive-widget vagy Visual Viewport API),
• a régi JavaScriptes --vh hack törölve lett,
• valódi mobil eszközön is le lett tesztelve, nem csak emulátorban.