David Madore's WebLog: Quelques questions techniques sur le contenu Web

Index of all entries / Index de toutes les entréesXML (RSS 1.0) • Recent comments / Commentaires récents

Entry #1926 [older|newer] / Entrée #1926 [précédente|suivante]:

(lundi)

Quelques questions techniques sur le contenu Web

Maintenant que mon nouveau moteur de blog me permet de faire des changements techniques sur ce blog (c'est-à-dire, en fait, de faire joujou), encore faut-il savoir quels changements je voudrais/devrais/pourrais faire. Voici certaines des questions que je me pose, et sur lesquelles certains de mes lecteurs ont peut-être un avis.

Première question, comment servir du contenu XHTML ? Il faut savoir que le XHTML, qui, comme son nom le suggère, est la version XML du HTML, peut en gros être servi de deux façons différentes : comme du HTML (c'est-à-dire, sous le type MIME text/html) ou comme du XML (c'est-à-dire, sous le type MIME application/xhtml+xml). Dans le premier cas (ce que je fais actuellement), bien que le contenu soit réputé être du XML bien-formé, il n'est pas analysé comme tel, mais comme une « soupe de tags » (par exemple, si une balise ouverte n'était jamais fermée, cela ne provoquerait pas une erreur fatale), autrement dit, on ignore qu'il s'agit de XML. Certaines mesures de compatibilité doivent alors être prises pour permettre au contenu d'être analysé de la même façon par un parseur « soupe de tags » que par un parseur XML (par exemple, si on doit pour une raison ou une autre créer un élément div vide, par exemple pour lui donner des attributs de style, il faut l'écrire sous la forme <div style="clear: both"></div> et pas <div style="clear: both"/> comme le XML permettrait mais ce qui confuserait les parseurs « soupe de tags » qui y verraient une balise ouvrante jamais refermée). Actuellement, je fais toutes sortes d'efforts dans ce sens, ce qui a d'ailleurs pas mal compliqué la tâche de l'écriture du moteur de blog (parce que bien que ces mesures de compatibilité soient recommandées par le W3C, personne ne semble avoir écrit de code spécifique pour produire du XHTML en en tenant compte). À l'inverse, servir du XHTML comme du XML présente différents avantages, notamment le fait de pouvoir y mélanger différents autres standards XML, comme le SVG ou le MathML. Mais au moment où j'ai écrit le précédent moteur de ce blog, cette possibilité était mal supportée : certains navigateurs ne comprenaient pas du tout le XHTML présenté sous le type MIME application/xhtml+xml, et même ceux qui le supportaient ne le géraient pas toujours très bien, par exemple Firefox ne faisait pas de rendu incrémental (il devait attendre que toute la page soit chargée avant de commencer à afficher quoi que ce soit). Probablement, de ce point de vue-là, la situation s'est améliorée, et je suppose que le seul navigateur qui gère encore imparfaitement le XHTML servi comme XML est IE dans ses anciennes versions (et même si je ne veux pas envoyer paître les gens qui utilisent encore ça, je peux toujours servir les pages avec un type MIME différent pour ce navigateur).

Mais la question du type MIME n'est pas tout. Même si je sers le XHTML comme du XML, il se pose la question de savoir si je déclare une DTD, et si oui, laquelle. Actuellement, je déclare <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">, autrement dit je promets du XHTML 1.0 strict, je fais les efforts nécessaires pour que ç'en soit, et je valide effectivement mes pages contre cette DTD. Seulement, de nos jours où la multiplication des standards du Web a beaucoup compliqué le jeu de tags qui peuvent apparaître dans un document, les DTD sont un mécanisme de validation plus ou moins obsolète : on préfère des choses plus flexibles et basées sur du XML pur, comme RelaxNG ou XSD (je n'y connais rien, donc je ne sais pas ce qui exite vraiment dans l'un ou l'autre pour valider du XHTML moderne, mais je n'ai pas de doute qu'il y ait des possibilités dans cette direction). Notamment, il n'a été que très difficilement possible de produire une DTD pour la combinaison XHTML+MathML+SVG, et cela représentera probablement la culminaison des efforts dans cette direction. Seulement, ne pas déclarer de DOCTYPE du tout va faire (si le document est servi avec type text/html) que des navigateurs Web tomberont dans un mode spécial « quirks », où ils ne gèrent pas le CSS correctement. La meilleure solution est sans doute de commencer les documents par <!DOCTYPE html>, comme le préconise le HTML5.

Voilà justement un autre sujet, le HTML5 : comme le XHTML2 a été maintenant officiellement abandonné, on doit bien admettre que le HTML5 est le standard moderne. Mais il ne facilite pas forcément les questions précédentes. Notamment, il se pose toujours la question de savoir si, et comment, on peut fabriquer des documents qui soient du HTML5 valide à la fois quand ils sont interprétés en mode « soupe de tags » text/html (qui cette fois est une soupe de tags normalisée, donc plus si soupesque que ça) et en mode XML (c'est-à-dire XHTML). Or si je veux produire et manipuler mon document avec des outils XML (ce que je veux), et quand même le rendre lisible aussi largement que possible, c'est bien ce que je dois faire. Cette page de FAQ, au demeurant très intéressante, fait une réponse inquiétante : It is possible to construct documents that are valid HTML5 when labeled as text/html and valid XHTML5 when labeled as application/xhtml+xml. Doing so is much harder than it first appears and is most often useless, so you'd probably spend your time better by not trying.[#] Ceci contredit d'ailleurs un petit peu l'autre réponse suivante, qui est faite un peu plus loin : If you don't care about IE, you can use an XML serializer and serialize to XHTML5 (application/xhtml+xml). However, if you do care about IE, you can use an HTML5 serializer and serialize from an XML pipeline to text/html. In this case, you must avoid constructs that aren't supported in text/html (e.g. div as a child of p). Accessoirement, le fait que le standard HTML5 ne soit pas encore fini n'aide pas trop les choses !

Tiens, un petit détail s'agissant de HTML5 : je suis un grand fan de la distinction entre les balises abbr et acronym[#2], et ces andouilles ont décidé assez gratuitement de la supprimer (il ne subsiste que abbr). Pourquoi tant de haine ? Je pourrais remplacer acronym par abbr dans toutes mes pages, mais c'est quand même une perte d'information assez violente ; à la place, je suppose qu'il faut plutôt remplacer acronym par abbr class="acronym" et faire une stylesheet orale pour indiquer comment lire le texte.

[#] Je pense que si je ne mets aucune entité, j'arrive bien à produire des documents qui sont à la fois du HTML5 et du XHTML5 valides. En revanche, si je veux mettre des entités (juste par défi), ça devient vraiment technique. Voici donc un défi : produire un document qui soit (1) du HTML5 valide en mode « soupe de tags », (2) du XHTML5 valide selon la spécification HTML5, (3) du XML bien-formé et si il contient une référence à une DTD, alors valide selon cette DTD, et (4) pour garantir la non-trivialité, qu'il contienne à la fois une référence à une entité (disons &mdash;) et un élément SVG. Est-ce possible ?

[#2] Pour préciser, abbr sert à marquer une abréviation qui doit se lire lettre par lettre, par exemple HTML, noté <abbr>HTML</abbr> et prononcé [aʃteɛmɛl], et acronym sert à marquer un acronyme qui se lit comme un seul mot, par exemple MIME, noté <acronym>MIME</acronym> et prononcé [maɪm].

Deuxième question, comment faire un flux de syndication correct ? Je fais notamment référence à des commentaires sur l'entrée précédente. Actuellement, je propose un flux RSS 1.0, auquel je peux assez facilement ajouter un flux Atom s'il y a de la demande. Mais encore faut-il savoir quoi mettre dedans. Auparavant il n'y avait que le titre des entrées. Maintenant j'ai mis le début du texte proprement dit (160 caractères initialement, que je viens d'augmenter à 500 puisque 160 semble un peu court). Mais j'avoue que je ne sais pas très bien à quoi ce truc sert (en fait, je n'ai jamais utilisé d'agrégateur de flux, ce qui n'aide pas). Dans mon esprit, avoir le début du contenu devait servir à voir rapidement si on a lu l'article et, sinon, si on est éventuellement intéressé à la lire, un peu comme Google affiche en-dessous d'un lien dans les résultats de recherche : du coup, cela fait sens de ne mettre que le début (et de retirer le formatage). Apparemment, il y a des gens qui préfèrent lire complètement le contenu par un agrégateur. Je n'ai pas d'objection à ça (je vois mal quelle objection je pourrais avoir, à part que je suppose que ça casse toutes les stylesheets CSS), mais j'ai un petit problème avec l'usage du fichier RSS (ou Atom) lui-même : dans mon esprit, le fichier RSS a pour but d'être petit et téléchargeable rapidement et fréquemment, pour pouvoir facilement savoir s'il y a du nouveau contenu — si on veut télécharger le contenu proprement dit, il faut voir ailleurs. Autrement dit, je veux bien qu'un agrégateur permette de lire mon blog complètement, mais dans ce cas c'est le boulot de l'agrégateur de télécharger le fichier HTML proprement dit (s'il a calculé qu'il y avait du nouveau et qu'il y avait raison de télécharger), d'en extraire la bonne section, et de la présenter comme il veut la présenter, cela ne devrait pas se limiter à la lecture du RSS. Donc il faut m'expliquer comment obtenir ça, parce qu'en l'état je suis un peu perplexe (on me souffle qu'Atom doit permettre de fournir un lien vers le contenu proprement dit, mais je ne comprends pas vraiment comment). Ajout (2011-09-06T15:20+0200) : Quelqu'un me dit que ce n'est pas possible pour un flux Atom de référencer du contenu externe, mais quelqu'un d'autre suggère, et cette page semble confirmer, que si, avec l'attribut src sur la balise atom:content ; mais les agrégateurs Atom sont-ils assez malins pour utiliser correctement une ressource externe qui soit un div dans un document HTML ?, voilà ce que je voudrais savoir.

Cette question rejoint un peu la précédente : si je passe à HTML5, alors on me suggère que je peux mettre les entrées dans des balises article, ce qui simplifierait le boulot d'outils cherchant à analyser le blog automatiquement. Je suis tout à fait favorable à ça.

Ajout (2011-09-07) : voir l'entrée du surlendemain.

Troisième question, comment gérer les commentaires ? Actuellement c'est un script Perl maison qui s'en occupe, et qui tourne sous la forme d'un CGI sur mon serveur Web. Je n'y ai pas touché du tout : ce moteur de commentaires est à peu près complètement séparé du moteur de blog (et il permet d'ailleurs de commenter n'importe quelle page Web, c'est voulu, même si j'aurais tendance à être réticent à modérer favorablement des commentaires sur des pages ne me concernant pas du tout), les seules connexions étant que je fournis au moteur de commentaires des alias pour les entrées de mon blog (pour afficher le titre de l'entrée commentée) et qu'à l'inverse j'ai un petit bout de JavaScript qui affiche le nombre de commentaires et la date du dernier à la fin de chaque entrée. Cette séparation a l'avantage que le système de commentaires ne m'a pas handicapé pour le changement du moteur de blog ; elle a l'inconvénient que quand on me demande de produire un flux RSS des commentaires ou, pire, de reproduire l'entrée elle-même en tête de chaque page de commentaires, ce n'est pas facile.

Je voudrais donc probablement, à terme, refaire ce moteur de commentaires, ce qui est d'ailleurs sans doute plus facile. Et probablement l'intégrer de façon plus proche avec le moteur de blog. Pour ça, j'ai déjà choisi mon arme : Apache Tomcat, parce que pour s'intégrer avec un outil en Java ce sera le mieux (et parce que je ne veux vraiment pas apprendre PHP ; quant à Perl, il m'a profondément déçu par son absence de bibliothèque convenable pour gérer le XML : XML::LibXML est complètement cassé dès qu'on commence à jouer avec les namespaces, or on doit le faire si on prétend mélanger XHTML avec n'importe quoi).

Mais une question d'un peu plus haut niveau consiste à se demander quel mécanisme d'entrée fournir pour les commentaires. Actuellement, on tape du pur texte, seule est fournie la possibilité d'entrer un lien en tapant <URL: schéma://monurl >, ce qui est malcommode et d'ailleurs les gens ne lisent pas les instructions et se trompent plus souvent qu'ils ne réussissent. Je voudrais faire plus agréable que ça, mais c'est extrêmement délicat : permettre de taper du HTML demande par exemple soit de trouver un parseur « soupe de tags » (capable de transformer la soupe en un vrai arbre DOM) soit d'exiger que le commentateur produise du XHTML bien-formé, ce qui est bourré d'écueils (les gens n'ont pas envie de refermer leurs balises, je pense, il n'y a que les maniaques comme moi pour le faire). Sans doute les navigateurs modernes ont-ils tout ce qu'il faut (un éditeur de HTML inclus qui produise automatiquement du XHTML bien-formé), ce qui fait que je pourrais fournir le choix entre taper du texte pur, taper du XHTML à la main ou, si on a un navigateur convenable, taper du XHTML à travers un widget fourni par le navigateur. Reste qu'il faudra encore, pour des raisons de sécurité, valider ce XHTML derrière, choisir un modèle de contenu autorisé, etc. : tout ça est un peu fastidieux.

Par ailleurs, j'ai un ami qui réclame que les commentaires soient accessibles par une interface NNTP, pour pouvoir les agréger avec ses autres groupes de discussion. La demande est raisonnable sur le principe, même si je n'aime vraiment pas le protocole NNTP, et que la conversion HTML↔texte est au mieux déplaisante (sans parler de la quasi-impossibilité de faire un round-trip correct, quelque chose qui figure d'ailleurs dans ma TORANT-list). Si au moins il existait des standards d'échange ou téléchargement des messages sur les webforums (un standard basé sur JSON, typiquement), je pourrais utiliser ça et lui dire que dès lors que les messages sont récupérables sous un format clair c'est à lui de se débrouillre pour interface avec NNTP… mais je ne crois pas qu'un tel standard existe. (Ce qui est hautement regrettable, parce qu'il est vraiment pénible de suivre des webforums qui ont tous leur style différent, sans pouvoir les agréger sous une interface unique dans un newsreader.) Au moins en lecture, un flux RSS ou Atom serait sans doute désirable.

↑Entry #1926 [older|newer] / ↑Entrée #1926 [précédente|suivante]

Recent entries / Entrées récentesIndex of all entries / Index de toutes les entrées