Trucsweb.com

Trucsweb.com

XML

HTML5

RDFFav

Le nouveau HTML « Living Standard » et le XML

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.Self-closing tag, HTML, WHATWG, Apple, Google, Mozilla, Microsoft, W3C, valitation, valideur, XHTML, XML, XSLT, XSL, Optional tagsLe nouveau HTML « Living Standard » et le XML

« Semantic Web roadmap »

Tim Berners-Lee, qui méritait le prix Nobel!
Tim Berners-Lee, qui méritait le prix Nobel!

« 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 : RDF 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.

XML, persona non grata, et la promesse de Web2

Ce n’est pas une surprise, selon le WHATWG, ça fait 20 ans qu’on néglige le XML, depuis 2003! « ...This interest was borne from the realization that XML’s deployment as a web technology was limited to entirely new technologies (like RSS and later Atom), rather than as a replacement for existing deployed technologies (like HTML). » (Cet intérêt est né de la prise de conscience que le déploiement de XML en tant que technologie Web était limité à des technologies entièrement nouvelles (comme RSS et plus tard Atom), plutôt qu’en remplacement des technologies déployées existantes (comme HTML).) Source le WHATWG. À croire qu’ils ne comprennent pas l’idée!

Limité aux nouvelles technologies RSS!! Résumé le XML à du RSS c’est dire qu’un système informatique est essentiellement une base de données. Ou que « L’Avalée des avalés » est un alphabet! Quand on pense qu’on carbure partout au JSON... inspiré de technologie encore plus vieille que le XML!

D’ailleurs, dans l’optique du Web2, comment peut-on séparer le contenu du contenant d’une page HTML? En JSON? On peut séparer le style (CSS), on peut séparer à la limite la structure HTML, manipuler le tout en JavaScript? Mais le contenu lui-même, même s’il provient d’une base de données (essayer d’ouvrir une base de données dans un navigateur ;-). Pourquoi pas en CSV!?!

C’est pas fou, la première version des Trucsweb en 1997 combinait deux fichiers texte! Mon forum était fort populaire à l’époque, la première version avait planté solide à cause de ma base de données MySQL. Pour éviter de dépendre de la base de données, j’utilisais des fichiers texte. Le résumé en format texte et le texte en format HTML, le tout manipulé par un langage serveur.

C’était en 1997! Depuis 20 ans c’est du XML mur à mur bien sûr! Non pas parce qu’elle plante! Parce qu’à l’époque les sites populaires étaient victime de contrainte par les fournisseurs d’hébergement Web. Comme limiter la mémoire! Quand je m’en suis rendu compte, j’ai tablé sur le XML. J’utilise toujours des bases de données, sur des serveurs dédiés déjà. Mais le HTML est en XML! Parce que l’idéal c’est le format XML, le « Markup Language » extensible! Le ciment du Web2! Ça n’a rien d’excentrique, c’est tout à fait dans la logique du Web 2 et du « Semantic Web roadmap » de Tim Berners-Lee!

Parlant d’interpellation et du maillage naturel du web, de la sémantique, de la décentralisation et de tout ce qui fait l’essence du Web2. Sur certaines tablettes, c’est impossible d’entrer une adresse dans le navigateur! Il faut utiliser le moteur de recherche. De toute façon, la grande majorité des internautes recherche avec Google une adresse alors qu’ils pourraient simplement la coller dans la barre du navigateur. On est très loin de la philosophie du Web2. Dire qu’on en est déjà à l’horribilis Web3 et son retour à la case départ!


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...

Valideur de la W3C

GitHubComme j’ai mentionné plus haut, la W3C a modifié son message d’avertissement en une simple information. Mais notre document HTML5 n’obtient pas la mention « Valide pour autant ». Et bien, j’ai fait plusieurs tests cette semaine. J’ai testé des codes d’exemples du WAHTWG dont certains avaient des erreurs de validation! La W3C ne passe pas son propre test? Alors j’ai contacté la WHATWG pour les aviser des erreurs. Et bien, c’est faux, la WHATWG ou plutôt Scott O’Hara sur GitHub m’a répondu que c’était le videur de la W3C qui avait des erreurs! Ouf!

« @Oznog there is already a bug for the validator to output the updated information: validator/validator#1397. The validator is presently incorrect, not the HTML spec. »


« Le valideur est actuellement incorrect, pas la spécification HTML. »

Héhé, je peux bien le croire! Une chose sûre, il y a un bogue tant avec le valideur de la W3C que les spécifications du WHATWG. J’ai aussi mentionné une petite erreur de fermeture de balise dans un des exemples des spécifications du WHATWG! Bon, ce n’est pas un problème de spécification c’est carrément un détail. Mais c’est une erreur qu’on ne prend pas au sérieux, elle est toujours là!

Le code suivant (4.3.8 The header element), cité en exemple dans la spécification, retourne deux erreurs! Les deux en raison du bogue du valideur de la W3C. Mais la deuxième erreur est fort probablement une bête erreur de frappe. Si le paragraphe était fermé, il n’y aurait qu’une seule erreur. Et de toute façon, la nouvelle spécification indique de ne pas fermer les paragraphes quand c’est possible. Comme c’est le cas dans cet exemple. Le site des spécifications HTML du WHATWG n’est visiblement pas encore à niveau avec la dernière mouture! Vous pouvez vérifier par vous même!


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

Conclusion

Sinon, faire avancer le Web, certes, mais oublier pour ne pas dire du rejeter du revers de la main le XML c’est ignoble. Il encore trop tôt pour observer les dégâts et l’ampleur de cette décision unilatérale des majors! D’autre part, il n’y a probablement que les amateurs de XML qui vont être touchés alors que les autres négligent souvent ces mêmes recommandations.

Références

, Analyste programmeurConception oznogco multimédia (http://oznogco.com), Trucsweb
Dernière mise à jour :

Commentaires

Ajouter un commentaire
Votre adresse de courriel ne sera pas publiée. * L'astérisque indique les champs obligatoires.
Votre évaluation du tutoriel

10/10 sur 1 revues.
       Visites : 266 - Pages vues : 387
X

Trucsweb.com Connexion

Connexion

X

Trucsweb.com Mot de passe perdu

Connexion

X

Trucsweb.com Conditions générales

Conditions

Responsabilité

La responsabilité des Trucsweb.com ne pourra être engagée en cas de faits indépendants de sa volonté. Les informations mises à disposition sur ce site le sont uniquement à titre purement informatif et ne sauraient constituer en aucun cas un conseil ou une recommandation de quelque nature que ce soit.

Aucun contrôle n'est exercé sur les références et ressources externes, l'utilisateur reconnaît que les Trucsweb.com n'assume aucune responsabilité relative à la mise à disposition de ces ressources, et ne peut être tenue responsable quant à leur contenu.

Droit applicable et juridiction compétente

Les règles en matière de droit, applicables aux contenus et aux transmissions de données sur et autour du site, sont déterminées par la loi canadienne. En cas de litige, n'ayant pu faire l'objet d'un accord à l'amiable, seuls les tribunaux canadien sont compétents.

X

Trucsweb.com Trucsweb

X

Trucsweb.com Glossaire

X

Trucsweb.com Trucsweb

X

Trucsweb.com Trucsweb

Conditions

Aucun message!

Merci.

X
Aucun message!
X

Trucsweb.com Créer un compte

Créer un compte

.
@