Standards du Web : comprendre HTML, CSS et la validation
Verdict : pour un site neuf, écrivez du HTML conforme au standard vivant, utilisez CSS pour la présentation et validez les deux avant la mise en ligne. XHTML 1.0 reste une archive utile pour comprendre l’ancien Web, pas une base de départ.
Sommaire
Le mot "standard" désigne ici une spécification partagée, pas un badge ni une promesse commerciale. La bonne démarche consiste à nommer la règle visée, contrôler le document envoyé et lire le résultat avant de décider quoi corriger.
Pour un premier contrôle, utilisez Nu Html Checker pour le HTML et le validateur CSS du W3C pour les feuilles de style. Les deux réponses deviennent utiles quand elles restent attachées à l’entrée exacte et au profil demandé.
Structure, présentation et transport ne jouent pas le même rôle
HTML décrit la structure et le sens : titres, paragraphes, liens, formulaires et relations entre les éléments. CSS décrit l’apparence, les dimensions et la disposition. HTTP transporte la ressource et l’URL permet de la retrouver. Comprendre le trajet d’une requête HTTP aide à isoler ce type de problème. Séparer ces rôles facilite la correction : une erreur de structure se traite dans le HTML, une règle de présentation dans CSS, un problème de ressource dans la réponse HTTP ou l’URL.
Le HTML Living Standard est la référence courante du langage HTML. Les recommandations WCAG ajoutent des exigences d’accessibilité sur la perception, l’utilisation et la compréhension des contenus. Une URL stable, une structure claire et un contraste lisible répondent donc à des questions différentes, même lorsqu’elles concernent la même interface.
Un standard commun réduit les interprétations propres à un navigateur ou à un fournisseur et donne un vocabulaire précis pour corriger un document.
Pourquoi XHTML 1.0 a marqué son époque
XHTML 1.0 reformulait HTML 4 comme une application XML 1.0. La recommandation demandait un document bien formé : balises fermées, noms en minuscules et attributs entre guillemets. La page du W3C indique une recommandation publiée en 2000, révisée en 2002, puis remplacée le 27 mars 2018.
L’ancien CyberSDF déclarait XHTML 1.0 Strict et CSS2 dans son pied de page, avec deux badges liés aux validateurs. Ces images documentaient une pratique de l’époque. Elles correspondaient à une spécification, une version et un document précis, pas à un certificat permanent de qualité.
Le billet du 25 mars 2005, signé Laurent, critiquait les agences qui reproduisaient sur le Web les méthodes de la mise en page papier : tableaux utilisés comme cadres, images placées au pixel près et optimisation pour un navigateur ou une résolution unique. L’idée qui reste valable est la séparation entre structure et présentation, car elle facilite l’évolution d’une interface. Le choix de XHTML 1.0, lui, appartient à cette histoire.
Le standard vivant décrit aussi une syntaxe XML. Pour commencer un document HTML, le choix pratique reste la syntaxe HTML courante, avec une validation adaptée au document réellement envoyé.
XHTML 1.0 éclaire l’histoire de la conformité, tandis que le HTML courant constitue le point de départ adapté à un nouveau site.
Une validation répond à une question précise
Un validateur compare le document aux règles déterministes d’une spécification et signale les écarts qu’il sait reconnaître. Dans le HTML, cela peut faire apparaître un identifiant utilisé deux fois ou l’absence d’un attribut alt. Dans CSS, le service vérifie la grammaire et les valeurs connues.
Le validateur CSS sépare les erreurs des avertissements. Une erreur appelle une correction dans le code. Un avertissement appelle une lecture du cas et une décision documentée. Demandez le rapport complet, pas seulement une image verte ou un texte "valide" copié dans un pied de page.
La limite à retenir est simple : un résultat valide confirme les règles que l’outil sait vérifier, puis l’usage se contrôle aussi au clavier, au zoom et avec les technologies d’assistance, comme le rappelle l’aperçu W3C de l’évaluation de l’accessibilité.
La validité donne une réponse fiable sur la conformité vérifiable du code, pas une appréciation générale de l’interface.
Un contrôle HTTP avec quatre fichiers
Le 17 septembre 2026, un contrôle a envoyé quatre petits fichiers par requête HTTP directe aux deux services : un HTML conforme, une variante avec une image sans alt et deux fois id="contenu", une feuille CSS conforme avec color: #222 et background-color: #fff, puis une variante avec color: not-a-color. Les quatre réponses ont renvoyé HTTP 200.
curl -H 'Content-Type: text/html; charset=utf-8' \
--data-binary @test-html-valide.html \
'https://validator.w3.org/nu/?out=json'
curl --get --data-urlencode text@test-css-valide.css \
--data 'output=json' \
'https://jigsaw.w3.org/css-validator/validator'Nu Html Checker a renvoyé la version 26.9.16. Le fichier HTML conforme a produit 0 message. La variante fautive a produit 2 erreurs et 1 information : l’alternative absente, l’identifiant dupliqué et l’emplacement de la première occurrence. Le validateur CSS a déclaré la première feuille valide avec 0 erreur et 0 avertissement sur le profil css3. La variante fautive a produit 1 erreur et 0 avertissement pour la valeur not-a-color.
La correction commence par le premier message qui désorganise le document, puis le contrôle repart avec la même entrée. Cette méthode évite de confondre un symptôme secondaire avec la cause lisible dans le rapport.
Un test exploitable associe l’entrée, le service, le profil et le résultat afin qu’une correction puisse être rejouée.
Lire un résultat avant de toucher au code
Un message sur alt indique l’absence d’un attribut, alors que la qualité de l’alternative se lit dans le rapport entre l’image et l’information à transmettre. Une erreur CSS indique une valeur inconnue, puis la feuille demande une vérification du contraste, de la lisibilité et du comportement à 200 % de zoom.
Le même principe vaut pour les liens, les formulaires et les titres. Une structure sémantique aide la lecture, un libellé décrit l’action et une mise en page qui se replie conserve l’accès au contenu. Ces contrôles se complètent au lieu de se remplacer.
Pour corriger efficacement, gardez le document envoyé, la réponse JSON et la date de l’appel. Lorsqu’un message disparaît après une modification, relisez le code autour de la correction : un rapport vide indique l’état de cette entrée, pas la qualité de toutes les autres pages.
Le rapport indique quoi corriger dans l’entrée mesurée ; la relecture indique si cette correction sert vraiment la personne qui utilise l’interface.
Ce qu’un cahier des charges doit nommer
Demandez la spécification visée : HTML courant, profil CSS, version d’un composant ou règle interne clairement nommée. Ajoutez l’URL, le fichier ou le fragment contrôlé, la version du service, la date du contrôle et le traitement attendu pour chaque erreur. Une capture de badge ne contient pas assez d’information pour reprendre une correction.
La demande peut ensuite préciser la structure HTML, les règles CSS maintenables, les URL stables, les navigateurs et les appareils concernés. Pour l’accessibilité, nommez les parcours à vérifier au clavier, au zoom et avec les technologies utilisées par votre public. Le prestataire doit rendre un rapport lisible et expliquer les corrections, pas seulement annoncer un résultat.
Le billet de Laurent en 2005 garde une portée pratique : une interface conçue pour une seule résolution ou un seul navigateur vieillit mal. Les techniques ont changé, mais le critère se vérifie encore en demandant des environnements nommés et un résultat observable.
Pour élargir la décision, consultez les critères pour choisir un logiciel selon une tâche vérifiable, puis parcourez les logiciels utiles à comprendre et à choisir.
Une promesse de conformité devient vérifiable quand le prestataire nomme la spécification, l’entrée, l’outil, le périmètre contrôlé et le traitement des erreurs.