L’unité dvh règle un vrai problème d’interface sur mobile : elle permet de dimensionner un élément en fonction de la hauteur réellement visible du viewport, au lieu de se baser sur une valeur trop théorique. Dans cet article, je vais montrer ce qu’elle mesure, pourquoi elle corrige les comportements pénibles de vh, quand l’utiliser, quand l’éviter, et comment l’intégrer proprement dans un front moderne.
Les points essentiels à retenir sur la hauteur dynamique
-
1dvhreprésente 1 % de la hauteur du viewport dynamique. -
100dvhsuit les changements de la barre d’adresse, des barres d’outils et du clavier virtuel. -
vhse comporte encore commelvhsur les navigateurs modernes, ce qui peut dépasser la zone visible. -
svhsert à stabiliser l’interface,lvhà viser la hauteur maximale,dvhà coller à l’espace réellement affiché. - Pour un plein écran fiable, je privilégie souvent
min-heightplutôt queheight. - Le bon choix dépend surtout de l’effet recherché : stabilité, couverture maximale ou adaptation en temps réel.
Pourquoi 100vh reste piégeux sur mobile
Sur desktop, 100vh donne souvent un résultat satisfaisant : l’élément remplit la fenêtre du navigateur, point final. Sur mobile, c’est une autre histoire, parce que la hauteur visible varie selon la présence de la barre d’adresse, des barres d’outils et, parfois, du clavier virtuel.
C’est exactement le cas classique mis en avant par web.dev : un bloc en 100vh peut être trop grand à l’ouverture de la page, puis devenir “juste” après un scroll quand l’interface du navigateur se replie. En clair, ce qui semble être un écran complet peut déborder, couper un bouton, ou créer un espace vide difficile à anticiper.
| Comportement | Effet visuel | Risque concret |
|---|---|---|
100vh sur mobile |
Calcule la hauteur sur une base souvent trop large | Bloc coupé, contenu caché, scroll inutile |
100dvh |
S’adapte à la hauteur visible en temps réel | Peut provoquer un léger redimensionnement quand l’UI change |
Le point clé, pour moi, est simple : si l’interface doit réellement vivre dans l’espace visible, 100vh n’est plus le bon réflexe par défaut. C’est là que la différence entre les unités de viewport devient décisive.
Ce que mesure réellement dvh
dvh signifie dynamic viewport height. Concrètement, 1dvh vaut 1 % de la hauteur du viewport dynamique, c’est-à-dire de la zone visible telle qu’elle est au moment du rendu. Si l’interface du navigateur change, la valeur suit.
Je trouve utile de le formuler ainsi : dvh ne mesure pas la hauteur “idéale” de l’écran, mais la hauteur effective disponible pour la page. C’est précisément ce qui le rend intéressant pour les écrans d’accueil, les modales, les panneaux latéraux sur mobile ou les zones qui doivent rester entièrement visibles.
Quand le viewport change vraiment
Le viewport dynamique n’est pas un concept abstrait. Il réagit aux barres de navigation qui apparaissent ou disparaissent, au passage en orientation paysage, et dans certains cas au clavier virtuel. Une interface qui semble figée sur papier peut donc changer de hauteur pendant la session, ce qui est normal.
Cette dynamique est utile, mais elle a un coût : si votre design dépend d’une hauteur exacte, vous devez accepter que l’élément se redimensionne pendant l’usage. Ce n’est pas un défaut de dvh, c’est la conséquence logique d’un choix orienté “visible maintenant”.
Ce que ça change pour la mise en page
En pratique, dvh devient pertinent dès qu’un bloc doit épouser l’écran visible sans le dépasser. J’évite simplement d’en faire une règle universelle, parce qu’un composant qui grandit et rétrécit en continu n’est pas toujours plus confortable qu’un composant légèrement plus stable.
Autrement dit, dvh est une solution de précision, pas un remplacement automatique de toutes les hauteurs en viewport. Pour choisir correctement, il faut comparer ses trois variantes de référence.
Choisir entre svh, lvh et dvh
Les nouvelles unités de viewport ont été créées pour couvrir trois besoins différents : la hauteur la plus petite, la plus grande et la hauteur dynamique. MDN rappelle d’ailleurs que vh se comporte désormais comme lvh dans les navigateurs modernes, ce qui explique pourquoi les anciens problèmes réapparaissent sur mobile dès qu’on cherche un plein écran strict.
| Unité | Ce qu’elle suit | Je la privilégie quand | Limite principale |
|---|---|---|---|
svh |
La plus petite hauteur visible | Je veux stabiliser l’interface et éviter les sauts | Peut laisser de l’espace vide |
lvh |
La plus grande hauteur possible | Je vise une couverture maximale de l’écran | Peut masquer du contenu quand les barres du navigateur sont visibles |
dvh |
La hauteur dynamique réellement disponible | Je veux coller à l’espace visible en temps réel | Peut se recalculer pendant l’usage |
Si je dois résumer brutalement : svh protège la stabilité, lvh favorise le plein écran maximal, et dvh sert l’adaptation immédiate. Ce trio suffit déjà à couvrir la majorité des cas concrets, surtout sur les interfaces mobiles.
Les cas où dvh améliore vraiment l’interface
Je réserve dvh aux éléments où la hauteur visible est une contrainte UX réelle, pas juste un effet visuel. Les bons candidats sont assez faciles à reconnaître : tout ce qui doit rester lisible, interactif et cadré dans la fenêtre visible du navigateur.
Les sections d’accueil en plein écran
Pour une hero section, min-height: 100dvh fonctionne souvent mieux que height: 100vh. La section garde un aspect plein écran, mais elle s’ajuste si l’interface du navigateur occupe une partie de l’espace. C’est simple, net, et bien plus robuste sur mobile qu’une hauteur rigide.
.hero {
min-height: 100dvh;
display: grid;
place-items: center;
}Les modales, panneaux et feuilles mobiles
Pour une modale ou une bottom sheet, dvh aide à garder l’ensemble visible sans forcer l’utilisateur à scroller dans un conteneur trop grand. J’aime mieux associer cette approche à overflow-y: auto qu’à une hauteur fixe, parce qu’une modale trop haute devient vite pénible dès que le clavier apparaît.
.modal {
max-height: 100dvh;
overflow-y: auto;
}Lire aussi : CSS Grid - Maîtrisez la grille pour des layouts parfaits
Les zones de lecture qui doivent rester accessibles
Dans certaines applications, une zone de contenu doit garder son équilibre même quand la barre d’adresse bouge. Pensez aux écrans de connexion, aux formulaires courts, aux assistants en étapes ou aux vues de chat. Dans ces cas, dvh réduit les surprises et évite qu’un bouton d’action se retrouve hors champ.
Le vrai bénéfice n’est pas seulement esthétique : il s’agit de réduire la friction au moment où l’utilisateur agit. Et dès qu’on parle d’action, les détails de mise en page deviennent plus importants que les effets visuels.
Les erreurs que je vois le plus souvent
Le problème avec une unité utile, c’est qu’on finit vite par l’appliquer partout. C’est rarement une bonne idée. Voici les erreurs que je croise le plus souvent en intégration front.
- Utiliser
height: 100dvhsur un bloc qui contient du contenu variable au lieu demin-height. - Oublier de prévoir le scroll interne sur une modale ou un panneau trop haut.
- Remplacer tous les usages de
vhsans vérifier si la stabilité visuelle n’était pas justement recherchée. - Ne pas tester le rendu avec la barre d’adresse visible, puis cachée, puis en rotation paysage.
- Ignorer le clavier virtuel sur les formulaires, alors que c’est souvent là que l’interface se dégrade le plus.
Mon conseil est pragmatique : si l’élément doit grandir, utiliser min-height est souvent plus sûr que height. Si l’élément doit rester dans un cadre strict, alors il faut prévoir le débordement et l’interaction avec le scroll. C’est cette distinction qui évite la majorité des bugs visibles.
L’intégrer proprement sans casser l’existant
Quand je dois introduire cette unité dans un projet déjà en production, je privilégie une approche progressive. Le plus simple est de partir d’un fallback raisonnable, puis de surcharger avec dvh uniquement quand le navigateur le comprend.
.fullscreen-panel {
min-height: 100vh;
}
@supports (height: 100dvh) {
.fullscreen-panel {
min-height: 100dvh;
}
}Ce pattern reste lisible, facile à maintenir, et compatible avec une base de code qui n’a pas été pensée autour des nouvelles unités de viewport. Je l’utilise volontiers quand je veux corriger une section précise sans rouvrir toute la mise en page.
Dans les cas plus sensibles, j’ajoute aussi une logique de contrainte plutôt qu’une hauteur absolue. Par exemple, un panneau peut combiner max-height: 100dvh avec du scroll interne et, si nécessaire, des espacements liés aux zones sûres de l’appareil. Cette approche est plus robuste qu’une hauteur figée qui casse dès que l’environnement change.
La règle à garder en tête est simple : plus l’interface dépend de la zone visible, plus le dimensionnement dynamique a du sens. Plus elle dépend du contenu, plus il faut éviter de l’enfermer dans une hauteur unique.
La règle pratique que j’applique avant de livrer
Avant de valider un écran, je me pose toujours la même question : est-ce que je veux que ce bloc suive l’espace visible, ou est-ce que je veux qu’il reste stable pendant la session ? Si la réponse est “suivre”, je pars sur dvh. Si la réponse est “rester stable”, je regarde plutôt svh ou une mise en page moins dépendante du viewport.
En pratique, j’utilise dvh pour les écrans d’accueil, les modales et les panneaux mobiles ; svh quand je veux éviter les sauts ; et lvh uniquement quand je cherche le plus grand écran possible sans me soucier des barres du navigateur. Ce choix simple me fait gagner du temps, parce qu’il colle à l’usage réel au lieu de suivre une logique purement théorique.
Si vous ne devez retenir qu’une chose, retenez celle-ci : la bonne unité n’est pas celle qui semble la plus moderne, c’est celle qui correspond à l’expérience que vous voulez vraiment offrir. Pour un plein écran mobile propre, dvh est souvent le meilleur point de départ, mais le rendu final dépend toujours du contexte, du contenu et du niveau de stabilité attendu.
