Validité HTML des pages sur LinuxFr.org

Un matin (le 6 octobre 2018), une question existentielle a fait jour dans mon esprit, comme ça, venue d’on ne sait où. Et dont on voit le caractère urgent et prioritaire quelques années plus tard.

Une idée probablement dans le même genre que l’envie pas gagnée de Sir Tim Berners-Lee de rendre à l’utilisateur le contrôle via le projet Solid, ou les râleries sur la dérive obésitaire du logiciel (évoquée en journal) ou la quête graalesque du poétique oxymore de la DRM ouverte interopérable standard accessible.

Bref, je me demandais « les pages produites par LinuxFr.org sont-elles valides niveau HTML, et est‐ce que (plutôt comment) ça a changé au fil des années ? ».

Évidemment, ça ne donnera un état et une évolution que sur les contenus/commentaires du site, et pas sur Internet en général (même si certains ne connaissent d’Internet que leur réseau social préféré, mais ceux‐là ne nous intéressent pas ici, car soit ils ne viennent donc pas sur LinuxFr.org, soit ils y sont en permanence mais ne mettent pas de liens pour en sortir vu qu’ils n’en sortent pas).

Sommaire

• HTM-quoi?
• C’est plus compliqué que prévu
• Les dépêches
  • L’état initial
  • Des exemples de HTML fait main invalides
    • Des esperluettes mal codées dans des liens
  • Des exemples de Markdown produisant du HTML invalide
    • Hyperlien décrit, mais sans URL
  • Tableau mais sans contenu
  • Élément de liste vide
    • Spans vides sur la coloration syntaxique
  • Conversion de lien Wikipédia
    • Réinitialisation de l’indice des notes de bas de page entre la 1ʳᵉ partie et la 2ᵈᵉ partie
• C’était plus compliqué que prévu, mais est-ce que c’est mieux après ?
• Conclusions ?

HTM-quoi?

Le HTML est le langage du web. Il permet de structurer et de mettre en page le contenu de tous les sites internet.

Il est proche du XML, mais plus spécifique et moins strict. Comme dans tous les langages, il est possible de faire des erreurs qui rendent le fichier invalide. Par exemple, l’utilisation de balises qui n’existent pas, des balises ouvertes et jamais fermées (comme cela peut arriver avec des parenthèses, ou une utilisation incohérente des balises (par exemple un élément de liste qui ne serait pas dans une liste). Le navigateur se débrouille alors comme il peut pour afficher quelque chose.¹

Cela peut provoquer des problèmes d’affichage, nuit à l’accessibilité, et complique la conversion des documents dans d’autres formats.

Historiquement, les dépêches sur LinuxFr.org étaient écrites et stockées directement en HTML, aujourd’hui, c’est le format Markdown qui est utilisé, avec une conversion en HTML pour l’affichage sur le site.

C’est plus compliqué que prévu

Faisons simple. On commence par les dépêches, en se limitant à la première et la seconde partie (on a déjà vérifié les liens précédemment, et dans l’immédiat on fera l’hypothèse qu’il n’y a pas de souci sur le titre, les étiquettes, les infos sur les auteur(s)/contributeur(s)/modérateur(s), les dates, etc.), et on ne va pas regarder les commentaires. On extrait brutalement la concaténation du HTML stocké pour les deux parties d’une dépêche, on ajoute des début/fin de document HTML qui vont bien, et on utilise tidy pour vérifier si on a obtenu une page valide, pour chaque dépêche. Le HTML des deux parties est produit à partir de Markdown pour les dépêches créées depuis la migration RoR en février 2011, et directement pour les dépêches créées avant et les milliers de dépêches anciennes réinjectées en 2012.

Les dépêches

L’état initial

Voyons déjà comment a évolué la validité des dépêches (par série 4xxx, on entend ici les dépêches existantes numérotées de 4000 à 4999, par valide un code de retour de tidy de 0 et par invalide un code de retour de 1).

(analyse faite le 6 octobre 2018 et portant sur les dépêches publiées aux numéros allant de 1 à 38818, pour un total de 25249 dépêches)

série	HTML valide	HTML invalide	total	source HTML	source Markdown	commentaire
0xxx	593 (97 %)	13 (3 %)	606	606 (100 %)
1xxx	576 (96 %)	21 (4 %)	597	597 (100 %)
2xxx	585 (96 %)	24 (4 %)	609	609 (100 %)
3xxx	579 (96 %)	23 (4 %)	602	609 (100 %)
4xxx	531 (96 %)	18 (4 %)	549	609 (100 %)
5xxx	491 (97 %)	13 (3 %)	504	503 (99 %)	1
6xxx	540 (96 %)	18 (4 %)	558	558 (100 %)
7xxx	492 (95 %)	23 (5 %)	515	514 (99 %)	1
8xxx	565 (94 %)	31 (6 %)	595	595 (100 %)
9xxx	582 (96 %)	23 (4 %)	605	605 (100 %)
10xxx	625 (98 %)	11 (2 %)	636	635 (99 %)	1
11xxx	559 (98 %)	10 (2 %)	569	569 (100 %)
12xxx	484 (97 %)	14 (3 %)	498	498 (100 %)
13xxx	419 (96 %)	17 (4 %)	436	436 (100 %)
14xxx	503 (98 %)	10 (2 %)	513	513 (100 %)
15xxx	408 (96 %)	12 (4 %)	420	419 (99 %)	1
16xxx	406 (96 %)	16 (4 %)	422	422 (100 %)
17xxx	409 (95 %)	20 (5 %)	429	429 (100 %)
18xxx	463 (98 %)	9 (2 %)	472	472 (100 %)
19xxx	440 (93 %)	28 (7 %)	468	468 (100 %)
20xxx	484 (94 %)	26 (6 %)	510	510 (100 %)
21xxx	567 (94 %)	36 (6 %)	603	603 (100 %)
22xxx	479 (91 %)	43 (9 %)	522	522 (100 %)
23xxx	585 (90 %)	60 (10 %)	645	644 (99 %)	1
24xxx	663 (88 %)	85 (12 %)	748	748 (100 %)
25xxx	612 (83 %)	117 (17 %)	729	727 (99 %)	2
26xxx	610 (82 %)	127 (18 %)	737	736 (99 %)	1
27xxx	583 (76 %)	183 (24 %)	766	678 (88 %)	88 (12 %)	migration technique RoR et début du Markdown
28xxx	680 (83 %)	136 (17 %)	816		816 (100 %)
29xxx	881 (92 %)	68 (8 %)	949	525 (55 %)	424 (45 %)	réinjection d’anciennes dépêches
30xxx	991 (100 %)	0 (0 %)	991	991 (100 %)		réinjection d’anciennes dépêches
31xxx	998 (99 %)	2 (1 %)	1000	999 (99 %)	1	réinjection d’anciennes dépêches
32xxx	965 (98 %)	10 (2 %)	975	903 (92 %)	72 (8 %)	réinjection d’anciennes dépêches et aussi un code de retour 2
33xxx	762 (89 %)	90 (11 %)	852		852 (100 %)
34xxx	810 (95 %)	35 (5 %)	845	1 (1 %)	844 (99 %)
35xxx	830 (99 %)	2 (1 %)	832		832 (100 %)
36xxx	805 (99 %)	3 (1 %)	808		808 (100 %)
37xxx	714 (98 %)	13 (2 %)	727		727 (100 %)
38xxx	577 (97 %)	14 (3 %)	591		591 (100 %)

Commençons déjà par nettoyer ce vilain code de retour 2 sur une dépêche réinjectée, pour cause de balise <troll> non échappée (ça ne s’invente pas)</troll>. Et profitons-en pour convertir cette dépêche en Markdown, ça fera toujours ça de moins à faire lors de la prochaine migration technique.

Quels sont donc les soucis sur les 1404 dépêches invalides au 6 octobre 2018 (soit 5,6 %) ? (devenues 1131 invalides sur 25 803 soit 4,4% au 29 décembre 2019)

Des exemples de HTML fait main invalides

On parle donc des contenus en HTML datant d’avant la migration de 2011 à Ruby On Rails et qui n’ont pas (encore) été convertis en Markdown.

Des esperluettes mal codées dans des liens

La source initiale est ici en HTML fait main :

<a href="http://example.invalid?param&mode&tid">lien</a> <!-- invalide -->
<a href="http://example.invalid?param&amp;mode&amp;tid">lien</a> <!-- correct -->

pour éviter

Warning: unescaped & or unknown entity "&mode"
Warning: unescaped & or unknown entity "&tid"

Des exemples de Markdown produisant du HTML invalide

Disons-le d’ores et déjà, une entrée de suivi a été créée pour éviter que le Markdown ne produise du HTML invalide.

Hyperlien décrit, mais sans URL

[Description d’un lien mais pas de lien]()

<a href>Description d’un lien mais pas de lien</a> (href non rempli)

Warning: <a> attribute "href" lacks value

Tableau mais sans contenu

|Colonne 1|Colonne 2|
|---------|---------|

<table>
<thead>
<tr>
<th>Colonne 1</th>
<th>Colonne 2</th>
</tr>
</thead>
<tbody>
</tbody> (tbody vide)

Warning: trimming empty <tbody>

Élément de liste vide

* coin
*

avec un <li> vide invalide

<ul>
<li>coin</li>
<li>
</li>
</ul>

Warning: trimming empty <li>

Spans vides sur la coloration syntaxique

<?php
class Hello {
    static $t = <<<EOT
<br/>
EOT;
?>

avec deux <span> vides

<pre><code class="php"><span class="o">&lt;?</span><span class="nx">php</span>
<span class="k">class</span> <span class="nc">Hello</span> <span class="p">{</span>
    <span class="k">static</span> <span class="nv">$t</span> <span class="o">=</span> <span class="s">&lt;&lt;&lt;</span><span class="dl">EOT</span><span class="s"></span>
<span class="s">&lt;br/&gt;</span>
<span class="dl">EOT</span><span class="p">;</span>
<span class="cp">?&gt;</span><span class="x"></span></code></pre>

Warning: trimming empty <span>

Conversion de lien Wikipédia

[[Benoît Mandelbrot]]

qui produisait avant l’invalide href avec espace

<a href="http://fr.wikipedia.org/wiki/Benoît Mandelbrot" title="Définition Wikipédia">Benoît Mandelbrot</a>

mais qui a été corrigé depuis en

<a href="https://fr.wikipedia.org/wiki/Beno%C3%AEt%20Mandelbrot" title="Définition Wikipédia">Benoît Mandelbrot</a>

donc il suffit de forcer la régénération du HTML depuis le Markdown.

Réinitialisation de l’indice des notes de bas de page entre la 1ʳᵉ partie et la 2ᵈᵉ partie

Entrée de suivi déjà existante

Warning: <sup> anchor "fnref1" already defined
Warning: <li> anchor "fn1" already defined

C’était plus compliqué que prévu, mais est-ce que c’est mieux après ?

Durant le bref temps de rédaction de cette dépêche, soit entre le 6 octobre 2018 et le 30 décembre 2021, le site est passé de 25 249 dépêches publiées à 26 692 dépêches publiées. Regardons ce qui a changé.

série	HTML valide 2018	HTML invalide en 2018	%HTML invalide 2018	source HTML 2018	source markdown 2018	%source markdown 2018	HTML valide 2021	HTML invalide 2021	%HTML invalide 2021	source HTML 2021	source markdown 2021	%source markdown 2021	total dépêches
0xxxx	5534	207	3,6%	5805	2	0,0%	5593	147	2,6%	5737	3	0,1%	5740
1xxxx	4716	147	3,0%	4861	2	0,0%	4765	98	2,0%	4859	4	0,1%	4863
2xxxx	6144	881	12,5%	5693	1332	19,0%	6413	612	8,7%	5694	1331	18,9%	7025
3xxxx (*)	8296	188	2,2%	3222	5262	62,0%	8301	183	2,2%	2893	5591	68,4%	8484
4xxxx							566	14	2,4%	0	580	100,0%	580
total	24690	1423	5,4%	19581	6598	25,2%	25638	1054	3,9%	19183	7509	28,1%	26692

(*) données extrapolées de 7621 à 8484 dépêches pour correspondre à 2021

Conclusions ?

• de nombreuses dépêches sont désormais valides niveau HTML (369 devenues valides en absolu, et passage de 5,4% d’invalides à 3,9% en relatif) ;
• il y a moins de pages en HTML « en dur » et davantage en Markdown, ce qui facilitera de futures migrations (398 converties en absolu, et passage de 25,2% à 28,1% en relatif) ;
• on en déduit que dans à peine une dizaine d’années à ce rythme, tout sera valide et en markdown (promesse non contractuelle) ;
• petit rappel, on avait dit « faisons simple » donc là n’ont pas été regardés les journaux, les entrées de forum, les sondages, les liens, les pages wiki, les entrées du suivi, les commentaires, les titres, les étiquettes, les infos sur les autrice(s)/contributrice(s)/modératrice(s), les dates, etc. ;
• ajout du pénible : notons que tidy a probablement des limites aussi, et puis n’ont pas été regardés le Javascript ou les feuilles de style CSS ou l’EPUB ou… bref vous avez l’idée ;
• une entrée de suivi a été créée pour éviter que le Markdown ne produise du HTML invalide.