Formateur HTML

La plupart du HTML tolère qu'un formateur réorganise librement ses espaces blancs — une indentation supplémentaire entre éléments de bloc comme `<div>` et `<p>` n'a aucun effet visible, car les navigateurs fusionnent les séquences d'espaces blancs entre ces éléments lors du rendu. Trois cas précis brisent complètement cette hypothèse : le contenu dans `<pre>` rend chaque espace et saut de ligne littéralement, exactement comme écrit ; `<textarea>` traite son contenu de la même façon car il est censé reproduire un texte exact éditable par l'utilisateur ; et tout élément portant `white-space: pre` en CSS hérite du même traitement littéral. Un formateur qui réorganise les espaces blancs dans l'un de ces blocs change ce que la page affiche réellement, pas seulement l'apparence du code source — c'est pourquoi ce formateur les laisse complètement intacts plutôt que d'appliquer ses règles d'indentation habituelles.

Les éléments en ligne situés directement à côté de texte sont un cas plus subtil : un espace entre deux éléments en ligne est parfois visuellement significatif — l'espace entre deux mots enjambant des balises `<span>` séparées, par exemple — donc le formateur est délibérément prudent avec le contenu en ligne, préférant laisser l'espace blanc ambigu tel quel plutôt que de risquer d'effondrer un espace qui faisait un vrai travail visuel.

Une page assemblée comme un seul fichier HTML intègre couramment son propre CSS dans un bloc `<style>` et son propre JavaScript dans un bloc `<script>`, et un formateur qui ne comprend que les balises HTML laisserait ce code intégré comme un bloc non formaté ou, pire, le saboterait en traitant les accolades et points-virgules comme de la syntaxe HTML. Transmettre le contenu de ces blocs à un vrai analyseur CSS et un vrai analyseur JavaScript respectivement signifie que tout le fichier — balisage, styles et comportement ensemble — revient formaté de façon cohérente, plutôt que seulement la structure HTML externe.

Les navigateurs sont construits avec un modèle de récupération d'erreur conçu spécifiquement pour rendre quelque chose de raisonnable même à partir d'un balisage gravement malformé — une balise non fermée, un guillemet manquant, des éléments imbriqués dans un ordre invalide — car le web a des décennies de HTML imparfait en production qui doit encore s'afficher. Un formateur ne peut pas adopter cette même indulgence : pour reformater un document, il doit construire une compréhension structurelle précise de ce qui est imbriqué dans quoi, et un document avec des balises réellement déséquilibrées n'a pas de structure correcte unique à récupérer. C'est pourquoi une page s'affichant parfaitement normalement dans un navigateur peut quand même être rejetée par ce formateur — le navigateur a silencieusement réparé l'ambiguïté à sa façon, tandis qu'un outil essayant de reformater correctement doit signaler l'ambiguïté plutôt que de deviner.

Un fichier qui échoue au formatage n'est très souvent pas du HTML cassé du tout, mais un template — Handlebars, Jinja, Blade, EJS ou similaire — mélangeant directives de template et balisage, produisant un document qui n'est pas du HTML autonome valide et n'a jamais besoin de l'être. Le template ne devient du vrai HTML bien formé qu'après l'exécution de son moteur de template et la substitution des données réelles. Formater la sortie rendue, capturée après traitement par le moteur de template — depuis « Voir le code source » d'un navigateur, par exemple — évite complètement cela, cette sortie étant du vrai HTML sans aucune syntaxe de template restante.