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
# Format riche
Posté par Le Gab . É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 BAud (site web personnel) . É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 Le Gab . É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 bobble bubble . Évalué à 1.
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 :
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 ymorin . Évalué à 5.
Bon, le HTML avec mutt, au moins, je peux dire à mes correspondants:
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 Watchwolf . É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 Nolent . É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 Stéphane Klein (site web personnel) . Évalué à 8.
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 ariasuni . Évalué à -2.
Le texte brut c’est assez horrible dans son propre style aussi. Genre:
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:
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 Ignatz Ledebur . É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 ariasuni . Évalué à 1.
Si le fait que quelque chose soit beaucoup utilisé indiquait que cette chose était bonne, ça ce saurait.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: C'est quoi le problème ?
Posté par ariasuni . Évalué à 2. Dernière modification le 01 août 2015 à 10:03.
doublon supprimé
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: C'est quoi le problème ?
Posté par gouttegd . Évalué à 6.
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.
format=flowed, spécifié depuis au moins seize ans. Enough said.
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 ariasuni . Évalué à 2.
Je parlais de taille de ligne.
C’est un peu ironique de citer un document écrit en taille fixe. ;)
… ou pas? En pratique je reçois des courriels qui prennent la taille qu’ils veulent sur mon écran et c’est bien relou.
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 Ignatz Ledebur . É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 ariasuni . Évalué à 2.
C’est pas pour le poids de la version texte…
Et donc ça ne devrait jamais changer? On devrait se compliquer la vie pour une limitation technique des années 80?
J’utilise mon client comme il faut, tout le monde peut lire mes courriels.
blablabla.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: C'est quoi le problème ?
Posté par Ignatz Ledebur . Évalué à 3.
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.
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 ?
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 xcomcmdr . Évalué à 2. Dernière modification le 02 août 2015 à 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 Ignatz Ledebur . Évalué à 4. Dernière modification le 02 août 2015 à 16:11.
On pourrait aussi imaginer que :
[^] # Re: C'est quoi le problème ?
Posté par ariasuni . É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 gouttegd . Évalué à 3.
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 :
(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…
Euh, non.
Edit→Account settings, rubriqueComposition & Addressing, décocherCompose 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 gouttegd . Évalué à 3.
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 clefmailnews.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 ariasuni . É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 ariasuni . Évalué à 2.
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 Ignatz Ledebur . É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 :
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 gouttegd . Évalué à 4.
OK, dans ce cas la réponse est format=flowed.
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 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 !).
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 ariasuni . Évalué à 0.
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?
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).
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é.
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 gouttegd . Évalué à 5.
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
flowedpour supprimer l’inconvénient des lignes de longueur fixe, tout en gardant les autres avantages du format texte.Non, mais certains (moi par exemple) les envoie au format texte
flowed, qui autorise ton client à recouper les lignes comme bon lui semble.Il le fait s’il est autorisé à le faire, c’est-à-dire si le format n’est pas seulement
text/plain, maistext/plain; format=flowed. Si l’expéditeur n’a pas formatté son mail en format=flowed, Thunderbird n’y est pour rien.Edit > Rewrap, ouCtrl-R. De rien.Évidemment, ce que moi je raconte c’est la théorie, alors que toi c’est la réalité.
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.
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?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 ariasuni . Évalué à -1.
En 2015, être obligé·e d’utiliser un raccourci clavier à cause du format utilisé. L’humain qui s’adapte à la machine…
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.
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.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 jihele . É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 Tonton Benoit . Évalué à 10.
… Et 72 colonnes, SVP !
[^] # Re: Texte brut...
Posté par BAud (site web personnel) . É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 DerekSagan . É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 jihele . É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 Sébastien Wilmet . Évalué à 8.
… Et pas de top posting, SVP !
[^] # Re: Top posting
Posté par Tonton Th (Mastodon) . Évalué à 6.
Le terme officiel français (validé par le comité fufa) est goretquotage.
# Contenu distant
Posté par Olivier Esver (site web personnel) . É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 kna . É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 stephane74 . É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 Nairwolf . É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 :
Et il n'y a pas d'accent non plus ^
[^] # Re: Quotes
Posté par gouttegd . Évalué à 8.
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 jyes . Évalué à 10.
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 gde . É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 deuzene (site web personnel) . Évalué à 2.
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 YuGiOhJCJ (site web personnel) . É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 -=[ silmaril ]=- (site web personnel) . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.