Les layout du web - Partie 1 : Histoire.

Nous sommes en 2019. Le secteur d’activité principal de 7 des 10 plus grandes entreprises au monde est la technologie de l’information. Plus de la moitié des humains sont connectés à Internet. Les technologies HTML et CSS ont plus de 20 ans de maturité, et le navigateur standard d’aujourd’hui supporte la technologie nécessaire pour faire vivre des expériences de réalité virtuelle, visuelles et sonores convaincantes.

Et, malgré tout cela, il n’est toujours pas facile d’aligner efficacement une grille imbriquée dans une autre en CSS. Que s’est-il passé ? Petit voyage dans le temps pour traverser les différentes méthodes de dispositions de pages web !

Le layout web “Holy Grail”

Le “Holy Grail” (ou Graal) – symbole de la légende arthurienne et nom d’une célèbre comédie des Monty Python – est également le nom donné à un « layout » (ou disposition) spécifique des éléments sur une page dans les débuts du développement web.

 

Cette disposition qui englobait le cas d’utilisation principal de beaucoup de plateformes web est composée de différentes parties, nommées :

• header, en haut de la page, utilisant la totalité de la largeur.
• footer, en bas de la page, utilisant la totalité de la largeur.
• menu, content et aside, divisant le centre de la page en 3 colonnes. Chacune utilise le reste de la hauteur de la page

Problématique

Le problème à résoudre était de faire que chacune des 3 colonnes centrales occupe la totalité de la hauteur. À une époque où le HTML et le CSS en étaient à leur débuts, la réponse la plus élégante à ce challenge n’était pas évidente. À un point que la quête de la solution était comparée à la recherche du Graal, d’où le nom du layout. Il était facile d’arriver, par exemple, au résultat suivant, où les colonnes n’atteignent pas le bas de la page :

 

La difficulté était de trouver un moyen d’écrire sa page de telle manière que le rendu soit à la fois bon dans tous les navigateurs de l’époque (qui, rappelons-le, avaient beaucoup plus de différences entre eux), et que le code soit sémantiquement correct et optimisé pour son indexation par les moteurs de recherche.

Les solutions existaient, mais n’étaient pas intuitives. Wikipédia possède un article sur le sujet (en anglais), et montre certaines des solutions les populaires pour résoudre ce problème. La solution la plus courante était certainement d’utiliser une <table> pour placer les éléments sur la page.

Histoire : Positionnement avec table, et “tableless”

Organiser sa page avec une table

La version 2.0 de la spécification HTML, sortie en fin 1995, décrivait l’utilisation de la balise <table> pour organiser des données tabulaires sous la forme d’un tableau.

L’utilisation principale de la balise a été très rapidement détournée, car les les développeurs se rendaient compte que celle-ci pouvait être utilisée pour placer facilement l’ensemble des éléments de leur page web sur l’écran ; une cellule par “partie” précédemment décrite.

Cette méthode de positionnement était devenue très populaire car simple à implémenter, mais présentait un désavantage majeur : celui d’être sémantiquement incorrect. C’est-à-dire d’utiliser un élément HTML pour y insérer des données que cet élément n’est pas censé contenir à la base.
Le coût de ce désavantage est non seulement une accessibilité réduite, mais surtout une incapacité des moteurs de recherche à comprendre correctement le contenu de la page, et par conséquent à recommander celle-ci lors d’une recherche.

Malgré cela, la simplicité de la compréhension et de l’implémentation de cette solution a propulsé la popularité de celle-ci (et je pense dans une certaine mesure contribué à la popularité de HTML même, résultant de la facilité à organiser de l’information dans une page ; que ce soit depuis un éditeur de texte classique ou un WYSIWYG HTML, qui a également commencé à faire son apparition).

Organiser sa vue avec du CSS

L’utilisation des tables était tellement prévalante, que le fait-même de ne pas utiliser une table pour organiser sa page web porte un nom et une page Wikipédia : le « tableless » web design (en anglais).

La mise en page par l’utilisation d’une table était devenue ordinaire, mais l’arrivée de nouvelles technologies dans les navigateurs a commencé à faire changer les habitudes. La prise en charge de nouveaux standards tels que CSS2 par les navigateurs, ainsi que le redesign de certains des grands sites de l’époque, ont popularisé la séparation entre le contenu et l’affichage (ou design) d’une plateforme web : un fichier HTML contenant le texte de la page (contenu), et un ou plusieurs fichiers CSS contenant les directives pour l’afficher correctement (affichage).

Les avantages de remplacer les balises table par des éléments sémantiquement adaptés selon la situation étaient nombreux :

• Optimisation pour les moterus de recherche (SEO) : Les robots de moteurs de recherche pouvaient plus facilement comprendre quel était le contenu important d’une page, et comment celle-ci était organisée.
• Fonctionnalités : L’élément HTML table n’a que très peu de fonctionnalités agissant sur le placement du contenu.
• Accessibilité : L’écran de bureau n’était déjà pas le seul moyen de parcourir une page web. Les lecteurs d’écran (destinés par exemple aux personnes malvoyantes, ou dyslexiques) et les téléphones portables – dont la popularité était en hausse – appréciaient eux-aussi de comprendre l’organisation de l’information sur une page pour fonctionner correctement.
• Bande passante : La taille d’un fichier HTML ainsi que le taux de transfert réseau moyen de l’époque étaient plusieurs ordres de magnitude plus faibles que ceux d’aujourd’hui. Une table en HTML demande un nombre de caractères particulièrement élevé (par rapport aux autres structures). L’abandon des tables a réduit la taille moyenne des pages, et par conséquent réduit le temps de téléchargement de celles-ci.

Quelques techniques

Les techniques pour arriver à produire un layout “Holy Grail” en CSS sont nombreuses, déjà en CSS2. Rappelons le problème principal : le but est de diviser le centre de la page en 3 colonnes, et que chacune d’entre-elles remplisse la totalité de la hauteur disponible, peu importe la taille de leur contenu. Le but n’est pas d’énumérer toutes les techniques ici, mais nous allons nommer une ou deux des plus populaires.

display: table

La première solution arrivée avec les nouveaux standards CSS est très naturellement d’essayer de reproduire le comportement précédent. Ainsi, il est évident que la propriété display: table allait devenir devenue populaire. Elle fait s’afficher un élément comme si il s’agissait d’une table. Il suffisait de reproduire la même structure que la table que l’on utilisait précédemment, et de remplacer ses éléments (table, tr, td, …etc) par leurs propriétés CSS display « équivalentes » (table, table-row, table-column, …etc). Cette solution, bien que fonctionnelle dans le sens où elle évite l’utilisation d’élément table (et peut donc être sémantiquement correcte), n’est pas optimale. Elle garde certains des désavantages de l’utilisation de table, à savoir la quantité de code nécessaire à son affichage.

float

La propriété CSS float permet de placer facilement un élément à gauche ou à droite dans son conteneur. Bien que simple en apparence, cette propriété ne répond pas directement au problème, et cache des complexités. À l’époque, un article de blog a attiré beaucoup d’attention en montrant un exemple pratique de leur utilisation. La solution proposée est fonctionnelle, mais requiert un code conséquent et peu intuitif.

Bottom padding

Il est possible d’allonger la place qu’occupe un élément en lui spécifiant une ou des propriétés CSS padding. Cela crée un espace d’un côté de l’élément qui n’a comme but que de rester « vide ». Cet espace s’insère entre le contenu de l’élément et sa bordure. La technique était donc d’ajouter cet espace vers le bas des colonnes afin qu’il colore l’espace vide. Cependant, il était impossible de savoir quelle est la taille exacte d’espace à ajouter pour chaque colonne.

C’est là qu’intervient la propriété margin, qui définit la taille de la marge entre l’élément courant et les autres éléments de la page. Ainsi, il est facile d’ajouter de l’espace vide… ou dans ce cas de figure, d’en enlever. En effet, il est possible d’assigner une valeur négative à cette propriété. On utilisait donc une marge négative d’une valeur égale au padding afin que l’élément colore la page jusqu’en bas sans prendre plus de place. Ainsi, le code pour des colonnes de classe column dans un conteneur de classe wrapper était le suivant :

 

Encore une fois, il était possible d’arriver au résultat visuel voulu, mais au prix d’une solution relativement capillotractée.

JavaScript

Etant donné que JavaScript peut s’exécuter à tout moment et a accès à tous les éléments de la page, il est toujours possible de calculer et d’ajuster leur taille « mathématiquement ». Cette solution est cependant malheureusement accompagnée d’un temps de latence supplémentaire, et de performances réduites. Elle n’est donc – à priori – jamais optimale pour attaquer un problème d’agencement d’éléments sur une page. Bien que déconseillée, il me semblait incomplet de ne pas mentionner cette horrible méthode.

Nous avons fait un fait un tour de la problématique principale et des différentes solutions historiques. Nous verrons quelles sont les méthodes de nos jours pour faire face à ces problèmes dans l’article suivant !