[Mini-FAQ] Le HTML dans les news

julienl+faq@teaser.fr (Julien Lenglet)

Archive-Name: fr/minis-faqs/html-dans-les-news

Bonjour,

Cette FAQ a été rédigée par Émilie Danna et est désormais mise à 
jour par votre serviteur, Julien Lenglet (julienl+faq@teaser.fr).
Pour tout commentaire ou pour signaler une erreur, une coquille,
etc, n'hésitez pas à contacter le mainteneur.

Sommaire

1. Situation actuelle : pas de HTML sur Usenet
2. Les inconvénients du HTML
        2.1. Trois fois plus à transporter et à stocker
        2.2. L'augmentation de la capacité des disques durs, de la
             rapidité des liaisons et du trafic
3. Les avantages supposés du HTML
        3.1. Lisibilité
        3.2. Les caractères non-latins, les formules mathématiques et
             les images
4. Les autres formats
5. Remerciements



1. Situation actuelle : pas de HTML sur Usenet

Le HTML est prohibé dans toutes les chartes des groupes de la
hiérarchie fr. Il est également fortement déconseillé dans tous les
groupes du Big 8 (comp, humanities, misc, news, rec, sci, soc, talk)
ainsi que dans les groupes non-binaires de alt.* et toutes les autres
hiérarchies régionales à ma connaissance. Autrement dit, l'usage du
HTML est autorisé, à ma connaissance, uniquement dans les
pseudo-groupes du pseudo-réseau Niouzenet et dans la hiérarchie
microsoft.*.

Plus efficacement, sur la plupart des serveurs de nouvelles
administrés, tous les articles en HTML ou avec une partie texte et une
partie HTML (multipart/alternative ou multipart/mixed) sont
automatiquement filtrés, c'est-à-dire qu'ils n'apparaissent pas sur le
serveur où le filtre adéquat est en place, mais continuent de se
propager sur les serveurs qui ne filtrent pas. Concrètement, cela
signifie que vos articles ne passent pas sur de nombreux serveurs.

Ce filtrage est possible grâce à cleanfeed, utilisé majoritairement
avec le serveur INN, avec les variables block_html, block_mime_html et
html_allowed.

<URL:http://www.exit109.com/~jeremy/news/cleanfeed.html>

Ce filtrage est également intégré au serveur DNews:
Dans newsfeeds.conf, mettre dans la section qui concerne le "me" du
feed:

reject article "\ncontent-type: text/html"
reject article "\nContent-Type: multipart/alternative"

Empiriquement, on constate que

reject body "\ncontent-type: text/html"
reject article_header "\ncontent-type: text/html"

est plus efficace.


De plus, tous les lecteurs de nouvelles ne lisent pas le HTML.

Lecteurs qui peuvent afficher directement du HTML: Netscape, Outlook
Express, trn4 (en texte)

Lecteurs qui ne peuvent pas afficher directement du HTML: Gnus, Free
Agent, Agent, slrn, ...

2. Les inconvénients du HTML

2.1. Trois fois plus à transporter et à stocker

Les articles en HTML prennent en moyenne environ 3 fois plus de place
que les mêmes articles en texte brut seulement. 

En effet, comme une grande partie des lecteurs de nouvelles ne peuvent
pas afficher le HTML, il faut doubler la contribution en HTML de son
équivalent en texte brut. On obtient ainsi des articles de la
composition suivante:

Dans les en-têtes de l'article:

        MIME-Version: 1.0
        Content-Type: multipart/alternative;
boundary="----=_tralalalalala"

Et dans le corps de l'article:

        Message en plusieurs parties et au format MIME.

        ----=_tralalalalala
        Content-Type: text/plain; charset="iso-8859-1"
        Content-Transfer-Encoding: quoted-printable

        <ici le texte brut>

        ----=_tralalalalala
        Content-Type: text/html; charset="iso-8859-1"
        Content-Transfer-Encoding: quoted-printable

        <ici le même texte en HTML, docn avec des balises en plus>

        ----=_tralalalalala--

Comme le texte en HTML prend, à cause des balises approximativement
deux fois plus de place que la même contribution en texte brut, on
obtient en définitive un article 3 fois plus gros.

Ce rapport de 3 à 1 est naturellement une moyenne. Pour un article
court à la mise en page surchargée, il est plus élevé; pour un article
long de type FAQ où seuls les titres des paragraphes sont mis en
valeur, il est moindre.

De plus, l'encodage utilisé par défaut par de tels articles, le
quoted-printable (QP), est lui aussi déconseillé et mal décodé par de
quelques logiciels de lecture de news.


2.2. L'augmentation de la capacité des disques durs, de la rapidité
     des liaisons et du trafic

Certes la capacité des disques durs a fortement augmenté, la bande
passante aussi et les modems sont plus rapides, mais:

- Le trafic a aussi augmenté, et ce continûment et beaucoup plus vite
  que la rapidité des modems ou la capacité des disques durs. Personne
  n'est disposé à augmenter sa facture téléphonique ou à saturer sa LS
  ou à acheter continuellement des disques durs de qualité pour le
  serveur de news dont il est responsable et pour lequel son budget
  est en général réduit. Cette augmentation du trafic a fait
  disparaître les "vrais" feeds complets qui demandent trop de
  ressources (en décembre 1998: environ 23 Go par jour pour un feed
  complet, 14 Mo par jour pour fr). Pour avoir une idée plus précise,
  je cherche des chiffres (réels, pas de prévision) sur au moins
  quelques mois pour la taille d'un feed (nombre de Mo par jour), mais
  uniquement pour des hiérarchies "texte", par exemple le Big 8 ou fr,
  ou même alt sans les binaires.

- À la limite, l'augmentation de ressources nécessaire à la
  propagation du HTML serait acceptable si le HTML apportait
  réellement quelque chose à Usenet, ce qui est faux, comme nous
  allons le voir maintenant.


3. Les avantages supposés du HTML

3.1. Lisibilité

Le HTML permet de "mettre en page" le texte, c'est-à-dire de changer
la police, la taille, la couleur du texte, la texture du fond, etc. 
Cette possibilité devrait augmenter la libilité des articles,
cependant:

- Le HTML ne permet pas d'entrelacer les citations proprement: il est
  incapable de montrer correctement qu'un texte est cité et qu'à
  l'intérieur de ce texte cité, un autre texte est cité, etc. Il ne
  dispose donc pas d'une fonction essentielle à Usenet où le plus
  important pour augmenter la lisibilité est de montrer clairement, par
  des couleurs différentes par exemple, qui a écrit quel texte et par
  qui il est cité.

- De nombreux lecteurs de nouvelles permettent déjà de distinguer par
  des couleurs distinctes les différentes citations, en mettant dans
  la même couleur le texte écrit et la ligne d'attribution de ce même
  texte, c'est-à-dire la ligne du type « Le 2 Feb 1998, Marcel Dugenou
  écrivait: ». Il serait maldroit de critiquer un format (le texte
  brut) alors que le responsable de tous vos malheurs est en fait le
  logiciel qui exploite mal ce format (par exemple Outlook Express).  

- Les couleurs choisies par les intervenants ne sont pas toujours du
  meilleur goût et diminuent parfois la lisibilité. Un texte vert sur
  un fond rouge est illisible. La balise <BLINK> a déjà fait des
  ravages sur le web, inutile de la transposer sur Usenet. 
  Au contraire, chacun peut configurer son lecteur de nouvelles pour
  que les couleurs, la taille de la police, ..., correspondent le
  mieux à son confort personnel.

- Le HTML n'est pas fait pour la mise en page d'un document mais pour
  sa structuration. Utiliser le HTML dans les news pour faire
  clignoter FREE en 3D et en rose fluo n'est pas une utilisation
  canonique du HTML.
  Donc, le HTML n'est pas adapté à Usenet où les articles sont en
  général courts et peu structurés. La seule utilité serait de
  faciliter la lecture des FAQ et autres documents de référence dont
  la lecture en texte brut peut être fastidieuse. Mais, c'est bien
  connu, personne ne lit les FAQ (sauf accidentellement leurs
  valeureux auteurs). De plus, les FAQ sont en général automatiquement
  archivées en HTML. Pour la hiérarchie fr, elles sont disponibles
  sous ce format à <URL:http://www.usenet-fr.news.eu.org/>

- Certains lecteurs de news comprennent déjà un formatage basique
  du texte:
        /blabla/ pour l'italique
        *blabla* pour le gras
        _blabla_ pour souligner

- Le « problème » des lignes coupées: le HTML a autant de problèmes
  avec les lignes trop longues que tout système utilisant du texte
  brut pour décrire des paragraphes. Ce n'est pas apparent parce que
  les navigateurs formatent à la volée le texte pour que les lignes
  occupent toute la largeur de l'écran ou de la fenêtre. Or, non
  seulement il est plus efficace en termes de temps de calcul que
  celui qui émet le message le formate bien plutôt que chacun des
  lecteurs aient à le reformater. Mais, de plus, avec la marge de
  sécurité des 72 caractères maximum par ligne (ce qui autorise 4
  niveaux de citation qui ajoutent chacun deux caractères en début de
  ligne: "> "), il n'y a pratiquement aucun problème avec tous les
  lecteurs de nouvelles, même ceux se contentant d'afficher simplement
  le texte de 80 colonnes sans le reformater pour le bien-être de
  l'utilisateur. Des problèmes ne se rencontrent qu'avec Outlook
  Express qui est notoirement incapable de citer le message d'un autre
  sans le rendre illisible (alternance de lignes de différentes
  longueurs, précédées ou non de caractères de citation).

- Pour augmenter la qualité du message, il est d'abord nécessaire de
  soigner l'orthographe et la grammaire, la ponctuation, la bonne
  structuration des idées, la concision, etc.  L'expérience montre que
  le soin apporté à ces différents points est plus efficace en terme
  de clarté et de lisibilité du discours, que l'utilisation de
  couleurs ou fontes particulières. Il suffit d'examiner n'importe
  quel livre pour s'en convaincre.

3.2. Les caractères non-latins, les formules mathématiques et les images

- Pour les caractères non-latins (grecs, chinois, japonais, ...), le
  HTML est inutile, il suffit d'avoir les bonnes en-têtes:

        Mime-Version: 1.0
        Content-Type: text/plain; charset=iso-qui-va-bien
        Content-Transfer-Encoding: 8bit

- Le HTML n'est pas adapté pour transmettre les formules
  mathématiques. MathML est encore très peu utilisé, donc il ne reste
  que les images (voir le dernier paragraphe). Lire les conseils
  publiés régulièrement sur fr.sci.maths pour écrire le mieux possible
  les formules mathématiques.

- Le HTML n'est pas non plus adapté pour transporter les images. En
  effet, tous les binaires sont interdits sur fr, filtrés de la même
  façon que le HTML et annulés par un robot.
  Pour montrer une image, il suffit de donner un lien vers un site web
  ou ftp où l'on aura stocké cette image.
  Pour des schémas, d'électronique par exemple, il existe des
  programmes transformant des images en « art ASCII », c'est à dire en
  les représentant à l'aide des caractères ASCII.

4. Les autres formats et les autres médias

4.1. Les autres formats

- D'après ce qui précède, l'idéal serait un formatage basique du texte
  pour mettre en gras, en italique et souligner. Ce format existe:
  c'est le texte/enriched décrit dans la RFC 1896.

- D'autres expériences ont été menées pour transporter les
  caractéristiques de la mise en page séparément du texte auquel elle
  s'applique. Lire <URL:http://www.templetons.com/brad/oob.txt>
  Un système similaire (proletext) et du même auteur est utilisé dans la
  hiérarchie clari.*

- XML/CSS est très à la mode en ce moment et c'est un format qui
  semble intelligent. Cependant, il présente les mêmes inconvénients
  que le HTML, en particulier en ce qui concerne la taille des
  messages (les définitions des styles et les tags prenant plus de
  place que le contenu du message).

4.2. Les autres médias

Tous les arguments exposés ci-dessus s'appliquent aussi au mail à la
nuance près que le mail (hors liste de diffusion) est un média privé
qui ne concerne que les correspondants qui peuvent donc trouver un
format commun autre que le texte/brut. Ce qui n'exclut pas qu'il est
inconvenant d'envoyer un mail en HTML sans s'enquérir d'abord si son
correspondant veut et peut le lire.

5. Remerciements

Merci à...

- tous les intervenants de fr.usenet.* et fr.comp.mail qui ont exposé
  les arguments qui se trouvent dans cette FAQ
- tous les relecteurs: Pascal Petit, Éric Demeester, Thomas Parmelan,
  Michel Guillou, Sylviane Jacquemin, Christian Perrier, Cédric Beust
- tous les intervenants de fr.* qui liront cette FAQ au lieu de
  débattre encore une fois de ce sujet sur les groupes que je lis.

[Retour au sommaire]