Sondage Les courriels en HTML...

Posté par . Licence CC by-sa
10
24
juil.
2015

c'est le Mal, tout le monde le sait.

La résistance est-elle futile ?

  • Plain test rulz, FTW! Mon serveur/courrielleur envoie ça dans /dev/null :
    63
    (3.2 %)
  • J'écris toujours en texte brut et mon courrielleur me présente les message HTML en texte brut :
    326
    (16.4 %)
  • Je lis les messages HTML en texte brut mais je dois régulièrement consulter la version HTML pour y comprendre quelque chose :
    147
    (7.4 %)
  • J'affiche les messages reçus en HTML, mais j'écris en texte brut autant que possible :
    806
    (40.6 %)
  • Je lis/écris en HTML, mais j'essaye de ne pas abuser des couleurs :
    512
    (25.8 %)
  • Comic sans MS rulz! En plus, j'ai des super images de fond pour mes messages ! :
    130
    (6.6 %)

Total : 1984 votes

La liste des options proposées est volontairement limitée : tout l'intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées, ou de l'impossibilité de choisir plusieurs réponses. 76,78% des sondés estiment que ces sondages sont ineptes.
  • # Format riche

    Posté par . Évalué à 3.

    Y a t-il eu des tentatives de format riches pour les courriels? un rfc quelque part?

    En quoi le HTML est mal? C'est plutôt le Javascript qui est dangereux, il suffirait à nos chères MUA de ne pas l'interprêter. Il faudrait aussi interdir les hrefs externes.

    Après oui, un email n'est pas supposé être un document de composition.

    • [^] # Re: Format riche

      Posté par (page perso) . Évalué à 4.

      tu as sans doute raté http://arc.pasp.de/ avec l'ASCII Ribbon campaign :-)

      Plus globalement, j'ai recensé http://faq.tuxfamily.org/CommunicationLibreInternet/Fr#Pour_vos_mails je veux bien d'autres suggestions pertinentes :-)

      • [^] # Re: Format riche

        Posté par . Évalué à 1.

        Pas convaincu, c'est au MUA de limiter les possibilités à défaut d'avoir le format "idéal".

    • [^] # Re: Format riche

      Posté par . Évalué à 1.

      Après oui, un email n'est pas supposé être un document de composition.

      je trouve cette remarque intéressante : je fulmine assez souvent contre des courriels sans autre contenu qu'une pièce jointe, souvent un fichier word ou un scan d'un fichier word, que mon client mail stocke dans un dossier temporaire avant d'ouvrir en invoquant une appli externe, parfois un blob.
      La plupart du temps, thunderbird, mon MUA comme tu me l'a justement rappelé, aurait fait l'affaire pour envoyer le message : choix de la police, de sa couleur et de sa taille, des puces, l'insertion de quelques images. Pas besoin de js comme tu dis.

      Si on regarde les résultats du sondage, on voit que le texte brut est prioritaire, mais mon navigateur affiche aussi :

      des citations

      • du texte en gras, en italique ou complètement barré

      On peut voir le même contenu sans avoir installé flash, mais pas sous links ni lynx. A contrario, il ne me semble pas possible de centre du texte par exemple, ou de faire un tableau, dans l'éditeur wɪziwig de linuxfr. Peut-être que parfois ça serait utile ?

  • # mutt

    Posté par . Évalué à 5.

    Bon, le HTML avec mutt, au moins, je peux dire à mes correspondants:

    "désolé, j'ai rien compris à ton message…".

    Sinon, pour de vrai, lorsque je reçois mes mails, je les passent dans une moulinette qui vérifie si le mail est en HTML, auquel cas, si il n'y pas de multipart text/plain, en rajoute une avec le rendu du HTML par links2.

    Ça marche assez bien au final, et je ne redoute plus de souffrir d'epilepsie lorsque je lis mes mails ! ;-]

    Hop,
    Moi.

  • # C'est quoi le problème ?

    Posté par . Évalué à 6.

    Je ne comprends pas ce qu'est le problème avec le format TML, moi je trouve ça très pratique pour écrire des emails lisibles.

    • [^] # Re: C'est quoi le problème ?

      Posté par . Évalué à -1.

      Moi non plus je n'ai jamais eu de probleme avec les mails en html… Du coup je lis mes mail en html. En revanche j'en envoi casiment jamais, et comme j'y connais rien en html…

    • [^] # Re: C'est quoi le problème ?

      Posté par (page perso) . Évalué à 8.

      Je ne comprends pas ce qu'est le problème avec le format TML, moi je trouve ça très pratique pour écrire des emails lisibles.

      Quoter (citer) un mail HTML est assez difficile (https://en.wikipedia.org/wiki/Posting_style#Quoted_line_prefix). Voila mon principale problème avec les mails HTML.

      Étant donné que c'est difficile de Quoter en HTML, les gens répondent avec des couleurs dans le mail et là c'est la catastrophe, cela devient illisible et déstructuré.

      • [^] # Re: C'est quoi le problème ?

        Posté par (page perso) . Évalué à -2.

        Le texte brut c’est assez horrible dans son propre style aussi. Genre:

        • Taille fixée par la personne qui écrit le courriel, c’est pas acceptable sur le web mais dans les courriels c’est bon?
        • Retour à la ligne d’un ou deux mots à la fin de chaque ligne si son client ne coupe à la même longueur que le client de l’autre personne
        • Moche (ça me gêne pas d’écrire en Markdown mais j’aime bien le rendu HTML quand même, ou le rendu coloré de mon éditeur de texte)

        Du coup l’HTML n’est pas parfait mais je le trouve beaucoup plus pratique pour composer que le texte brut. D’autre part, un·e de mes correspondant·e·s ayant arrêté d’utiliser Incredimail, la quasi-totalité des courriels sont tout à fait acceptables dans leur usage du HTML.

        Enfin bon, il reste le TOFU, les signatures «Envoyé depuis mon Pouet», et les courriels des entreprises/université avec leur signature si délicates.

        Pour ce dernier cas, le meilleur exemple que j’ai vu est:

        [Nom] [Prénom]
        [Fonction dans l’école]

        Tel: [numéro de téléphone]
        [Adresse de l’école]
        [Ligne de tiret]
        [Lien vers le site de l’école]
        [Lien vers le site d’une autre école du même groupe]

        Suivez-nous sur

        [Image de Facebook] [Image de Twitter]

        Think before printing [gné? tout le reste est en français]

        En fait, les pires courriels que je reçois sont ceux des étudiants en école d’ingénieur (souvenirs des courriels dont le contenu est aussi pauvre que la forme est ostentatoire).

        Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: C'est quoi le problème ?

          Posté par . Évalué à 4.

          Ton (bon) client n'a pas à couper un message en pur texte brut (en flowed, il peut, mais c'est un format pas toujours approprié). Ces messages s'écrivent historiquement sur 65 colonnes, mais tu peux exiger de n'importe qui de ne pas dépasser 80 colonnes. De toutes façons, vu le nombre de gros projets (le noyau Linux, au hasard) qui se structurent autour de listes de diffusion en texte brut, ça se saurait si ce format était réellement handicapant.

        • [^] # Re: C'est quoi le problème ?

          Posté par (page perso) . Évalué à 6.

          Taille fixée par la personne qui écrit le courriel

          Là je dois forcément mal comprendre de quoi tu parles, parce que précisément en texte brut l’émetteur n’envoie aucune information de mise en forme (y compris la taille). C’est le destinataire qui choisit la taille de la police d’affichage dans son client de messagerie.

          Retour à la ligne d’un ou deux mots à la fin de chaque ligne si son client ne coupe à la même longueur que le client de l’autre personne

          format=flowed, spécifié depuis au moins seize ans. Enough said.

          Moche

          Question de goût. Pour ma part, je trouve que la plupart de ceux qui écrivent des mails en HTML ont des goûts tellement déplorables en matière de choix de police, de graisse, de soulignement et de couleurs, que je préférerai toujours le rendu du texte brut — il est peut-être moche mais au moins il est uniforme, et je choisis la taille, la police et la couleur, merci.

          Ah zut, j’ai marché dedans.

          • [^] # Re: C'est quoi le problème ?

            Posté par (page perso) . Évalué à 2.

            Taille fixée par la personne qui écrit le courriel

            Là je dois forcément mal comprendre de quoi tu parles, parce que précisément en texte brut l’émetteur n’envoie aucune information de mise en forme (y compris la taille). C’est le destinataire qui choisit la taille de la police d’affichage dans son client de messagerie.

            Je parlais de taille de ligne.

            Retour à la ligne d’un ou deux mots à la fin de chaque ligne si son client ne coupe à la même longueur que le client de l’autre personne

            format=flowed, spécifié depuis au moins seize ans.

            C’est un peu ironique de citer un document écrit en taille fixe. ;)

            Enough said.

            … ou pas? En pratique je reçois des courriels qui prennent la taille qu’ils veulent sur mon écran et c’est bien relou.

            Moche

            Question de goût. Pour ma part, je trouve que la plupart de ceux qui écrivent des mails en HTML ont des goûts tellement déplorables en matière de choix de police, de graisse, de soulignement et de couleurs, que je préférerai toujours le rendu du texte brut — il est peut-être moche mais au moins il est uniforme, et je choisis la taille, la police et la couleur, merci.

            Je sais que c’est une question de gout, mais bon mettre des chevrons au début de chaque ligne de texte citée je trouve ça un peu horrible au 21e siècle. La rédaction en HTML dans Thunderbird ça juste marche, c’est pas parfait mais c’est plus simple pour moi et pour la plupart des gens avec qui je discute.

            Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: C'est quoi le problème ?

              Posté par . Évalué à 6.

              Par défaut, Thunderbird envoie une version HTML et une version texte brut de ton courriel, ce qui explique que tu n'aies pas de problèmes mais double (je suis gentil) le trafic pour rien ou presque.

              Pour le reste, il y a des RFCs, dont la Netiquette (RFC 1855) qui spécifie qu'idéalement les courriels doivent être écrits sur 65 caractères (pour permettre ensuite plusieurs niveaux de citation sans difficulté). Il suffit juste d'apprendre aux gens à se servir de leur client de courriel en suivant cette règle. Mais il est vrai qu'au XXIe siècle partir du principe qu'il faut apprendre quoi que ce soit est délirant et scandaleusement élitiste. Autant pondre de bonnes grosses usines à gaz démocratiques à l'usage des macaques, puis ensuite se lamenter que les gens passent leur temps à s'envoyer du caca sur fèces-book au lieu de faire du oueb…

              • [^] # Re: C'est quoi le problème ?

                Posté par (page perso) . Évalué à 2.

                Par défaut, Thunderbird envoie une version HTML et une version texte brut de ton courriel, ce qui explique que tu n'aies pas de problèmes mais double (je suis gentil) le trafic pour rien ou presque.

                C’est pas pour le poids de la version texte…

                Pour le reste, il y a des RFCs, dont la Netiquette (RFC 1855) qui spécifie qu'idéalement les courriels doivent être écrits sur 65 caractères (pour permettre ensuite plusieurs niveaux de citation sans difficulté).

                Et donc ça ne devrait jamais changer? On devrait se compliquer la vie pour une limitation technique des années 80?

                Il suffit juste d'apprendre aux gens à se servir de leur client de courriel en suivant cette règle. Mais il est vrai qu'au XXIe siècle partir du principe qu'il faut apprendre quoi que ce soit est délirant et scandaleusement élitiste.

                J’utilise mon client comme il faut, tout le monde peut lire mes courriels.

                Autant pondre de bonnes grosses usines à gaz démocratiques à l'usage des macaques, puis ensuite se lamenter que les gens passent leur temps à s'envoyer du caca sur fèces-book au lieu de faire du oueb…

                blablabla.

                Écrit en Bépo selon l’orthographe de 1990

                • [^] # Re: C'est quoi le problème ?

                  Posté par . Évalué à 3.

                  C’est pas pour le poids de la version texte…

                  Tu n'es pas le seul à envoyer des courriels, prends par exemple le trafic sur les listes très fréquentées (dont la LKML, par exemple), le multiplier par deux est beaucoup moins anodin.

                  Et donc ça ne devrait jamais changer? On devrait se compliquer la vie pour une limitation technique des années 80?

                  La RFC 1855 date de 1995, c'est marqué dessus… dois-je en conclure que le texte brut n'est pas vraiment le cœur de tes difficultés de communication ?

                  Quand tu as un usage éprouvé qui perdure chez des gens numériquement très compétents dont c'est le moyen principal de communication (la LKML, par exemple, bis repetita, Linus reconnaissant par ailleurs que son boulot consiste essentiellement à lire des courriels et à y répondre), il est certes possible mais quand même peu probable que ce soit par simple amour du temps jadis, tu ne crois pas ?

                  J’utilise mon client comme il faut, tout le monde peut lire mes courriels.

                  Je t'ai expliqué la raison probable de ce fait. Tout comme je t'ai exposé que ce n'est pas parce qu'un mésusage est massif qu'il en devient correct.

                  • [^] # Re: C'est quoi le problème ?

                    Posté par . Évalué à 2. Dernière modification le 02/08/15 à 11:07.

                    1995, 20 ans. Soit deux siècles en informatique, environ…

                    A ce compte là, on peut aussi dire que Windows 95 reste un OS moderne, hein…

                    65 colonnes sur un écran d'aujourd'hui ça passe largement, je pense que ça passe largement tu sais… On pourrait au moins passer à 80 colonnes…

                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                    • [^] # Re: C'est quoi le problème ?

                      Posté par . Évalué à 4. Dernière modification le 02/08/15 à 16:11.

                      On pourrait aussi imaginer que :

                      • il y ait des environnements où X n'est pas disponible et où les gens, plutôt que de se connecter à N ttys, profiteraient qu'on n'est plus en 95 pour utiliser un multiplexeur sur un seul. Multiplexeur qui, soyons fous, pourrait scinder l'écran, si bien que ce genre de limites serait encore tout à fait pertinent ;
                      • des gens trouvent le concept ci-dessus si efficace qu'ils se mettent à utiliser sous X des gestionnaires de fenêtres pavant et râlent ensuite parce qu'ils sont obligés de mettre leurs applications en plein écran juste à cause de pinpins infoutus de couper les lignes de leurs courriels ;
                      • il y ait encore des gens, mais là après deux siècles d'informatique c'est effectivement de la SF dystopique, survolant les liens qu'on leur donne. Par exemple la RFC 2646 du format flowed, qui non seulement répond une fois de plus aux difficultés soulevées, mais de surcroît rappelle que la limite de 65 caractères reste pertinente pour une raison de pure lisibilité (la même qui probablement fait que les journaux font courir les lignes sur de petites colonnes au lieu de les étaler sur deux pages au prétexte qu'il y a la place).
                      • [^] # Re: C'est quoi le problème ?

                        Posté par (page perso) . Évalué à 2.

                        Je critique que le fait qu’on utilise des formats avec des lignes fixes alors qu’on pourrait écrire sans s’en soucier (comme à peu près n’importe quel champ de texte dans sur un site web, ou un logiciel de traitement de texte, ou un éditeur de texte brut configuré pour ça), et que les lignes soient affichées pour s’adapter à la taille de la fenêtre (comme à peu près n’importe quel site sur le web, un logiciel de traitement de texte, ou un éditeur de texte brut configuré pour ça).

                        Je disais également que dans bien que la RFC 2646 du format flowed était censé réglé tous les problèmes que j’ai mentionné, si je les ait mentionné c’est qu’ils sont réels (d’ailleurs je viens de recevoir un courriel plein texte qui s’affiche correctement, la preuve que ça arrive). D’autre part, dire que la limitation de 65 caractères est pertinente est une connerie, on code pas une information d’affichage dans le format pour ensuite bidouiller pour le réafficher avec une longueur de ligne différente, pour bidouiller pour que lors de l’édition on respecte toujours la longueur de ligne, c’est un non-sens.

                        Après on peut se battre sur quel personne est la plus chiante, toi qui est obligé de «applications en plein écran juste à cause de pinpins infoutus de couper les lignes de leurs courriels» alors que ça devrait être au logiciel de faire ça et que tous les contenus devraient avoir une taille fluide (oui je m’adresse à toi, format PDF, chiant à lire sur téléphone) ou moi qui me plaint des éditeurs que j’utilise qui ne s’encombrent pas d’avoir des fonctions pour gérer le texte à taille fixe, oui j’ai qu’à changer de logiciels et pourquoi pas écrire mes commentaires Linuxfr en 65 colonnes tiens pourquoi pas.

                        Bon maintenant quand j’ai un avis sur quelque chose c’est rare que je change d’avis en me disant simplement que c’est «un usage éprouvé qui perdure chez des gens numériquement très compétents». J’ai ai rien à carrer de qui utilise quoi, si on arrive pas à me trouver une raison pour laquelle ça serait supérieur alors je continuerais à trouver ça stupide. J’ai exposé mes problèmes, ont m’a dit qu’ils étaient déjà réglé, mais on ne m’a vraiment dit pourquoi c’était mieux techniquement de couper les lignes à 65 caractères.

                        Bon en fait on dirait que Thunderbird édite de façon potable en mode texte contrairement à ce que j’ai cru en essayant mais c’était il y a un bail, et je viens de voir que même Thunderbird mets des trucs affreux dans les courriels en HTML. Le problème c’est que Thunderbird est capable d’éditer en HTML et envoyer en texte, mais faut préciser pour chaque courriel d’envoyer en format texte si on réponds à un courriel en HTML.

                        Écrit en Bépo selon l’orthographe de 1990

                        • [^] # Re: C'est quoi le problème ?

                          Posté par (page perso) . Évalué à 3.

                          D’autre part, dire que la limitation de 65 caractères est pertinente est une connerie, on code pas une information d’affichage dans le format

                          D’accord en théorie, mais après il faut se mettre à la place des rédacteurs du RFC 5322 (et des RFC qui l’ont précédé) : ils étaient plus ou moins obligé de tenir compte du fait qu’il existe des implémentations qui font n’importe quoi lorsqu’un message comportaient des lignes trop longues… D’où l’introduction de la recommandation, pour un émetteur, de ne pas dépasser 78 caractères par ligne :

                          Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.
                          […]
                          The more conservative 78 character recommendation is to accommodate the many implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line, in spite of the fact that such implementations are non-conformant to the intent of this specification.

                          (La limite à 65 caractères découle de cette limite à 78 caractères, pour se ménager suffisamment de niveaux de citations — mais cette limite-là n’a jamais été imposée par un quelconque standard, seulement par la Netiquette qui n’est que « pour information ».)

                          Ajoutons à celà qu’après cette recommandation de ne pas dépasser 78 caractères par ligne, il y a ensuite une obligation de ne pas dépasser 998 caractères (cette limite-là vient tout droit du protocole SMTP), et le « bidouillage » du format=flowed devient logique : il permet de séparer clairement les retours à la ligne qui ne sont là que pour respecter le protocole, de ceux qui sont là pour exprimer la volonté de l’auteur du message d’aller à la ligne.

                          Ce « bidouillage » a aussi l’avantage de permettre un affichage à peu près correct du message même avec un client qui ne prend pas en charge le format flowed, ce qui est déterminant et trop souvent oublié par ceux qui proposent une « solution » peut-être bien meilleure et plus propre techniquement mais condamnée à l’échec parce qu’elle nécessite un support de la part de tous les acteurs…

                          Le problème c’est que Thunderbird est capable d’éditer en HTML et envoyer en texte, mais faut préciser pour chaque courriel d’envoyer en format texte si on réponds à un courriel en HTML.

                          Euh, non. EditAccount settings, rubrique Composition & Addressing, décocher Compose messages in HTML format. Peu importe que le message auquel tu réponds soit en HTML, ta réponse sera en texte brut.

                          • [^] # Re: C'est quoi le problème ?

                            Posté par (page perso) . Évalué à 3.

                            Peu importe que le message auquel tu réponds soit en HTML, ta réponse sera en texte brut.

                            En revanche, par défaut Thunderbird ne compose pas en format flowed, et l’option pour le faire n’est, à ma connaissance, accessible que par le about:config, en mettant la clef mailnews.send_plaintext_flowed à true.

                            (Si tu veux critiquer l[e manque d’]ergonomie de Thunderbird, on peut sûrement tomber d’accord. ;) )

                            • [^] # Re: C'est quoi le problème ?

                              Posté par (page perso) . Évalué à 2.

                              Perso j’ai rien touché et la configuration est à true.

                              Je me demande ce qu’il en est de Kmail (ou même des autres clients courriels), j’envisage de repasser dessus puisque la prochaine version (qui va sortir ce mois-ci) sera basée sur KF5.

                              Écrit en Bépo selon l’orthographe de 1990

                          • [^] # Re: C'est quoi le problème ?

                            Posté par (page perso) . Évalué à 2.

                            Euh, non. Edit → Account settings, rubrique Composition & Addressing, décocher Compose messages in HTML format. Peu importe que le message auquel tu réponds soit en HTML, ta réponse sera en texte brut.

                            Euh si tu coches Thunderbird édites en texte. Je trouve plus pratique d’éditer le texte en HTML et qu’ensuite il soit convertit en texte (Thunderbird ça bien), surtout pour les citations et pour éviter de devoir me fatiguer avec le Ctrl+R tout le temps.

                            Soit tu édites en HTML et la réponse est potentiellement envoyée en HTML selon le destinataire (et peut-être le formatage utilisé dans le courriel?), soit on édites en texte et là on envoie toujours en texte. Bon c’est pas bien grave.

                            Écrit en Bépo selon l’orthographe de 1990

                        • [^] # Re: C'est quoi le problème ?

                          Posté par . Évalué à 2.

                          Pour la limite de 65 caractères, j'ai bien précisé « idéalement » et « pertinent » ne signifie pas « indépassable » juste « pas si débile que ça ».

                          Le seul problème que j'ai avec le format flowed est que, dans la mesure où c'est souvent l'éditeur qui fait automatiquement les retours à la ligne, ça peut casser assez facilement les mises en forme où l'alignement des lignes compte, par ex :

                          >    x="$(fmt -w80 foo | sed 's/[,.$]/+/')"
                                                            ^^^
                            Tu as mis le dollar dans les crochets.
                          
                          Voici mon idée d'arborescence :
                           |- root/
                                  |- a/
                                  |- b/
                                  |- c/
                                   ...
                          
                            1. Personne n'est obligé de suivre ce que je dis ;
                            2. Ça ne m'empêche pas de le dire haut et fort ;
                            3. De toutes façons vous ne voudrez pas reconnaître que j'ai raison.
                          

                          C'est à dire que ça décale le problème, car pas plus que les clients de courriels les éditeurs ne savent déterminer qu'un bloc de texte est un paragraphe. Mais bon, au moins en faisant gaffe ça offre une solution aux cas les plus courants (sauf dans le dernier, où en plus du problème de l'indentation chaque ligne consécutive devrait être traitée comme un paragraphe, ce qui est impossible à spécifier proprement).

            • [^] # Re: C'est quoi le problème ?

              Posté par (page perso) . Évalué à 4.

              Je parlais de taille de ligne.

              OK, dans ce cas la réponse est format=flowed.

              C’est un peu ironique de citer un document écrit en taille fixe. ;)

              Oui, le format canonique des RFC est le texte brut avec un format de page fixe. Libre à toi de railler l’IETF et ses vieux barbus restés à l’âge de pierre (tu ne seras pas le premier), mais en attendant, les RFC des années 1980 sont toujours lisibles aujourd’hui avec le plus rudimentaire des éditeurs de texte (même le bloc-notes de Windows peut les lire). On verra en 2050 si on peut en dire autant d’un document écrit aujourd’hui dans un format « riche ».

              Note quand même que le lien que j’ai posté est celui de la version HTML du RFC (voici la version texte), qui comme tu le vois n’empêche pas du tout l’auteur d’imposer la taille de ligne qu’il souhaite, contrairement à ce que tu penses.

              … ou pas? En pratique je reçois des courriels qui prennent la taille qu’ils veulent sur mon écran et c’est bien relou.

              Ou bien l’expéditeur n’utilise pas format=flowed, ou bien c’est ton client qui ne le prend pas en charge. Dans le deuxième cas, utilise un vrai client mail. Dans le premier, prend ton bâton de pèlerin et va dire à tes correspondants d’utiliser un vrai client mail (bon courage !).

              Je sais que c’est une question de gout, mais bon mettre des chevrons au début de chaque ligne de texte citée je trouve ça un peu horrible au 21e siècle.

              Mon client reconnaît automatiquement les citations (précisément grâce aux chevrons en début de ligne) et les affiche en retrait avec une petite barre bleue sur le côté. Magie du texte brut : c’est chez moi que les décisions de mise en forme sont prises, pas chez l’expéditeur qui peut écrire en pensant uniquement au fond et pas à la forme (les chevrons ne sont pas de la mise en forme, c’est du balisage sémantique pour dire « cette ligne est une citation, affiche-là comme tu veux »).

              • [^] # Re: C'est quoi le problème ?

                Posté par (page perso) . Évalué à 0.

                C’est un peu ironique de citer un document écrit en taille fixe. ;)

                Oui, le format canonique des RFC est le texte brut avec un format de page fixe. Libre à toi de railler l’IETF et ses vieux barbus restés à l’âge de pierre (tu ne seras pas le premier), mais en attendant, les RFC des années 1980 sont toujours lisibles aujourd’hui avec le plus rudimentaire des éditeurs de texte (même le bloc-notes de Windows peut les lire). On verra en 2050 si on peut en dire autant d’un document écrit aujourd’hui dans un format « riche ».

                Nan mais le format des RFC est même pas fait pour être lu sur un ordinateur moderne. À la limite je préfèrerais une version texte, mais sans entête et pied de page, et sans ligne à taille fixe pour que mon éditeur de texte puisse afficher du texte sur toute la largeur que je veux.

                D’ailleurs j’aimerais bien savoir pourquoi il y a des entêtes et des pieds de page dans un document texte brut destiné à être consulter sur un ordinateur. À moins que ça soit pour avoir une version unique à consulter sur ordinateur/imprimer, mais dans ce cas, est-ce que c’est bien adapté à tous les formats de papier?

                Note quand même que le lien que j’ai posté est celui de la version HTML du RFC (voici la version texte), qui comme tu le vois n’empêche pas du tout l’auteur d’imposer la taille de ligne qu’il souhaite, contrairement à ce que tu penses.

                Si on m’envoyait des courriels en texte brut sans colonne à taille fixe et que mon courrielleur était capable de couper automatiquement les lignes, ça me plairait bien. Malheureusement je crois que ça n’est pas le cas, parce que 1) personne n’envoie des courriels au format texte sans couper les lignes à taille fixe, 2) je crois que Thunderbird ne coupe pas les lignes automatiquement lors de l’affichage d’un courriel au format, obligeant à faire défiler horizontalement (pitié, plutôt la mort).

                Je sais que c’est une question de gout, mais bon mettre des chevrons au début de chaque ligne de texte citée je trouve ça un peu horrible au 21e siècle.

                Mon client reconnaît automatiquement les citations (précisément grâce aux chevrons en début de ligne) et les affiche en retrait avec une petite barre bleue sur le côté.

                Oui moi aussi, mais si je dois couper le texte en plusieurs bouts pour citer des parties c’est pas pratique. La théorie (oui mon truc à ligne fixe est géré par mon courrielleur) vs la réalité.

                Magie du texte brut : c’est chez moi que les décisions de mise en forme sont prises, pas chez l’expéditeur qui peut écrire en pensant uniquement au fond et pas à la forme (les chevrons ne sont pas de la mise en forme, c’est du balisage sémantique pour dire « cette ligne est une citation, affiche-là comme tu veux »).

                En fait je dis que le HTML c’est pratique (en plus c’est censé être sémantique), vous vous plaignez du CSS (la forme). Le problème est qu’on autorise trop de trucs, pas le HTML en lui-même…


                Je ne dis pas que le texte brut c’est mal (les deux ont des défauts), juste que dans l’état actuel des choses je préfère le HTML au texte brut (en particulier à colonne fixe) alors pas la peine de me dire que j’ai tort. À croire que le texte brut est une religion…

                Écrit en Bépo selon l’orthographe de 1990

                • [^] # Re: C'est quoi le problème ?

                  Posté par (page perso) . Évalué à 5.

                  Si on m’envoyait des courriels en texte brut sans colonne à taille fixe et que mon courrielleur était capable de couper automatiquement les lignes, ça me plairait bien.

                  Je vais me répéter une dernière fois : format=flowed. C’est précisément à ça que ça sert.

                  Le format texte brut « de base » n’impose aucun format, sauf la longueur des lignes. Donc on a inventé le format flowed pour supprimer l’inconvénient des lignes de longueur fixe, tout en gardant les autres avantages du format texte.

                  1) personne n’envoie des courriels au format texte sans couper les lignes à taille fixe

                  Non, mais certains (moi par exemple) les envoie au format texte flowed, qui autorise ton client à recouper les lignes comme bon lui semble.

                  2) je crois que Thunderbird ne coupe pas les lignes automatiquement lors de l’affichage d’un courriel au format [brut]

                  Il le fait s’il est autorisé à le faire, c’est-à-dire si le format n’est pas seulement text/plain, mais text/plain; format=flowed. Si l’expéditeur n’a pas formatté son mail en format=flowed, Thunderbird n’y est pour rien.

                  Oui moi aussi, mais si je dois couper le texte en plusieurs bouts pour citer des parties c’est pas pratique.

                  Edit > Rewrap, ou Ctrl-R. De rien.

                  La théorie (oui mon truc à ligne fixe est géré par mon courrielleur) vs la réalité.

                  Évidemment, ce que moi je raconte c’est la théorie, alors que toi c’est la réalité.

                  le HTML c’est pratique (en plus c’est censé être sémantique)

                  Tout est dans le « censé ». Tu as déjà jeté un œil au code d’un mail HTML ? La plupart du temps il n’y a pas l’ombre de sémantique, c’est de l’HTML sorti tout droit de l’époque de HTML 3.2, rempli de <I>, <B>, <FONT>, et des mises en page réalisées à grand coups de <TABLE>… et encore, quand le message principal n’est pas dans des images embarquées !

                  C’est la théorie du HTML sémantique vs la réalité du HTML entièrement consacré à la forme.

                  Le problème est qu’on autorise trop de trucs, pas le HTML en lui-même…

                  Ah, ce n’est pas de la faute de l’HTML lui-même, mais de ceux qui s’en servent ? Donc tu seras d’accord que le problème du texte brut n’est pas le format lui-même, mais de ceux qui ne se servent pas de la disposition format=flowed ?

                  juste que dans l’état actuel des choses je préfère le HTML au texte brut (en particulier à colonne fixe) alors pas la peine de me dire que j’ai tort. À croire que le texte brut est une religion…

                  Pas la peine de faire l’offensé en déformant mes propos, nulle part je n’ai dit que tu avais tort de préférer HTML, je n’ai même pas critiqué HTML en lui-même. Je n’aime pas qu’on se serve pour m’imposer la manière d’afficher un mail dans mon client de messagerie, c’est tout.

                  En revanche, toi tu ne trouves rien de mieux pour défendre HTML que d’attaquer le texte brut, en lui inventant un défaut qui a été corrigé il y a seize ans ou en ignorant toutes les fonctions intégrées de longue date à n’importe quel client mail digne de ce nom. Tu peux comparer les utilisateurs du texte brut à des croisés (pendant que tu y es, dis carrément « adorateurs », ne te retiens pas), mais tu es pas mal dans le genre.

                  • [^] # Re: C'est quoi le problème ?

                    Posté par (page perso) . Évalué à -1.

                    Edit > Rewrap, ou Ctrl-R. De rien.

                    En 2015, être obligé·e d’utiliser un raccourci clavier à cause du format utilisé. L’humain qui s’adapte à la machine…

                    Évidemment, ce que moi je raconte c’est la théorie, alors que toi c’est la réalité.

                    Je dis juste que mon expérience ne peut pas être balayée juste que parce qu’une RFC existe.

                    Sinon, voir le dernier paragraphe de mon autre commentaire.

                    Ah, ce n’est pas de la faute de l’HTML lui-même, mais de ceux qui s’en servent ? Donc tu seras d’accord que le problème du texte brut n’est pas le format lui-même, mais de ceux qui ne se servent pas de la disposition format=flowed ?

                    Selon moi le problème est le format en lui-même et le bidouillage avec format=flowed… Mais c’est vrai que dans la pratique ça marche pas si mal.

                    En revanche, toi tu ne trouves rien de mieux pour défendre HTML que d’attaquer le texte brut, en lui inventant un défaut qui a été corrigé il y a seize ans ou en ignorant toutes les fonctions intégrées de longue date à n’importe quel client mail digne de ce nom.

                    Tu peux comparer les utilisateurs du texte brut à des croisés (pendant que tu y es, dis carrément « adorateurs », ne te retiens pas), mais tu es pas mal dans le genre.

                    Ouais j’aime carrément pas le ton de certains commentaires, qui est un peu trop souvent le standard sur Linuxfr. Je suis pas la dernière à y participer mais je sais pas, j’essaie d’éviter (même si sur le coup j’aurais revérifier des trucs que j’avais testé/vu il y a longtemps).

                    Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: C'est quoi le problème ?

      Posté par . Évalué à 10.

      J'ai volontairement écrit ça de façon péremptoire dans le sondage.

      Il y a des tas d'argumentaires contre, mais ça peut faire débat, et ce qui était vrai il y a 10 ans ne l'est peut-être plus maintenant. C'est pourquoi j'ai voulu savoir où "on" en était chez les (plus ou moins) barbus.

      Ce qui me vient à l'esprit.

      1/ Pas fiable : hormis des formatages simples, on ne sait pas comment ça va s'afficher

      2/ Difficile à faire suivre sans tout casser

      3/ Porte ouvert à l'agression publicitaire et au mauvais goût

      4/ Poids des messages : beaucoup plus lourd pour un message de trois mots, c'est ridicule.

      5/ Sécurité : possibilité d'embarquer des contenus extérieurs

      6/ Illisible par les gens dont le logiciel ne le prends pas en charge

      Mais on peut répondre :

      1/ Si on se limite aux formatages simples, c'est pas si mal : gras, souligné, etc. (Et certains parsers HTML -> plain text remplacent le gras par un encadrement par des *, etc, ou alors c'est le logiciel émetteur qui le fait dans la version plain text.

      2/ Idem, avec du formatage simple, ça doit marcher, et avec un message complexe, c'est la merde

      3/ Ici aussi, on critique le mésusage, pas la technique

      4/ Juste, mais quand on commence à envoyer des photos de 4 Mo, ça devient négligeable

      5/ Les logiciels savent en général désactiver ces contenus

      6/ Il faut vivre avec son temps

      Reste qu'avec du texte brut on peut déjà faire des choses claires, donc il faut peser le rapport gain/emmerdement à introduire un truc mal normé qui est sympa parfois, chiant d'autres fois.

      Ma (triste) vie :

      Au boulot, je force MS Outlook en texte brut (et ça a pas été simple !), sinon c'est la honte pour écrire sur une liste sérieuse, dans un environnement où tout le monde est en HTML, et je n'insère pas la signature HTML qui est fournie par la comm'.

      Les limites :

      • J'écris en texte simple mais la police d'affichage par défaut n'est pas monospace, donc c'est nul, notamment pour souligner les titres

      • Je dois cliquer sur "afficher en HTML" pour lire les tableaux embarqués ou même voir les images qui sont embarquées et n'apparaissent pas comme PJ

      • Les interlocuteurs, les rares fois où ils répondent dans le corps de texte, utilisent les couleurs pour séparer leurs contributions, car le préfixage avec > ne se fait pas par défaut.

      Bref, merci MS, merci Outlook. Encore, en interne, je pourrais me plier au HTML, mais pour dialoguer avec l'extérieur, ça m'embête.

  • # Texte brut...

    Posté par . Évalué à 10.

    … Et 72 colonnes, SVP !

    • [^] # Re: Texte brut...

      Posté par (page perso) . Évalué à 6.

      emacs gère très bien cela (un jour ce serait bien qu'il ait un éditeur de texte digne de ce nom tout de même…).

      • [^] # Re: Texte brut...

        Posté par . Évalué à 4.

        je crois que systemd en a un suffisament bon, comme il devrait bientôt remplacer emacs ça tombe bien

      • [^] # Re: Texte brut...

        Posté par . Évalué à 3.

        claws-mail a un éditeur de texte assez bon qui gère le wrapping.

        Le seul truc un peu pénible, c'est qu'il ne le fait que lorsqu'une ligné dépasse. Si on modifie un paragraphe pour ajouter un mot au milieu, il refait les lignes de tout le paragraphe. Si c'est pour enlever un mot, il faut ruser et le forcer à avoir une ligne trop longue (typiquement en supprimant un retour chariot) pour qu'il refasse le boulot.

        Il permet aussi d'indenter un peu : si le paragraphe commence par le symbole - ou *, il aligne la ligne d'en dessous et tout le paragraphe après le symbole

    • [^] # Re: Top posting

      Posté par (page perso) . Évalué à 8.

      … Et pas de top posting, SVP !

      « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

      • [^] # Re: Top posting

        Posté par (page perso) . Évalué à 6.

        top posting

        Le terme officiel français (validé par le comité fufa) est goretquotage.

        * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

  • # Contenu distant

    Posté par (page perso) . Évalué à 10.

    Perso, ce n'est pas trop les messages HTML qui me dérangent, mais plus lorsqu'ils incluent du contenu distant et qu'il est "impossible" de les lire sans activer ce contenu distant…

    S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

  • # Quotes

    Posté par . Évalué à 5.

    Moi, ce qui me gène le plus, c'est les signatures de 30 km de long, et les gens qui citent tout le message à chaque réponse (y compris cette grosse signature).

    Pour le HTML, ça serait intéressant si on se limitait au HTML simple, sans mise en forme. En gros, pouvoir avoir un minimum de mise en forme quand c'est utile (titres, emphase, liens) mais sans piquer les yeux. À la rigueur, une feuille de style côté client pour qu'on puisse choisir si on veut une mise en forme sobre ou avec plein de couleurs pour ceux qui aiment.

    • [^] # Re: Quotes

      Posté par . Évalué à 3.

      A oui, les 30 Kms de signature avec les fameuses images animées, ou pas.
      Je me fais à chaque fois plaisir en supprimant tout cela à chaque fois que je réponds à un mail qui ressemble plus à un roman.

    • [^] # Re: Quotes

      Posté par . Évalué à 6.

      Mon banquier fait cela, c'est horrible ! Il y a plein de bandeaux publicitaires, et des mentions légales attachés à sa signature, et à la fin, ce gentil petit mot qui décrédibilise tout :

      Les communications sur Internet n'etant pas securisees, l’'expediteur informe qu'il ne peut accepter aucune responsabilite quant au contenu de ce message.

      Et il n'y a pas d'accent non plus ^

    • [^] # Re: Quotes

      Posté par (page perso) . Évalué à 8.

      Moi, ce qui me gène le plus, c'est les signatures de 30 km de long

      Sans oublier le combo « signature de 30 km de long, en HTML ».

      Le modèle de signature recommandé par mon labo (et fourni par le service IT, qui n’a apparemment jamais entendu parler de la Netiquette — notamment le passage recommandant des signatures de quatre lignes maximum) fait 121 lignes de code HTML (incluant liens vers des images externes, propre feuille de style CSS, et commentaires que personne n’a jamais pris la peine de nettoyer)…

      Résultat, la seule signature est beaucoup plus longue (à la fois en termes de lignes de code HTML, et en termes d’espace pris sur l’écran après rendu) que le contenu d’un message moyen typique…

    • [^] # Re: Quotes

      Posté par (page perso) . Évalué à 10.

      Moi, ce qui me gène le plus, c'est les signatures de 30 km de long, et les gens qui citent tout le message à chaque réponse (y compris cette grosse signature).

      Avec la petite ligne écolo qui te sermonne de bien réfléchir avant d’imprimer cet e-mail, et qui se retrouvera immanquablement seule sur une deuxième page de papier si la folie te prenait de vraiment imprimer cet e-mail sans le nettoyer de ces idioties.

      • [^] # Re: Quotes

        Posté par . Évalué à 3.

        ça me rappel la fois ou j'ai détourné ce genre de signature pour dire de bien réfléchir avant d'envoyer un mail en HTML ; parce que bon, si on veut vraiment être écolo on n’envoie pas de mail en HTML.

        au final, personne ne m'a fait de remarque, personne n'a rien vu et ça n'a rien changé…

        • [^] # Re: Quotes

          Posté par (page perso) . Évalué à 2.

          parce que bon, si on veut vraiment être écolo on n’envoie pas de mail en HTML

          on utilise des pigeons. S'échanger des pps c'est pas très drôle pour la planète :<

          « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

  • # Laisser le navigateur web interpréter le HTML

    Posté par (page perso) . Évalué à 2.

    Je préfère les courriels en texte brut.
    Avec mon client de messagerie (Sylpheed), je lis mes e-mails en texte brut.
    Lorsqu'il y a du contenu HTML, il est considéré comme un contenu en pièce jointe.
    Du coup, je peux l'ouvrir avec mon navigateur web (Firefox).
    Laissons le navigateur web gérer l'interprétation de l'HTML.

    • [^] # Re: Laisser le navigateur web interpréter le HTML

      Posté par (page perso) . Évalué à 7.

      Certes, un truc quand même: le moteur de rendu html des clients "compatibles" (thunderbird, outlook, ..) est volontairement restreint et limité (pas de javascript souvent, pas de css complexe, …) et peut protèger par défaut l'inclusion de contenu tiers, ce que ton navigateur ne fera pas lui.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.