À l’issue de 3 jours de formation sur les bases du HTML et de CSS, la stagiaire déclare:
en fait, on ne devrait pas utiliser Photoshop pour faire un site Web, mais partir directement du DOM.
Pardonnez mon immodestie, mais à ce moment précis, je me suis senti comme Obi Wan Kenobi réalisant qu’il vient de sauver le jeune Skywalker du côté obscur de la Force.
Réflexion d’autant plus remarquable qu’elle provient d’une personne en pleine reconversion professionnelle, sans aucune formation informatique, et qui commence à peine à découvrir l’envers du décor du Web. Qu’elle ait compris l’enjeu et l’intérêt d’une notion aussi abstraite que le Document Object Model, c’est le meilleur signe que j’avais fait le bon choix, en abordant le sujet par sa face la plus ardue, mais la plus payante: le côté lumineux du HTML, le DOM.
J’ai hésité à accepter cette demande de formation, pour être honnête. Je n’ai pas développé de site depuis… ouh laaaaa, et je ne me sentais pas légitime pour former quelqu’un au HTML, et encore moins à CSS. Mais par les temps qui courent, on ne refuse pas du boulot; et j’ai disséqué suffisamment de code HTML et CSS, en tant qu’auditeur accessibilité, pour avoir quand même une bonne idée du sujet. Et me voilà donc face à la slide blanche: par quoi commencer?
N’ayant jamais donné de formation sur ce thème, j’ai naturellement regardé comment s’y prennent les autres. Mais là, déception: les tutos et cours en ligne les plus populaires dans les moteurs de recherche attaquent tous directement avec les balises, expliquant que celle-ci fait des boîtes, celle-là fait des boutons, et la troisième tire des traits. Cette approche a la séduction de la simplicité, mais elle vous entraîne effectivement du côté obscur du HTML. Celui qui vous fait croire que commencer par dessiner dans Photoshop est la bonne approche.
Cette façon de présenter le HTML ne dit pas ce qu’il se passe réellement. On peut voir le HTML comme un langage de description de contenu, ce qu’il a peut-être été à ses débuts, je ne sais pas, et je m’en fous. Mais quand on y réfléchit réellement, le HTML n’est autre qu’un langage d’initialisation du fameux DOM: le Document Object Model.
Car voici ce qu’il se passe dans le navigateur lorsqu’il reçoit la réponse HTTP du serveur (je schématise, hein). Contrairement à ce que l’on pense souvent, il n’écrit pas directement le contenu des balises à l’écran. Il interprète les balises pour construire un arbre hiérarchique d’objets (au sens informatique) qui sont autant d’éléments HTML, avec des propriétés et des nœuds texte. Ces éléments constituent les nœuds de l’arbre, liés entre eux par des relations hiérarchiques de type parent-enfant.
On parle bien ici de « document », et non de page (terme impropre, mais passons). Pour comprendre cette distinction, prenons cette analogie: les contenus d’un livre ne sont pas l’encre sur le papier. C’est l’information que cette encre et ce papier transmettent, via un certain agencement, et qui a une représentation théorique, le « document HTML » dans notre cas.
Une fois le DOM créé, le navigateur est prêt à en afficher les constituants. Il va déterminer leur position dans la page (en calculant le flow, le flux, en français, c’est-à-dire la façon dont les éléments « s’empilent » en fonction de leur type et leur position dans l’arbre DOM); et leur apparence, en appliquant des règles de style CSS qu’il va trouver dans la page, le navigateur, ou les feuilles de style utilisateur.
Ce n’est qu’alors que la « page » peut s’afficher. Contrairement à ce que laisse penser la définition erronée du HTML (« langage de description de contenu »), la page affichée n’est qu’un sous-produit du DOM, qui est le véritable résultat du HTML.
Et cette nuance change tout.
Déjà, il faut comprendre qu’un lecteur d’écran, un robot d’indexation, et quantité d’autres agents utilisateurs, n’ont que faire de la restitution « graphique » du HTML: ils s’appuient sur le DOM pour comprendre le contenu et sa structure, éventuellement le remodeler, et le restituer sous une forme particulière (vocale, Braille, données d’indexation, etc.). Un HTML mal formé, malgré toute la bonne volonté du navigateur, c’est un DOM potentiellement bancal, qui peut donner à l’agent utilisateur une information différente de celle voulue par l’auteur. On ne peut donc pas se fier à ce que l’on « voit » à l’écran, pour savoir comment le document pourra être interprété par un moyen de lecture non graphique.
Ensuite, cela oblige à reconsidérer la légèreté avec laquelle on ajoute des balises comme des <div>
ou des <span>
, dans le meilleur des cas (le pire étant de mettre des <blockquote>
pour indenter, des <h1>
pour écrire gros, et toutes ces horreurs, mais comme vous lisez ce blog, j’ose croire que vous savez déjà que c’est le Mal). Insérer une <div>
n’a pas juste pour effet de « dessiner » une boite transparente, que l’on va pouvoir colorier et triturer à loisir. Ce n’est pas gratuit. On crée effectivement une nouvelle branche, chargée de tous les éléments contenus dans notre <div>
. Une soupe de <div>
, ce n’est pas juste quelques octets en trop dans le HTML. C’est une structure pesante, inutile, qui va alourdir toutes les opérations de reflow et repaint. Et elles sont légions! Dès que l’utilisateur va scroller, afficher un menu déroulant, saisir du texte dans un champ, zoomer, ou redimensionner sa fenêtre; ou que votre code JavaScript (jQuery, cache-toi) va ajouter, enlever ou déplacer un élément; le DOM sera recalculé, et ré-affiché en ré-appliquant les règles de style, en repartant du début. Comprendre le DOM et son fonctionnement est donc un prérequis essentiel pour créer des pages performantes et économes en ressources.
Enfin cela permet de limiter les éventuelles divergences de rendu aux seuls réels bugs et particularismes des navigateurs. Un HTML bien choisi et bien formé sera au plus proche de l’idéal d’interopérabilité que l’on vise avec le Web. Une fois ceci bien intégré, le reste devient beaucoup plus simple.
Comprendre le fonctionnement du navigateur, et donc le DOM et ses implications, est par conséquent la véritable base, pour faire des pages robustes, interopérables, performantes, économes, accessibles, et indexables. Cela permet aussi de mieux comprendre les apparentes bizarreries du HTML: pourquoi les espaces sont ignorés, pourquoi les balises sont imbriquées comme ci et pas comme ça, pourquoi il faut fermer les balises et faire un code bien formé… Une fois cela acquis, des concepts aussi intimidants que l’héritage de propriétés, l’outline HTML5, le flux ou les restitutions alternatives; et par rebond, en CSS, la cascade, le modèle de boite, la fusion des marges et la spécificité, deviennent tout de suite plus abordables. On trouve rarement ces notions dans les formations étiquetées « débutant » — et pour cause, je serais bien en peine de les expliquer sans me référer constamment au DOM et à sa structure. D’ailleurs, ma stagiaire les a absorbés avec une réconfortante facilité. J’en veux pour preuve une autre réflexion, une fois que j’ai présenté le combinateur CSS « + » (frère adjacent): « du coup, ça sert à rien de mettre des classes de style pour styler le premier paragraphe! »
. Absolument. Mettre une classe juste pour ça est un exemple typique de technique maligne, insidieuse, qui fait glisser doucement votre code vers le côté obscur.
J’aurais sans doute pleuré beaucoup moins de larmes de sang, sur des pages montées en dépit du bon sens, si l’on m’avait expliqué tout cela à mes débuts il y a 15 ans (et j’aurais sans doute moins de poils blancs dans ma barbe!).
Si je garde mes slides pour moi pour le moment (les nuits passées dessus justifient que je les recycle!), je vous partage néanmoins une collection toute personnelle de liens vers des spécifications, ressources et références, qui devraient vous mettre sur les bons rails.
Si je vous ai donné la curiosité d’en savoir plus, et de reconsidérer la façon dont vous voyez le HTML, alors, j’aurai fait le Bien. Bienvenue du côté lumineux du HTML.
Amen. Même si parfois c’est plus délicat de passer par un DOM aux petits oignons (surtout avec des tonnes de JS), in fine, on est toujours gagnant sur le long terme : accessibilité, qualité, maintenabilité, etc.
A noter, de bonnes ressources pour comprendre d’autres aspects :
– http://videos.paris-web.fr/2011/ParisWeb14_Anthony%20Ricaud_DailyMotion.mp4 (une conf’ d’Antony Ricaud sur comment fonctionne un navigateur, avec un bon passage sur le DOM)
– How browsers work : http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ (en anglais) : c’est dense mais cela permet de mieux comprendre l’incroyable machinerie derrière un navigateur.
Super liens, merci! Dans la même veine, mais avec un focus sur l’accessibilité, la conf de l’ami Karl Groves à PW2013: http://www.paris-web.fr/2013/conferences/wcag-412-understanding-dom-and-its-importance-for-accessibility-1.php