Validité HTML des pages sur LinuxFr.org

Posté par  (site web personnel) . Édité par Anonyme, BAud, pulkomandy, Nils Ratusznik, Yves Bourguignon, Ysabeau 🧶, bobble bubble, tisaac et NeoX. Modéré par Ysabeau 🧶. Licence CC By‑SA.
Étiquettes :
53
31
déc.
2021
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?

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&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.
  • # Erreurs de statistiques

    Posté par  (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 (table paragraphs). 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  (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é.

  • # Problème de langage

    Posté par  . É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  (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  . É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  (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  (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  . Évalué à 1.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Problème de langage

        Posté par  . Évalué à 6.

        c'est soit avoir des oeillères technologiques de la taille de la Silicon Valley, soit d'une malhonnêteté intellectuelle flagrante.

        Ou c'est juste de l'humour (cf. la note du commentaire en question)

        • [^] # Re: Problème de langage

          Posté par  (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  . É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  (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  (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  . É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  (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  . É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  (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.