Vous n'utilisez peut-être pas (ou plus) le XHTML, mais lorsque vous écrivez du HTML, vous êtes peut-être plus influencé par le XHTML que vous ne le pensez. Vous écrivez très probablement du HTML à la manière de XHTML.

Qu'est-ce que la façon XHTML d'écrire du HTML, et qu'est-ce que la façon HTML d'écrire du HTML ? Voyons cela.

HTML, XHTML, HTML

Dans les années 1990, il y avait le HTML. Dans les années 2000, il y a eu le XHTML. Puis, dans les années 2010, nous sommes revenus au HTML. C'est une histoire simple...

Les dates approximatives des spécifications sont également révélatrices : HTML "1" 1992, HTML 2.0 1995, HTML 3.2 1997, HTML 4.01 1999 ; XHTML 1.0 2000, XHTML 1.1 2001 ; "HTML5" 2007.

Le XHTML est devenu populaire lorsque tout le monde croyait que le XML et ses dérivés étaient l'avenir. "XML tout court". Pour le HTML, cela a eu un effet profond et durable : celui de nous apprendre à l'écrire à la façon XHTML.

La façon XHTML d'écrire le HTML

La méthode XHTML est bien documentée, car XHTML 1.0 la décrit en détail dans sa section "Différences avec HTML 4" :

• Les documents doivent être bien formés.
• Les noms des éléments et des attributs doivent être en minuscules.
• Pour les éléments non vides, les balises de fin sont obligatoires.
• Les valeurs des attributs doivent toujours être citées.
• La minimisation des attributs n'est pas prise en charge.
• Les éléments vides doivent être fermés.
• Le traitement des espaces blancs dans les valeurs d'attributs est effectué conformément à XML.
• Les éléments de script et de style doivent comporter des sections CDATA.
• Les exclusions SGML ne sont pas autorisées.
• Les éléments ayant des attributs id et name, comme a, applet, form, frame, iframe, img et map, ne doivent utiliser que id.
• Les attributs ayant des ensembles de valeurs prédéfinies sont sensibles à la casse.
• Les références aux entités comme les valeurs hexadécimales doivent être en minuscules.

Cela vous semble-t-il familier ? À l'exception du balisage du contenu CDATA, ainsi que du traitement des exclusions SGML, vous suivez probablement toutes ces règles. Toutes ces règles.

Bien que le XHTML soit mort, nombre de ces règles n'ont jamais été remises en question. Certaines ont même été élevées au rang de "bonnes pratiques" pour le HTML.

C'est la façon XHTML d'écrire du HTML, et son impact durable sur le domaine.

La façon d'écrire du HTML

Une façon de nous ramener en arrière est de reformuler négativement les règles imposées par le XHTML. Faisons cela (sans la partie SGML, car HTML n'est plus basé sur SGML) :

• Les documents peuvent ne pas être bien formés.
• Les noms des éléments et des attributs peuvent ne pas être en minuscules.
• Pour les éléments non vides, les balises de fin ne sont pas toujours nécessaires.
• Les valeurs des attributs ne sont pas toujours citées.
• La minimisation des attributs est prise en charge.
• Les éléments vides n'ont pas besoin d'être fermés.
• Le traitement des espaces blancs dans les valeurs d'attributs n'est pas réalisé conforment à XML.
• Les éléments de script et de style n'ont pas besoin de sections CDATA.
• Les éléments ayant des attributs id et name ne peuvent pas utiliser uniquement id.
• Les attributs dont les valeurs sont prédéfinies ne sont pas sensibles à la casse.
• Les références aux entités comme les valeurs hexadécimales peuvent ne pas être uniquement en minuscules.

Supprimons les points ésotériques et ceux qui ne semblent pas pertinents. Il s'agit de la gestion des espaces blancs XML, des sections CDATA, du doublement des valeurs des attributs de nom, de la casse des ensembles de valeurs prédéfinis et des références d'entités en hexadécimal :

• Les documents peuvent ne pas être bien formés.
• Les noms des éléments et des attributs peuvent ne pas être en minuscules.
• Pour les éléments non vides, les balises de fin ne sont pas toujours requises.
• Les valeurs des attributs ne sont pas toujours citées.
• La minimisation des attributs est prise en charge.
• Les éléments vides n'ont pas besoin d'être fermés.

Si l'on fait abstraction de ces règles, on a beaucoup moins l'impression de travailler avec du XML, mais plutôt avec du HTML. Mais nous n'avons pas encore terminé.

"Les documents peuvent ne pas être bien formés" semble suggèrer qu'il serait acceptable que le code HTML soit invalide. Il était tout à fait cohérent que XHTML soit pointilleux sur la conformité de la forme en raison de sa gestion stricte des erreurs (par XML). Mais même si les documents HTML fonctionnent encore lorsqu'ils contiennent de graves problèmes de syntaxe et de conformité, il n'est pas utile, ni pour le professionnel ni pour notre domaine d'user et d'abuser de cette résilience. (J'ai déjà plaidé cette cause dans mon article "In Critical Defense of Frontend Development".

La façon HTML ne suggére donc pas que "les documents peuvent ne pas être bien formés". Il devrait également être clair que non seulement les balises de fin, mais aussi celles de début ne sont pas toujours nécessaires. Si nous reformulons et réorganisons, voici l'essentiel :

• Les balises de début et de fin ne sont pas toujours nécessaires.
• Les éléments vides n'ont pas besoin d'être fermés.
• Les noms des éléments et des attributs peuvent être en minuscules ou en majuscules.
• Les valeurs des attributs ne sont pas toujours entre guillemets.
• La minimisation des attributs est prise en charge.

Exemples

Comment cela se présente-t-il en pratique ? Pour les balises de début et de fin, sachez que de nombreuses balises sont facultatives. Un paragraphe et une liste, par exemple, s'écrivent comme ceci en XHTML :

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>
<ul>
  <li>Praesent augue nisl</li>
  <li>Lobortis nec bibendum ut</li>
  <li>Dictum ac quam</li>
</ul>

En HTML, vous pouvez l'écrire avec ce code (qui est parfaitement valide) :

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.
<ul>
  <li>Praesent augue nisl
  <li>Lobortis nec bibendum ut
  <li>Dictum ac quam
</ul>

Les développeurs ont également appris à écrire les éléments vides comme ceci : <br />. C'est encore une chose que le XHTML a apporté au HTML, mais la barre oblique n'ayant aucun effet sur les éléments vides, vous n'avez besoin que de ceci : <br>.

En HTML vous pouvez tout écrire en majuscules :

<A HREF="https://css-tricks.com/">CSS-Tricks</A>

Bon, évidemment, on dirait que vous criez et vous n'aimerez sans doute pas cela, mais enfin il n'est pas interdit de l'écrire comme ça.

Lorsque vous voulez condenser ce lien, le HTML vous offre la possibilité de laisser de côté certains guillemets :

<A HREF=https://css-tricks.com/>CSS-Tricks</A>

Note : En règle générale, lorsque la valeur de l'attribut ne contient pas d'espace ou de signe égal, il est possible de supprimer les guillemets.

Enfin, le HTML-HTML - et non le XHTML-HTML - permet également de minimiser les attributs. C'est-à-dire qu'au lieu de marquer un élément input comme requis et en lecture seule, comme ceci :

<input type="text" required="required" readonly="readonly" />

Vous pouvez minimiser les attributs :

<input type="text" required readonly />

Si vous profitez non seulement du fait que les guillemets ne sont pas nécessaires, mais aussi du fait que le texte est la valeur par défaut de l'attribut type ici (il existe d'autres combinaisons attribut-valeur inutiles), vous obtenez un exemple qui montre le HTML dans toute sa beauté minimale :

<input required readonly />

Écrire du HTML, à la manière du HTML

Ce qui précède n'est pas une représentation de ce qu'était le HTML dans les années 90. À l'époque, le HTML était chargé d'éléments <table> pour la mise en page, rempli de code de présentation, largement invalide (comme c'est encore le cas aujourd'hui), et la compatibilité des agents utilisateurs était très variable. Pourtant, c'est l'essence même de ce que nous aurions voulu conserver si XML et XHTML n'étaient pas arrivés.

Si vous êtes ouvert à une suggestion de ce à quoi pourrait ressembler une manière plus complète et contemporaine d'écrire le HTML, j'en ai une ! (Le HTML étant mon principal domaine d'intérêt, je complète ce texte par des liens vers certains de mes articles).

1. Respectez la syntaxe et la sémantique.
   • Validez votre HTML, et n'envoyez que du HTML valide, utilisez le validateur du W3C
2. Utilisez les options que vous offre le HTML, du moment que vous le faites de manière cohérente.
   • N'oubliez pas que les noms des éléments et des attributs peuvent être en minuscules ou en majuscules.
3. Limitez l'utilisation du HTML au strict minimum
   • Rappelez-vous que le balisage de présentation et de comportement doit être traité par CSS et JavaScript.
   • Rappelez-vous que les balises de début et de fin ne sont pas toujours nécessaires.
   • Rappelez-vous que les éléments vides n'ont pas besoin d'être fermés.
   • N'oubliez pas que certains attributs ont des valeurs par défaut qui permettent d'omettre ces paires attribut-valeur.
   • N'oubliez pas que les valeurs des attributs n'ont pas toujours besoin d'être entre guillemets.
   • N'oubliez pas que la minimisation des attributs est prise en charge.

Ce n'est pas une coïncidence si cela ressemble aux trois règles de base du HTML, si cela fonctionne selon le principe qu'un poids réduit de fichier conduit également à des sites plus rapides, et si cela suit l'école du développement web minimal. Rien de tout cela n'est nouveau - notre domaine pourrait simplement décider de le redécouvrir. Des outils sont également disponibles : html-minifier est probablement le plus connu et le plus à même de gérer toutes les optimisations HTML.

Vous avez appris le HTML à la manière du XHTML. HTML n'est pas XHTML. Redécouvrez le HTML et participez à l'élaboration d'une nouvelle méthode moderne d'écriture du HTML, qui reconnaît le XML sans en faire un dogme intangible.