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
[#] Ceci contredit
d'ailleurs un petit peu l'autre réponse suivante, qui est faite un peu
plus loin : 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.If you don't care about IE,
you can use an XML serializer and serialize
to XHTML5 (
Accessoirement, le fait que
le standard HTML5
ne soit pas encore fini n'aide pas trop les choses !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).
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 —) 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
() : 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 () : 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.