Taille de l'écran, de la fenêtre et de la page en JavaScript : 5 erreurs fatales et comment les éviter

La taille compte : pourquoi les scripts "cassent" la mise en page

Imaginez : vous créez un site adaptatif parfait, vous le testez sur votre ordinateur portable — tout fonctionne à merveille. Vous le lancez sur la tablette d'un client — bug. Les éléments se chevauchent, la fenêtre modale sort de l'écran, et une galerie refuse carrément de s'ouvrir. Cela vous dit quelque chose ?

Le plus souvent, la racine du mal est une mauvaise récupération des dimensions de l'écran, de la fenêtre du navigateur ou de la page elle-même. La question "Get the size of the screen, current web page and browser window" sur Stack Overflow a recueilli des centaines de milliers de vues. Et ce n'est pas un hasard : même les développeurs expérimentés confondent screen.width, window.innerWidth et document.documentElement.clientWidth.

Dans cet article, nous allons analyser les 5 erreurs les plus courantes commises par les débutants (et pas seulement) lors du travail avec les dimensions en JavaScript. Vous obtiendrez non seulement de la théorie, mais aussi des solutions prêtes à l'emploi et éprouvées pour des problèmes réels.

Top 5 des erreurs lors du travail avec les dimensions en JavaScript

Erreur n°1 : Utiliser screen.width au lieu de window.innerWidth

C'est un classique. Le développeur veut connaître la largeur de la zone d'affichage (viewport) et écrit :

// ❌ Incorrect\nconst viewportWidth = screen.width;\nconsole.log(viewportWidth); // 1920 (mais ce n'est pas le viewport !)\n

Où est le piège ? screen.width retourne la largeur physique du moniteur en pixels. Elle ne change pas si vous réduisez la fenêtre du navigateur ou ouvrez les outils de développement. Alors que window.innerWidth est la largeur de la zone d'affichage (viewport), c'est-à-dire la partie de la fenêtre où le contenu est affiché.

Quand cela casse le site : Si vous calculez des blocs adaptatifs avec screen.width, le site ne se réorganise pas lorsque vous ouvrez DevTools ou réduisez la fenêtre. L'utilisateur voit soit du vide, soit des éléments qui se chevauchent.

// ✅ Correct\nconst viewportWidth = window.innerWidth;\nconsole.log(viewportWidth); // Largeur actuelle de la zone visible\n

Erreur n°2 : Oublier le défilement (scrollbar)

Deuxième piège le plus courant. Le développeur récupère la hauteur de la fenêtre et tente de placer un élément exactement au milieu :

// ❌ Incorrect\nconst windowHeight = window.innerHeight;\nelement.style.top = windowHeight / 2 + 'px';\n

À première vue, tout est correct. Mais si le contenu est plus long que l'écran et qu'il y a une barre de défilement, window.innerHeight inclut sa hauteur. En conséquence, l'élément peut "sortir" de la limite inférieure de la zone visible.

Solution : Utilisez document.documentElement.clientHeight — il retourne la hauteur du viewport sans tenir compte de la barre de défilement.

// ✅ Correct pour le positionnement dans la zone visible\nconst viewportHeight = document.documentElement.clientHeight;\nelement.style.top = viewportHeight / 2 + 'px';\n

\n

Retenez la règle : window.innerWidth/innerHeight — avec la barre de défilement. document.documentElement.clientWidth/clientHeight — sans la barre de défilement. Choisissez selon la tâche.

\n

Erreur n°3 : Confondre la taille de la fenêtre et la taille de la page

Vous voulez savoir jusqu'où l'utilisateur a défilé et vous calculez la hauteur totale de la page :

// ❌ Incorrect\nconst pageHeight = window.innerHeight;\nconsole.log(pageHeight); // Ce n'est pas la hauteur de la page !\n

window.innerHeight est la hauteur de la fenêtre, pas du document. Pour obtenir la hauteur totale de la page (y compris la partie défilée), il faut utiliser document.documentElement.scrollHeight.

Exemple concret : Vous créez un fil infini (infinite scroll). Si vous utilisez window.innerHeight pour déterminer le moment du chargement de nouveaux posts, le script s'exécutera une seule fois et ne se