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
- 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.1
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&mode&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"><?</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"><<<</span><span class="dl">EOT</span><span class="s"></span>
<span class="s"><br/></span>
<span class="dl">EOT</span><span class="p">;</span>
<span class="cp">?></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.
# Erreurs de statistiques
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
Ah ben voilà on se dépêche pour produire une dépêche en moins de trois ans, et au final on a une erreur de statistiques dans la première version publiée… Les chiffres de conversion Markdown sont plus faibles qu'initialement annoncés, la dépêche a été rectifiée.
L'erreur venait d'un comptage des éditions de dépêches (table
news_versions
) au lieu des paragraphes qui convertissent Markdown en HTML (tableparagraphs
). Or on peut avoir des versions de dépêches en HTML, par contre il faut nécessairement des paragraphes pour avoir du Markdown.Au final, il y a juste 24 travaux d'Hercule au lieu de 12, ça ne change pas fondamentalement la taille du tas ou de la pile, hormis le fait que ça fait une très grosse allocation initiale…
Il manque aussi une info dans la dépêche : un des intérêts d'avoir du HTML valide pour les dépêches en HTML, c'est que l'on peut espérer convertir automatiquement plus facilement du HTML initialement valide en Markdown que convertir une soupe de balises en sacrifiant des poulets pour obtenir un résultat d'autant plus incertain.
[^] # Re: Erreurs de statistiques
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4.
Un autre intérêt que je vois à avoir du html valide pour les dépêches en html est que ça doit donner de l'epub de meilleure qualité (indépendamment du fait que c'est effectivement plus clément pour les poulets).
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Erreurs de statistiques
Posté par antistress (site web personnel) . Évalué à 7.
Ca doit aussi donner du HTML de meilleure qualité, note bien !
# Problème de langage
Posté par kowalsky . Évalué à 10.
Bonjour,
Je suis architecte transverse web en SSII et je peux répondre à ta question sur la validité HTML de LinuxFR. Le site n'ayant pas été réalisé en Java, il ne peut donc pas bénéficier des bons framework permettant de générer du HTML valide.
N'hésite pas à me solliciter pour que mon équipe d'ingénieur te fasse parvenir une étude sur la migration de votre blog communautaire vers Java.
Cordialement,
[^] # Re: Problème de langage
Posté par Raphaël G. (site web personnel) . Évalué à 4.
On te remercie oh apôtre du saint langage qui a récemment fait une opération portes grandes ouvertes grandiose sur tous les serveurs faisant usage d'une minuscule bibliothèque log4j via l'injection d'une petite ligne sympathique dans le journal de bord _^
[^] # Re: Problème de langage
Posté par kowalsky . Évalué à 5.
C'est de l'opensource ou pas ?
Les trois libertés du libre, même pour du code qui tourne coté serveur :
Tout le monde peut voir le code, tout le monde peut voir les logs, tout le monde peut exécuter du code.
[^] # Re: Problème de langage
Posté par Raphaël G. (site web personnel) . Évalué à 1.
J'ai l'impression que les développeurs de log4j ont voulu appliquer à tout l'open source les droits de l'Affero GPL, et dans leur fougue emprunt de liberté, ont maintenu cet esprit dans leurs correctifs à 3 reprises.
Grâce à ce bout de code purement libéral tous les serveurs en faisant usage se sont trouvés en accès parfaitement libre, quel beau projet "open4real" © ® ™ :
- données privées
- mots de passes
- ressources serveurs
- etc
Finalement cette bibliothèque open source est vraiment la quintessence du logiciel super libre.
Miner du shitcoin, récupérer de la donnée privée par hameçonnage, faire du voyeurisme sur les données privées des autres, tout est possible avec une simple formule magique qui s'énonce en une ligne :)
Finalement le Java c'est l'avenir du progrès libéré des contraintes de sécurité du passé :p
[^] # Re: Problème de langage
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Le W3C a décrété que seuls des framework Java permettent d'avoir du HTML valide ? Manque de bol, une poignée d'irréductibles rubistes a su pondre des pages valides sur les rails.
Tu peux donc annoncer à tes ingénieurs que tu as réussi à les mettre au chômage et qu'il y a maintenant du temps pour contempler la jivéhème.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Problème de langage
Posté par Faya . Évalué à 6.
Ou c'est juste de l'humour (cf. la note du commentaire en question)
[^] # Re: Problème de langage
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 02 février 2022 à 11:01.
Pour rappel : "LinuxFR en J2EE", 13 ans déjà !
[^] # Re: Problème de langage
Posté par kowalsky . Évalué à 3.
Mais même avant cela, c'est un fait établit dans les plus grandes écoles d’ingénieur que faire un blog comme LinuxFR en autre chose que Java est une erreur. Notamment grâce au driver JDBC qui supprime beaucoup de problème de sécurité.
[^] # Re: Problème de langage
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 2.
LinuxFr n'est pas un blog, c'est un site, pas tout à fait pareil. Et je trouve assez péjoratif de traiter LinuxFr de blog pour tout dire.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Problème de langage
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
On a encore franchi un cap : Être assimilé à wordpress ou blogspop, qui au passage ne sont pas écrits en avaj…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Problème de langage
Posté par Crao . Évalué à 4.
C'est toujours aussi amusant de voir comment les diplômés de l’académie du premier degré réagissent ;)
[^] # Re: Problème de langage
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3.
J'ai déjà entendu parler sérieusement de LinuxFr comme un blog. Et si on ne trouve pas ça drôle c'est que ça n'est pas si bien amené que ça…
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Problème de langage
Posté par kowalsky . Évalué à 3.
Je pense que tu ne te souviens pas de la grande époque de LinuxFR. C'est un gag récurent, à l'époque des journaux sur les motos et l'avortement.
Lis le lien sur linuxfr en J2EE, c'est intéressant sur la culture de ce blog communautaire qu'est LinuxFr.
[^] # Re: Problème de langage
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Fallait pas oublier de chatouiller la plante des pieds.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.