XML

HTML5

Le nouveau HTML « Living Standard » et le XML

« Semantic Web roadmap »

« Les objectifs de conception de XML mettent l’accent sur la simplicité, la généralité et la convivialité sur Internet. Il s’agit d’un format de données textuel avec un support solide via Unicode pour différentes langues humaines. Bien que la conception de XML se concentre sur les documents, le langage est largement utilisé pour la représentation de structures de données arbitraires telles que celles utilisées dans les services Web. »⑴

« En 1998, Tim Berners-Lee met en place ce qu’il appelle le « Semantic Web roadmap » (« feuille de route du Web sémantique ») où il élabore les différents objectifs techniques afin de parvenir à la mise en place de ce qu’il considère comme une base de données globale à l’échelle du réseau. Pour cela, il faut créer un lien entre l’usager qui doit se trouver dans un espace de collaboration et de coopération, d’une part, et les machines qui doivent saisir les données, d’autre part. Ces dispositifs techniques (XML, URI, l’ontologie, l’hypertexte, les données, etc.) doivent s’imbriquer afin de permettre au Web sémantique d’exprimer tout son potentiel. Cet agencement est symbolisé par Tim Berners-Lee dans le « layer cake », un schéma qui montre comment toutes ces technologies doivent fonctionner ensemble. »⑵

C’est un pas de plus dans la marginalisation du XML. C’est deux cultures qui s’affrontent alors qu’ils parlent la même langue et font partie de la même famille du markup language!! On parle de « Warning » et « d’info » actuellement. Mais sur papier, l’incompatibilité du XML avec le HTML est d’ores et déjà un fait! Si vous utilisez sérieusement le XML dans la création de pages Web, du travail qui vous attend pour respecter les normes de l’aliance W3C et le GAFAMZ oups, le WHATWG ;-)

Si le XML ne vous dit rien, ce tutoriel ne s’adresse pas à vous!

À première vue, comme le dit un simpliste commentaire sur stackoverflow.com : « To fix this easily in your document, select /> and press Crtl+D . »!⑶, c’est un détail! Le site stackoverflow.com ne passe pas le test de la W3C non plus.

Mais la fissure est bien plus importante. Le HTML a toujours été différent du XML même s’ils sont issus tous deux du SGML. Mais on pouvait en HTML être moins strict sans impacter le XML alors que les contraintes du XML passaient naturellement en HTML. Mais ce n’est plus le cas depuis le 5 octobre, depuis que le valideur de la W3C se base sur le nouveau HTML « Living Standard » et retourne un « Warning » quand il se frotte au XML!

Les Trucsweb est un bon exemple d’intégration de cette approche sur laquelle je mène des recherches depuis 1999. Chaque page des Trucsweb provient d’une source XML, c’est dire qu’un navigateur ouvre et interprète directement votre document XML (dans ce cas-ci un document RDF). Le transformer à l’aide d’un fichier XSL et un peu de style CSS et le tour est joué! Aucun langage serveur dans cet exemple : http://www.trucsweb.com/tutoriels/xml/tw357/default.rdf. Chaque page des Trucsweb est bâtie sur ce même principe!

Cette philosophie derrière le développement historique du Web est de plus en plus marginalisée. Pourquoi? Peut-être pour soulager le navigateur, j’en conviens. Mais ce navigateur est toujours compatible HTML4!! Give me a breack! À mon avis, c’est surtout pour aider les robots du GAFAMZ, des polluposteurs et des espions de tout acabit de capturer et manipuler plus efficacement une page Web!

Le plus drôle, c’est que ces géants son loin de respecter le HTML Living Standard! MSN (Microsoft) par exemple est encore au XHTML⑸ d’il y a 22 ans!! L’excellent mais strict XHTML 1.0.

HMTL Living Standard du WHATWG

Bon, fini la monté de lait. Passons aux problèmes rencontrés depuis le 5 octobre 2022 avec le valideur de la W3C et la dernière version du HMTL Living Standard Last Updated 5 October 2022 by WHATWG c’est-à-dire Apple, Google, Mozilla et Microsoft!

Balise à fermeture automatique (Self-closing tag⑺)

Je parle essentiellement de « fermeture à l’intérieur d’une balise sans fermeture » ou Self-closing tag comme le saut de ligne <br />. La W3C exige maintenant <br>... Le reste est secondaire.

Self-closing tag syntax in text/html documents is widely discouraged; it’s unnecessary and interacts badly with other HTML features (e.g., unquoted attribute values). If you’re using a tool that injects self-closing tag syntax into all void elements, without any option to prevent it from doing so, then consider switching to a different tool.

From line 5, column 3; to line 5, column 26

<head>↩ <meta charset="utf-8" />↩<meta>

Oups, c’était le nouveau message apparu hier, le 5 octobre 2022. Déjà aujourd’hui, la W3C vient de changer son message! Une seule journée pour dire à quel point ça dérange dans l’ombre! Ce n’est même plus un « Warning » mais une « Info ». En vain, on ne passe pas davantage le test! :

Info: Trailing slash on void elements has no effect and interacts badly with unquoted attribute values⑻.

Il faut bien comprendre que le XML exige la fermeture automatique des balises, tout comme le XHTML ou les langages XSL ou XSLT. Ce n’est pas une question d’être puriste, ce n’est pas un caprice. Un contenu XML transformé par le XSL n’a pas besoin d’être validé, le compilateur se charge de le faire pourvu que les documents soient bien formés. Bien formé dans le sens de bien formé, pas dans le sens de HTML!

Bien sûr on est habitué de travailler avec des incohérences. C’est pour cette raison que le XML a implanté un contenu encodé, un fourre-tout :

<content:encoded rdf:datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">
  <![CDATA[
     code HTML non conforme accepté entre ces "balises"
  ]]>
</content>

La seule solution est maintenant de modifier la sortie avec la méthode HTML method="html"

1 - <xsl:output method="html" encoding="utf-8" omit-xml-declaration="yes" indent="yes"/>

Puis vérifier les « Balises à fermeture automatique (Self-closing tag) » de tous vos codes HTML pour les convertir. Sauf les images SVG en ligne, qui passe le test des « Balise à fermeture automatique (Self-closing tag) » pour l’instant :

    <svg ...<polyline... <circle... <line...</svg>

Personnellement ça implique de convertir des centaines de fichiers XSL pour des dizaines de sites Web! Pire, c’est convertir des milliers de textes HTML « bien formés » comme on disait dans l’ancien temps(!) pour les rendre « mal formés » ;- ) Sans parler de mon éditeur HTML qui je dois revoir! Et mes réflexes, depuis des années je corrige des codes en ajoutant ce foutu petit caractère. Et aujourd’hui je dois faire le contraire. ;- ))

les « Balises facultatives » (Optional tags⑼)!

Le valideur ne produit pas encore d’erreur, d’info ou d’avertissement. Mais il y a un tas de changement complètement incompatible avec le XML dont les « Balises facultatives » (Optional tags⑼)!

13.1.2.4 Optional tags

Certain tags can be omitted.

Omitting an element's start tag in the situations described below does not mean the element is not present; it is implied, but it is still there. For example, an HTML document always has a root html element, even if the string <html> doesn't appear anywhere in the markup.

An html element’s start tag may be omitted if the first thing inside the html element is not a comment.

Avec le résultat suivant, bourré d’exception incompatible avec le XML. C’est d’ailleurs mon premier code mal formé à vie ;-) Cette liste à puce ci-dessous ne ferme pas les balises <li> ni <p> selon les nouvelles recommandations :

• La balise de fin d’un élément html peut être omise si l’élément html n’est pas immédiatement suivi d’un commentaire.

• La balise de début d’un élément head peut être omise si l’élément est vide ou si la première chose à l’intérieur de l’élément head est un élément.

• La balise de fin d’un élément d’en-tête peut être omise si l’élément d’en-tête n’est pas immédiatement suivi d’un espace ASCII ou d’un commentaire.

• La balise de début d’un élément body peut être omise si l’élément est vide, ou si la première chose à l’intérieur de l’élément body n’est pas un espace ASCII ou un commentaire, sauf si la première chose à l’intérieur de l’élément body est un meta, noscript, link, script, style ou élément de modèle.

• La balise de fin d’un élément de corps peut être omise si l’élément de corps n’est pas immédiatement suivi d’un commentaire.

//Exemple du code précédent
<ul>
  <li><p>La balise de fin d’un élément html...
  <li><p>La balise de début d’un élément head...
  <li><p>La balise de fin d’un élément d’en-tête...
  <li><p>La balise de début d’un élément body...
  <li><p>La balise de fin d’un élément de corps...
</ul>

Exemple par Google :

<!-- Non recommandé -->
<!-- Mais toujours valide!! -->
<!DOCTYPE html>
<html>
  <head>
    <title>Titre du document</title>
  </head>
  <body>
    <p>Texte.</p>
  </body>
</html>

<!-- Recommandé -->
<!-- Mais non valide!! -->
<!DOCTYPE html>
<title>Titre du document</title>
<p>Texte.

Héhé, attention, ce code, cette nouvelle façon de faire retourne une erreur. Le valideur de la W3C plante sur ce code, il exige d’ajouter la langue dans la balise <html> qui n’est plus requis ;- ) Donc le valideur ignore ces propres règles, sans doute parce que c’est nouveau, mais exige d’autres recommandations, sans doute parce qu’il ne les utilise pas! Tout sauf rassurant! Noter la méprise du valideur qui parle de <title> qui n’a rien à voir avec ce problème :

Warning: Consider adding a lang attribute to the html start tag to declare the language of this document.

From line 2, column 16; to line 3, column 7

TYPE html>↩<title>Titre 

Bon sens!

Et pourtant, quoi de plus simple à enseigner qu’une balise doit être OUVERTE et FERMÉE! Depuis hier, c’est devenu impossible pour moi de vous énumérer la litanie de nouvelles exceptions!

Officiellement, le HMTL Living Standard du WHATWG⑽ n’a plus de balises de fermeture du paragraphe <p> par exemple. Mais surtout, plus de balises d’ouverture ni de fermeture <html>, <head>; ou <body>! Wow. Il n’y a pas encore d’info ou de warning mais c’est radical! (Je souligne que le Navigateur est paradoxalement le moins rigoureux des applications. Il accepte encore le vieux HTML4 ou le XHTML et le « Self-closing tag » par exemple !) C’est quand même ironique quand on pense que cette petite « Révolution » était déjà là dans les années 90. La plupart des logiciels ne fermaient déjà pas les balises comme le paragraphe <p> ou le saut de ligne <br>... Ha c’est vrai, à l’époque les logiciels utilisaient des majuscules <BODY>. Le HMTL Living Standard exige maintenant des minuscule <body>.

Bonne nouvelle

Il y a quand même de bonnes initiatives dans cette nouvelle mouture de recommandations (Living Standard)⑾. Il n’y a pas que de mauvaises nouvelles dans ce virage tendancieux. Par exemple l’utilisation des doubles guillemets au lieu des simples guillemets dans les attributs HTML. Oui oui, du HTML strict ;- ) Quoique certains programmeurs soient habitués d’utiliser le simple guillemet dans certains cas. Non pas parce que c’est impossible en HTML mais parce que des composantes souvent JavaScript exige des doubles guillemets alors que le HTML permettait (avant) les deux types de guillemets :

<!-- Recommandation (avec raison) -->
<balise attribut="composante('valeur')">[...]</balise>

<!-- (mais) certaines composantes exigent le double guillemet, maintenant incompatible : -->
<!-- Non recommandé -->
<balise attribut='composante("valeur")'>[...]</balise>

Incompatible avec les nouvelles réglementations. Impossible aux Webmestres de réglé ce petit problème à la merci de la composante externe!

Une nouvelle intéressante, demande d’arrêter d’utiliser les entités HTML au profit d’un document encodé UTF-8 sans indicateur d’ordre des octets dit « BOM » (byte-order mark)⑿! Wow. Personnellement, ça fait 20 ans que j’y suis déjà comme la plupart des professionnelles non anglophones. Mais les chanceux n’ont pas de message dans le valideur pour les décourager alors que ça fait 20 ans qu’ils ne comprennent pas la technologie! À mon avis, même si c’est une recommendation plus importante (pour les francophones!?!) ou au même titre que la balise de fermeture, le valideur de la W3C va ignorer cette directive encore longtemps!

Mais voilà, je viens de résumer la nouvelle refonte. À part un tas de recommandations sur la manière de former le code HTML et CSS, c’est-à-dire l’esthétisme du code(!?!), alors que ce code sera compressé de toute façon au final détruisant cette recommandation, on est très loin de la révolution du HTML5...

<header>
 <hgroup>
  <h1>Fullscreen API</h1>
  <p>Living Standard - Last Updated 19 October 2015<p>
 </hgroup>
</header>

Conclusion