code Formateur et validateur HTML / XML star

Comment ça fonctionne

Le formateur parcourt votre balisage et suit la profondeur d'imbrication au fur et à mesure : chaque balise ouvrante fait monter le compteur de profondeur d'un niveau, chaque balise fermante correspondante le fait redescendre. Chaque ligne de sortie reçoit un nombre d'unités d'indentation proportionnel à sa profondeur actuelle — une balise à un niveau de profondeur reçoit une unité d'indentation, une balise à quatre niveaux de profondeur en reçoit quatre, et ainsi de suite. Les nœuds de texte, les commentaires et les attributs héritent de la profondeur de l'élément qui les contient, de sorte que le résultat final reflète visuellement la structure arborescente réelle du document au lieu d'un mur de texte ininterrompu.

Par exemple, une ligne unique compacte comme <ul><li>A</li><li>B</li></ul> revient sous la forme <ul> au niveau supérieur, avec <li>A</li> et <li>B</li> chacun mis en retrait d'un niveau, et la balise fermante </ul> revenue au niveau supérieur — trois lignes au lieu d'une, et la profondeur de chacune immédiatement lisible à partir de sa seule indentation. Les éléments vides comme <br> ou <img> n'augmentent jamais le compteur de profondeur, puisqu'ils n'ont pas d'enfants à imbriquer.

Bon à savoir

Choisissez le mode XML et l'analyseur est strict : toute violation de bonne formation — une balise non fermée, une imbrication incorrecte, un caractère invalide — est signalée avec un message d'erreur précis au lieu d'être corrigée silencieusement. Choisissez le mode HTML et l'outil exécute plutôt une vérification d'équilibre des balises au mieux, car les navigateurs eux-mêmes analysent le HTML avec souplesse et il n'existe pas d'état « invalide » strict équivalent à détecter. Cette différence reflète un vrai écart entre les deux formats : la spécification XML exige qu'un document soit bien formé ou soit rejeté purement et simplement, sans terrain d'entente, alors que le HTML5 a été délibérément conçu pour que de petites erreurs de rédaction — comme une balise fermante oubliée — ne cassent pas la page. Cette tradition permissive explique aussi pourquoi <br/> est obligatoire en XML alors que <br> et <br/> sont tous deux valides et interchangeables en HTML.

Cela dépasse largement le simple nettoyage d'un balisage écrit à la main. Du HTML minifié récupéré depuis une page en ligne, une réponse d'API XML renvoyée sur une seule ligne dense, ou un fichier de configuration exporté sans aucune mise en forme — tous deviennent bien plus lisibles, et il devient bien plus facile d'y repérer une balise mal placée, une fois l'indentation basée sur la profondeur appliquée. Comme l'indentation est recalculée à partir de la structure analysée plutôt que copiée depuis l'entrée, le résultat est cohérent quelle que soit l'incohérence de l'espacement d'origine.