La version décideur pressé : Drew DeVault suggère qu'on arrête d'envoyer des emails en HTML, j'ai essayé mais j'ai eu des problèmes.
La version plus longue : si vous me lisez souvent, vous savez peut-être que, comme Ploum ici et sans doute pas que lui, je m'intéresse de plus en plus à la frugalité numérique et aux solutions low-tech proposées à certains problèmes familiers. Comme par exemple les emails, cette saloperie qui tord mes boyaux et aspire l'air de mes poumons chaque fois que je dois en envoyer un, ou en chercher un dans mes dossiers mal synchronisés. C'est d'ailleurs Ploum qui m'a appris via son blog les vertus de l'inbox zero, et je suis assez content d'être devenu ce mec qui clique sur "Archiver" plus vite que son ombre mais je digresse.
La page https://useplaintext.email/ est titrée "Faites des emails en texte brut !" Elle dit en substance que les emails en HTML sont une erreur (c'est aussi l'avis d'un de ses inventeurs). Les arguments en ce sens sont connus : les liens dans les emails sont presque toujours du spam, les images se chargent jamais correctement (et bouffent des données précieuses selon votre forfait mobile), le code HTML peut contenir des traqueurs, et de toute façon c'est jamais affiché pareil d'un appareil à l'autre. C'est pourquoi cette page web recense pour chaque client email comment désactiver l'envoi en HTML afin de ne pas participer à cette gabegie. Pour le coup je suis assez d'accord avec l'idée, et je me dis que si cet usage était plus répandu, les emails pourraient devenir un peu plus élégants. La page est à l'initiative de Drew DeVault, un hacker qui n'a pas toujours raison sur tout loin de là, mais qui revendique une approche minimaliste avec parfois des résultats fascinants (il fait beaucoup la pub de Gemini par exemple et je trouve ça cool).
Donc j'ai suivi ses conseils, j'ai paramétré Thunderbird, FairEmail et Geary pour non seulement écrire en texte brut, mais aussi désactiver le "top posting" (car après tout Drew n'a pas tort, on lit bien de haut en bas ?) et activer le "format flowed" (sans trop savoir ce que c'était).
Et je trouve le résultat mitigé :
- Le texte brut c'est chouette d'un point de vue typographique, ça uniformise tout
- Par contre y'a des sauts de ligne bizarres selon les correspondances (cf. image). J'imagine que c'est un truc lié au "format flowed" ? Pourtant mes trois clients sont supposés le supporter.
- Et surtout, le bottom-posting est ingérable si le correspondant ne l'a pas lui-même désactivé : ses réponses se retrouvent en haut et les miennes en bas ! Useplaintext.email recommande de "supprimer les réponses" du corps du message, mais évidemment ça ne les empêche pas de réapparaître si le correspondant a un client qui les rajoute tout seul, au hasard Gmail.
En conclusion, l'expérience me laisse songeur. D'un côté, j'aime beaucoup l'idée de s'astreindre à un certain minimaliste en matière d'emails, qui à mon sens ne devraient pas causer beaucoup plus de friction qu'un SMS ou un message instantané (oui devnewton, comme dans deltachat, je sais). D'un autre côté, ce choix met le bazar dans les échanges avec les autres, et la page de Drew DeVault ne semble pas s'en inquiéter. C'est finalement un problème qu'on rencontre souvent dans le librisme : on veut éviter tel OS, telle appli, tel protocole, tel format de fichier, telle plateforme, mais ces choix impactent d'autres que nous, et il faut parfois les compromettre.
# mu4e ftw
Posté par openbar . Évalué à 10.
Je pense que si on veut être pragmatique, il faut accepter que le top posting c'est ce qui s'est imposé de fait. A part dans certaines niches d'échanges techniques, à peu prés tout le monde l'utilise…
Si on accepte ça, il n'y a pas de problème à utiliser les emails en plaintext; par exemple j'utilise mu4e et lit les emails en plaintext (dans emacs, avec la possibilité de les ouvrir dans le navigateur), et j'ai jamais eu de retour de gens s'en plaignant, et j'arrive toujours à bien retrouver les informations que je cherche rapidement.
[^] # Re: mu4e ftw
Posté par Glandos . Évalué à 10.
Le top posting est un enfer. Surtout en entreprise, quand on te transfère un message avec :
Ça, répété en boucle et parfois y a des gens qui ont répondu au milieu en mettant en rouge leur réponse.
Résultat, la molette de ma souris souffre très beaucoup fort pour 10 lignes de texte utile.
En fait, plus j'y pense, plus le fait de pouvoir modifier le message original est un souci. Ce qui se fait dans les logiciels de forum est beaucoup plus utilisable : une page vierge, et on récupère ce qu'on veut citer si on le souhaite.
Mais bon, c'est arrivé bien plus tard.
[^] # Re: mu4e ftw
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 4.
Tout à fait, mais il me semble aussi que jusqu'à une période récente, les clients email n'affichaient généralement (uniquement ?) qu'un message à la fois, plutôt que plusieurs messages de la discussion comme le font les forums ? Je crois même que c'était un des gros arguments de Gmail, pouvoir facilement relire une discussion sans devoir cliquer et cliquer dans une longue liste de "Re: Re: Re:" pour ouvrir chaque message l'un après l'autre (et d'ailleurs, c'est encore un truc que je dois faire dans l'Outlook de mon taf pour m'y retrouver entre les réponses massacrées par les clients chinois et les pièces jointes on ne sait où).
[^] # Re: mu4e ftw
Posté par openbar . Évalué à 8.
Ça c'est pas vraiment un problème du top posting, c'est surtout un problème de gens qui cliquent simplement sur répondre et nettoient pas les citations.
Si la norme était le bottom posting, et que tous les clients mails implémentaient un comportement d'ouvrir l'email en bas, et que le répondre soit automatiquement en bottom posting, les gens ne nettoieraient pas plus leurs emails et on se retrouverait avec le même problème, sauf qu'il faudrait que tu fasse chauffer ta molette vers le haut…
[^] # Re: mu4e ftw
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Il faut arrêter d'accuser les clients mails et cesser de demander/encourager des trucs qui veulent même répondre à notre place. Moi j'aime bien que mon curseur se positionne au début car je vais souvent écrire quelque chose avent la citation. Et en passant, l'hérésie est de ne pas citer précisément mais d'embarquer tout le message auquel on répond. D'ailleurs, puisque vous défendez la chose, pourquoi ne citez vous pas systématiquement la totalité des messages auxquels vous répondez ici ? J'ai parfois l'impression que parce-que c'est du courriel on doit perdre toute rationalité et faire n'importe quoi…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: mu4e ftw
Posté par Glandos . Évalué à 5.
IBM Notes (ex Lotus Notes). Il est impossible de répondre en dessous du message, on ne peut que écrire au dessus. On ne peut même pas casser une citation en deux pour répondre dedans, on ne fait que rajouter du texte dans la citation.
Oui, on pourrait argumenter que Notes n'est pas un client email, mais une messagerie avec une passerelle vers l'email…
[^] # Re: mu4e ftw
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
+1 Je l'avais oubliée cette infâme bouse.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: mu4e ftw
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Et l'incapacité pendant longtemps à préserver les fils de discussion dans certains clients, remplacée par on met tout l'historique dans chaque message, comme ça pas de souci de rangement des infos.
[^] # Re: mu4e ftw
Posté par Dring . Évalué à 2.
Heureusement Notes est en grosse perte de vitesse. Même IBM ne l’utilise presque plus.
[^] # Re: mu4e ftw
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 3.
Le problème de Lotus Notes, c'est que je ne l'ai jamais vu vraiment bien configuré, et que c'était une usine à gaz pas complètement finie. Ça aurait pu être un outil génial. Dommage.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: mu4e ftw
Posté par eingousef . Évalué à 10.
Vivement que Linuxfr passe au top-posting alors !
*splash!*
[^] # Re: mu4e ftw
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 5.
Je pense que si on veut être pragmatique, il faut accepter que le top posting c'est ce qui s'est imposé de fait. A part dans certaines niches d'échanges techniques, à peu prés tout le monde l'utilise…
Sauf au siècle dernier, au bon vieux temps de Usenet.
[^] # Re: mu4e ftw
Posté par Glandos . Évalué à 5.
C'est vrai. En général d'ailleurs, je m'adapte. Sur debian-devel, je fais du bottom posting. Quand un message est déjà écrit en top posting depuis 5 échanges, je vais pas tout casser juste pour imposer ma vision.
Les clients « modernes » ont tendance à rendre cette différence un peu obsolète d'ailleurs. Outlook Web masque comme il faut les messages précédents, et Thunderbird Conversations permet de faire une navigation en conversation assez pratique.
# Il se prend pour la voix de la sagesse
Posté par David Demelier (site web personnel) . Évalué à 6.
Il faut arrêter de suivre ce type qui s'auto proclame la voix de la sagesse en plus d'être une vraie drama queen.
La plupart de ses articles sont de simples projections de ses opinions personnelles en tant que conseils sur nos manière de développer. Et quand nous faisons pas comme il souhaite, il se barre. Par exemple, chez Alpine Linux il a décidé que si on arrêtait les patchs par email (car on utilisait son système de mailing list) il arrêterait de contribuer. Il réinvente des outils parce qu'il n'a pas envie d'utiliser l'existant et en plus il les propage comme une véritable peste.
Bref, je pense que c'est une personne qui a besoin de beaucoup d'attention et le fait savoir. Ne prenez pas ses articles comme un évangile.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Il se prend pour la voix de la sagesse
Posté par ElVirolo (site web personnel) . Évalué à 10.
Je ne vois pas ce qu'il y a de « drama queen » dans le lien que tu cites. Par ailleurs, c'est une « insulte » qui me paraît plus que problématique.
Drew a certes souvent des opinions arrêtées, et il n'a pas toujours été des plus diplomates (et, pour en avoir parlé avec lui, il en est conscient et a fait beaucoup d'efforts - insuffisants peut-être).
C'est lui qui les « propage » ou ses utilisateurs qui décident de les adopter ?
Vu le nombre de commentaires acrimonieux, voire violents, à son égard que tu postes ici, il semble que que tu aies un dent particulière (personnelle, peut-être) contre lui, ce que je peux tout à fait comprendre. J'ai moi-même parfois eu du mal dans mes échanges avec lui.
Ce que je ne comprends pas, en revanche, c'est la propension de ses détracteurs à recourir à des méthodes similaires à celles qu'ils dénoncent chez lui. On ne pourrait pas juste discuter ses propositions froidement et rationnellement, sans agressivité, généralisations et attaques ad hominem ? Je peux comprendre que ses manières soient parfois problématiques, mais je ne vois pas l'intérêt de toujours ramener le fond à la forme (ce qui, ironiquement, est justement ce que cherche une « personne qui a besoin de beaucoup d'attention et le fait savoir »).
Ce n'est pas parce que c'est une personne qui a tous les défauts du monde qu'elle a nécessairement tort. Les deux choses sont tout à fait distinctes. Si à chaque fois qu'un de ses propos ou opinions est relayé, on a le droit à « de toute façon, c'est un sale type », on est bien avancés…
[^] # Re: Il se prend pour la voix de la sagesse
Posté par David Demelier (site web personnel) . Évalué à 4. Dernière modification le 27 août 2022 à 08:43.
Ce n'est pas le problème, c'est de prendre sa notoriété pour acquis et essayer de forcer les gens à son opinion. Essayez d'envoyer un mail HTML à son système de mailing list et vous serrez renvoyé chez vous avec un message du genre « les messages HTML sont mauvais, blablabla, voir cesiteenquestion ».
Pour ma part, je suis d'accord que les mails HTML sont mauvais et je suis le premier à râler quand je vois les signatures HTML de 3Mo.
Mais pour autant, je vais pas forcer les gens à ne pas l'utiliser tout en me faisant passer pour le messager de la sagesse parce que « j'ai raison ».
Les opinions sont propres à chacun, forcer les gens à les suivre ça devient problématique.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Il se prend pour la voix de la sagesse
Posté par ElVirolo (site web personnel) . Évalué à 9.
D'après mon expérience, les courriels en HTML sont simplement rejetés par lists.sr.st. C'est son service, il en fait ce qu'il en veut, personne n'est « forcé » de ne pas utiliser d'HTML.
C'est un choix parmi d'autres. J'ai choisi d'utiliser Sourcehut entre autres pour cette raison. Il ne me viendrait pas à l'idée de lui reprocher de m'imposer de ne pas pouvoir utiliser de Javascript sur pages.sr.ht, par exemple. It's a feature, not a bug. Et libre à moi d'utiliser n'importe lequel des multiples autres services similaires.
Drew peut certes être grinçant, mais c'est un autre problème.
[^] # Re: Il se prend pour la voix de la sagesse
Posté par ElVirolo (site web personnel) . Évalué à 5.
Je viens de voir, par hasard, ce commentaire que Drew a laissé sur le Gitlab de PostmarketOS:
I don't think that HTML email is a great idea and I'm generally opposed to allowing it. However, I think it might make sense to allow it on some mailing lists (e.g. -discuss or -users) but not on others (e.g. -dev). Somewhat open to suggestions/patches on this theme.
[^] # Re: Il se prend pour la voix de la sagesse
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Dans ma messagerie perso, je ne lis pas de mail HTML ; ça ne veut pas dire que je force les gens à ne pas l'utiliser : les gens restent libres de faire comme bon leur semble y compris de ne pas correspondre avec moi.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Presque rien à voir, mais:
Posté par David Delassus (site web personnel) . Évalué à 7.
A chaque fois que je vois un sujet sur les mails, je repense à Google Inbox.
Ce joli produit à l'interface simple, et puissante, qui était le seul client mail ou je ne laissais pas ma boite mail devenir un tas de merde non trié, impossible à exploiter.
Un des rares produits google à avoir une bonne UX, alors que d'habitude c'est un désastre (coucou GCP, GMail, etc…).
Nostalgique de l'époque avant que Inbox ne rejoigne le cimetière google, je fais une petite recherche et tombe sur Shortwave !
Haaaa, en 5min ma boite mail est de nouveau exploitable.
Merci pour ton journal que je n'ai pas lu. J'ai pu retrouver une belle techno.
https://link-society.com - https://kubirds.com
[^] # Re: Presque rien à voir, mais:
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 3.
J'étais très fan de Google Inbox également, à l'époque où je n'utilisais que Google pour mes emails. Maintenant Gmail fonctionne plus ou moins de la même manière (avec les pubs en plus), mais ayant délaissé ma boîte Google pour tout ce qui n'est pas du spam, je me retrouve à envoyer des tickets suppliants sur les bugtrackers de clients Android pour réclamer des fonctionnalités similaires. J'espère que Thunderbird l'implémentera bientôt !
[^] # Re: Presque rien à voir, mais:
Posté par Glandos . Évalué à 4.
Shortwave a l'air bien, mais… pourquoi ne supporter que GMail ? C'est bizarre comme modèle commercial pour une boîte, de s'appuyer uniquement sur un seul fournisseur de données. J'ai vu plein de boîtes faire des clients Twitter, et… ça s'est pas bien fini pour eux.
[^] # Re: Presque rien à voir, mais:
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 26 août 2022 à 15:50.
Ou alors, Google pourrait tout simplement les racheter et les faire bosser sur Gmail, comme ils l'ont fait avec les devs de Sparrow (qui cependant fonctionnait avec n'importe quelle boîte IMAP)
# vraiment?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Je dirais qu'on se rend pas compte à quel point on utilise souvent des liens dans des emails. Moi c'est tout le temps (aussi bien en envoi qu'en réception) et ça m'embêterait bien de pas pouvoir faire autrement.
Je pense pas que le problème soit technique, pouvoir envoyer des mails au format HTML, c'est super, et ça peut s'afficher beaucoup mieux que le format texte préhistorique avec ses retours à la ligne tout moisis (tu as toi-même constaté ce problème malgré la tentative d'activer une option pour contourner le souci).
On peut faire du HTML léger avec juste quelques tags là ou c'est utile.
ça me rappelle les débats sur UTF-8 qui faisait perdre quelques octets par rapport aux encodages historiques. Certes, mais ça ouvre tellement de possibilités et simplifie tellement de choses.
Faire de la frugalité en HTML ne pose pas vraiment problème, en fait.
[^] # Re: vraiment?
Posté par Yth (Mastodon) . Évalué à 10.
Quand même il ne faut pas confondre HTML et liens.
C'est quand même devenu assez standard de détecter les liens dans du texte et de les rendre cliquable.
Que ce soit avec des logiciels de chat, ou des clients mail textuels, où même la console texte de ton Linux préféré, et j'en passe, on n'a vraiment pas besoin de gérer les mails en HTML pour avoir des liens sur lesquels il suffit de cliquer comme partout ailleurs.
Le mail en HTML n'apporte pas les liens, ni les liens cliquables, mais tout le reste : les CSS, les ressources externes, les rendus foireux, etc.
[^] # Re: vraiment?
Posté par Dring . Évalué à 8.
Arf. Vu la tronche de certains liens, le moins qu'on puisse dire c'est que ça pollue la lecture.
Si j'envoie https://sous-domaine.nom-de-site-a-la-con.com/service-debile/A6787FD89789787?option1=mon_slip&option_inconnue_mais_geniale=mes_chaussettes_bleues&skip=14, c'est relou à lire.
Si j'envoie un lien vers mes chaussettes bleues, c'est mieux, non ?
Certes, ça pose des problèmes de sécurité car Mme MICHU ne va pas vérifier que le second lien pointe vers un truc qu'elle connaît et auquel elle peut faire confiance. Le curseur sur le compromis sécurité/fonctionnalité n'est pas évident à placer correctement.
Mais du coup, je suis quand même plus pour HTML dans les mails, mais peut-être uniquement un sous-ensemble. Après, essayer de s'accorder sur un sous-ensemble, ça peut vite devenir la 3ième guerre mondiale…
Rien que mettre un peu de couleur pour mettre en exergue un paragraphe, une mot, une faute, une incohérence… j'aurais du mal à m'en passer.
[^] # Re: vraiment?
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 0.
Pourquoi madame Michu ? La madame Michu que je suis fait justement encore plus gaffe quand le lien est compliqué.
Et les courriels en html mal fichus sont illisibles.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: vraiment?
Posté par Dring . Évalué à 6.
Monsieur ou Madame Michu, qui par définition ne sont pas tombés dans l'informatique, ni quand ils étaient petits, ni après avoir grandi.
[^] # Re: vraiment?
Posté par gouttegd (site web personnel) . Évalué à 8.
Moi je préfère l’option du lien en note [1]. C’est une convention que tout le monde semble comprendre, et qui ne nécessite pas d’HTML.
Faux problème. Pour la plupart des utilisateurs, rendre le lien apparent ne les rendra pas moins susceptibles de cliquer dessus, peu importe à quoi ressemble le lien.
Si une utilisatrice est du genre à savoir ce qu’il faut regarder dans un lien pour repérer les trucs louches, elle sera probablement aussi du genre à laisser son pointeur au-dessus du lien quelques secondes le temps de voir l’URL s’afficher dans l’espace prévu à cet effet.
[1] https://sous-domaine.nom-de-site-a-la-con.com/service-debile/A6787FD89789787?option1=mon_slip&option_inconnue_mais_geniale=mes_chaussettes_bleues&skip=14
[^] # Re: vraiment?
Posté par Storm . Évalué à 2.
J'aime bien cette convention, mais ça serait pas mal si ça pouvait être automatisé/transparent pour la rédaction. Ça m'arrive souvent de rajouter un lien/une note au milieu de mon texte puis je dois tout ré-indexer par la suite :(
[^] # Re: vraiment?
Posté par barmic 🦦 . Évalué à 4.
Va de 5 en 5 ;)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
:on n'est pas obligé d'utiliser des chiffres …ni une numérotation séquentielle.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: vraiment?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 7.
J’ai un collègue qui fait ça (en mail et dans les docs), et je trouve le truc pénible dès que le texte est un peu long, parce que pour aller voir le lien tu es obligé d’aller en bas du texte, de cliquer, et de remonter. Autre conséquence, ça sort complètement le lien de son contexte.
La connaissance libre : https://zestedesavoir.com
[^] # Re: vraiment?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
En mode purement textuel, pas besoin que ce soit tout à la fin. Dans une longue diatribe, j'aime bien regrouper les liens en fin de paragraphe…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: vraiment?
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 26 août 2022 à 18:37.
Tout le monde comprend certes, mais comme pour les malins qui font en chiffres romains (par exemple qui me vient en tête mais il doit y en avoir plein d'autres) c'est surtout une façon d'être pris pour le chieur de service (lien pas à l'endroit où il est utile, en réalité) qui se croit plus malin que les autres.
[^] # Re: vraiment?
Posté par gouttegd (site web personnel) . Évalué à 5.
Si des gens me prennent pour le chieur de service parce que j’ai l’outrecuidance de les obliger à baisser le regard de quelque degrés pour trouver un lien à la fin du mail, ben ils me prennent probablement pour le chieur de service pour plein d’autres raisons. Donc → rien à foutre.
[^] # Re: vraiment?
Posté par esdeem . Évalué à 6.
Mettre un lien comme note en bas de page, ça va quand le texte est, justement, paginé.
Or ce n'est pas la cas des mails a priori.
Donc, dès que ton mail fait plus que la hauteur de lecture à l'écran, c'est un problème.
Personnellement, ça me permet de me concentrer sur le contenu, plutôt que que cliquer sur le lien pour voir la suite et me perdre dans la suite du lien, mais je comprends que ça agace.
Avoir peu d’égards pour ses interlocuteurs ou ses lecteurs, c'est au mieux inélégant.
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: vraiment?
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 10.
Moi j'aime bien le format préhistorique aves ses retours à la ligne moisis car il est sympa pour ma vue (et mes goûts) en affichant le texte comme je l'entends et pas comme on me l'impose. Je pense sincèrement que les courriels en html sont une sacrée régression sur ce plan.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: vraiment?
Posté par barmic 🦦 . Évalué à 6.
Bof moi je trouve pas. Parce que quand tu laisse l'émetteur choisir la largeur de son texte ça donne souvent des choses assez louches d'avoir ses retours à
lui plus ceux de ton logiciel à toi qui ne coïncident pas (parce qu'on a pas tous la même taille d'écran, le même logiciel, etc). C'est aggravé si tu
utilise une police avec une taille particulièrement plus grosse que ce que la plèbe a l'habitude de voir.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 7.
Ah oui la capacité de l'utilisateur final à choisir ce qui lui convient le mieux est une plaie. J'ai remarqué que ça enquiquinait beaucoup dans la sphère informatique.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: vraiment?
Posté par barmic 🦦 . Évalué à 6.
Je suis pas sûr de comprendre. Tu as plus de contrôle avec HTML. C'est pour ça que l'epub c'est bien.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
plus de contrôle = les gens peuvent mettre des retour de ligne comme bon leur semble ? Mais c'est moins gênant tout à coup quand HTML ? Pas compris non plus.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: vraiment?
Posté par barmic 🦦 . Évalué à 4.
Quand tu écris un mail texte tu fais un retour à la ligne à la 78ème colonne parce que c'est ce qui est préconisé par l'IETF et les différentes rfc décrivant SMTP. Quand tu es en html, le rapport entre comment est représenté ton fichier et sa représentation graphique sont decorélés.
Tu joue avec le soft wrap et quelque soit la manière dont un lecteur veut lire ta prose avec des lignes de 7 millions de caractères ou un caractère par ligne ça fonctionne.
Si l'auteur a choisi d'ajouter manuellement des retours à la ligne html, c'est pour donner une sémantique à son texte ou un mauvais usage de l'outil et pas une contrainte de ce dernier gravé dans le marbre des RFC.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Tu dis toi-même 998 et encore, il s'agit du transport (SMTP), pas une obligation faite aux usagers ou aux agents codés avec les pieds (et/ou de bonnes intentions infernales.) Perso, quand j'écris un mail texte, bah c'est du texte comme cette réponse-ci ; ça marche pareillement et je ne vois toujours le souci. (:
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: vraiment?
Posté par barmic 🦦 . Évalué à 4.
Lis jusqu'au bout. Voila la demande exacte de l'IETF :
Et si tu regarde les usages c'est bien 78 : https://lkml.org/lkml/2022/8/26/1221
Dans la norme comme dans les faits c'est 78 caractères qui sont utilisés.
Ce que tu fais, c'est encoder ton corps en base64. C'est pas le fonctionnement de base de thunderbird et il me semble pas que ce soit le cas de mutt. C'est refusé dans un paquet de mailing list donc tu dois changer de configuration entre si tu envois ton mail dans une mailing list ou ailleurs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
should ≠ must
Une recommandation/incitation n'est pas une obligation mais doit pouvoir s'adapter aux contextes…
Je t'assure que je n'encode pas en base64 (il me suffit d'afficher le source de mes messages pour le vérifier) et je ne vois pas d'où vient cette déduction. Pour l'heure, je n'ai pas de mailing list ou autre qui rejette mes messages mais bon, j'ai arrêté pas mal de listes donc peut-être que ça me fait passer à côté de la problématique.
Inversement, au boulot, ce matin j'ai du pester contre un mail en HTML qui m'a obligé à scroller horizontalement (contrairement à ce que as voulu me vendre.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: vraiment?
Posté par barmic 🦦 . Évalué à 2.
J'ai montré des exemples que c'était ce qui est pratiqué.
Je veux bien voir un exemple pour comprendre du coup.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par Yth (Mastodon) . Évalué à 2. Dernière modification le 30 août 2022 à 12:02.
Voilà à quoi ça ressemble et ya pas de base64 dedans.
Il s'agit d'un dump caviardé du mail tel que reçu sur le serveur final (auto-mailé via SMTP perso, donc ya qu'un seul SMTP dans la boucle).
Pas de raison d'encoder en base64, le texte, bah c'est du texte et voilà.
Les entêtes c'est « Entete: », une par ligne.
Tu sautes une ligne et le contenu texte commence, sans rien de plus.
Si tu as des accents, donc que le US-ASCII ne suffit pas, ça change tout seul la fin comme ça :
[^] # Re: vraiment?
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 30 août 2022 à 14:10.
Et dans ce cas là les mua te montrent un mot par ligne. Le destinataire ne peux pas choisir de regarder tout sur une même ligne.
J'ai vu des mua tenter de faire de l'interprétation (ignorer des retours à la ligne), mais c'est bien buguer parce que ce n'est pas trivial de distinguer ton cas de :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par eingousef . Évalué à 7.
Si ça c'est pas la preuve ultime que Jean de La Fontaine n'utilisait pas l'e-mail
*splash!*
[^] # Re: vraiment?
Posté par Yth (Mastodon) . Évalué à 6.
Tu veux dire que ça se comporte comme prévu, c'est à dire qu'un retour à la ligne est un retour à la ligne ?
C'est tout l'intérêt du format texte.
Après, si tu veux laisser le client destinataire gérer la mise en page c'est aussi assez facile, tu règles ton propre éditeur local à la largeur qui te convient, et tu ne sautes pas de ligne en fin de ligne, seulement en fin de paragraphe.
Et chez le client, ça sautera naturellement les lignes en fonction de la largeur de son propre affichage.
C'est sûr que si tu sautes une ligne pour rester sous 80 de large (ou 78), et que le destinataire avec un écran peu large n'en met que 50, ça va lui faire des lignes à 50 puis 30 coupées avant la fin avant de retourner à 50 puis 30, moche et bizarre.
Mais c'est comme les « sites webs optimisés pour le 1024x768 », tu forces la mise en page, donc tu ne laisses pas faire le client, donc ça foire.
T'as tout pareil avec un ordre de grandeur en plus en HTML hein, et depuis toujours, alors même que ça a été pensé à l'origine pour régler ce problème précis et laisser la gestion de la mise en page au client !
Bref, faire du mail textuel ça fonctionne, et on pourrait faire du texte enrichi, mais il aurait fallut un sous-ensemble assez strict du HTML dès l'origine pour que ça fonctionne bien.
Là on a des clients lourds qui intègrent un moteur de rendu HTML (ou plutôt l'inverse : un moteur de rendu HTML utilisé comme client mail, comme les webmails ou même thunderbird), ce qui est salement overkill pour de la transmission de texte enrichi.
[^] # Re: vraiment?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
Et je viens du coup de comprendre ce qui s'est passé l'autre jour au taff : mon expéditeur a trouvé le moyen (ou est-ce « à l'insu de son plein gré » par exemple en faisant un copier-coller ?) de m'imposer une certaine largeur (qui du coup n'allait plus avec ma résolution et mon niveau de zoom de malvoyance, d'où obligation de scroll) avec du HTML.
Mais sinon, c'était bien mon propos, même en faisant du purement textuel, il faut laisser le client/destinataire adapter à sa/son convenance/affichage (qui peut être 50 caractères de large ou 120 et pas forcément 80…) Pas besoin de HTML pour cela…
Maintenant, si le courrielleur coupe (donc reformate dans mon dos) avant envoie, c'est de mon point de vue aussi bogué que Outlook qui choisi de concaténer des sauts de lignes des messages reçus et autres inepties.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: vraiment?
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 01 septembre 2022 à 11:49.
Dans les faits c'est faux. Tous les MUA que je connais ne font pas du optimisé pour je en sais quel taille quand ils sont configuré pour envoyer du HTML et tu marche sur les conventions si tu envoi des lignes de plus de 78 caractères.
On revient au propos de base : tu laisse plus de liberté au lecteur avec du html qu'avec du texte.
On aurait pu faire pleins de choses, par exemple normaliser un markup et s'en servire. Mais aujourd'hui ça n'est pas le cas.
Tu peux faire des lignes de la taille que tu souhaite en encodant le corps en base64. Il me semble que c'est plutôt bien géré par les MUA.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par Yth (Mastodon) . Évalué à 3.
En fait, on est en train de parler de mails presque uniquement textuels, envoyés et écrits par des gens pour des gens.
Alors que la critique du mail HTML vient plus des abus et détournements liés au fait qu'il a été jugé plus simple de mélanger client mail et moteur HTML pour faire du mail enrichi.
Je loue l'initiative de ne pas réimplémenter la roue (pourtant retaillée de nombreuses fois depuis avec les bbcode, markdown, et autres syntaxes web non-HTML pour du rendu HTML, mais ça n'est pas le sujet).
Par contre il convient de ne pas se voiler la face sur les conséquences…
Des publipostages souvent assimilables à du spam, lourds avec des traqueurs dans tous les coins, des failles de sécurité à gogo (au fil des âges, pas forcément aujourd'hui, on parle aussi du passif), et une possible perte totale de compatibilité avec le format texte initial (ici on parle de certains mails HTML totalement illisibles sur un client texte).
Après, c'est cool d'avoir du style, de la mise en page, des images etc, dans un mail.
Mais clairement, ça pose infiniment plus de problème que le texte pur.
Et, en pratique, on se passe très bien du HTML dans les mails, la plupart des gens ne voient pas d'autre différence que le fait que l'image lourdingue de leur signature saute lors de mes réponses.
[^] # Re: vraiment?
Posté par barmic 🦦 . Évalué à 2.
Mais je m'en fou de tout ça. La question initiale que je n'ai jamais quittée c'est : le quel des 2 donne la liberté au destinataire sur comment le lire ?
Les 2 autorisent celui qui envoie à saboter la lecture mais d'un côté il faut un usage particulier des MUA pour le pratiquer et de l'autre ne pas le pratiquer constitue un piétinement des bonnes pratiques.
On peut imaginer avoir un autre protocole, de nouveaux standard, des usages différents et envisager tous les tenants et les aboutissants, mais la question était simplement le quel donne le plus de contrôle au destinataire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par Yth (Mastodon) . Évalué à 3.
Ah bah c'est une question facile ça :
Le format texte, c'est le seul des deux où tu vois directement ce que l'expéditeur a envoyé en entier, sans rien de caché, sans ressources externes qui pourraient foirer, sans dépendre d'un moteur de rendu.
Ou alors tu lis tes mails en HTML par le code source, là tu as le contrôle.
À la réception, tu contrôles vachement mieux ce que tu reçois quand tu le reçois au format texte !
C'est nettement plus simple pour les lecteurs d'écran pour personnes aveugles. Tu peux choisir tes couleurs (texte/fond) de façon générale et sans risquer qu'elles soient pourries, ce qui est utile pour les personnes mal-voyantes, ou atteintes de dyschromatopsie.
C'est lisible sur liseuse ebook connectée à internet, ça se lit aussi bien sur smartphone, écran large, ou notifications système.
Tu choisis si tu veux un affichage monospace ou avec la police que tu veux avec ligatures et tout, bref c'est du texte, tu en fais ce que tu veux.
Gérer du texte c'est toujours moins contraignant que de gérer de l'HTML.
Après, tu peux chipoter sur ces histoires de sauts de ligne, mais en pratique ça ne t'affectera que si ton affichage fait moins de 78 de large (ce qui peut arriver).
Après, si ton client mail gère les mails HTML, il gérera aussi bien les mails texte, avec les mêmes avantages que cités plus haut, donc clairement tu en fera « plus » avec un client mail qui gère le HTML.
[^] # Re: vraiment?
Posté par barmic 🦦 . Évalué à 1.
Je vais pas réitérer une troisième fois avec une troisième personne.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par claudex . Évalué à 7.
Non, il y a des retours à la ligne n'importe où (parce que mon smartphone ne fait pas 78 caractères de large).
C'est un texte avec un caractère technique (le CRLF à 78 caractère) qui est mélangé avec un caractère de mise en forme et pour lequel il n'y a aucun moyen de faire la distinction.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: vraiment?
Posté par Yth (Mastodon) . Évalué à 4.
Les seuls mails que je reçois avec une mise en page vraiment pétée sont ceux incluant des URLs à rallonge, et définis en tant que HTML.
Là, le client mail sur smartphone fait un rendu HTML et rétréci l'affichage pour t'afficher l'URL en entier, c'est illisible.
Le même en texte t'afficherait l'URL sur plusieurs lignes.
La coupure à 78 caractères n'est pas dans tous les mails textes, et va péter un peu la mise en page sur smartphone, tout en laissant lisible, mais bizarre. C'est moche, on est d'accord, gênant parfois.
Quand aux vrais mails enrichis de partout en HTML, très souvent sur smartphone, l'affichage est bien pété, parce que c'est loin d'être toujours pensé pour les écrans peu larges…
Les problèmes du HTML sont multiples, ceux du texte, bah il y en a un.
[^] # Re: vraiment?
Posté par flan (site web personnel) . Évalué à 3.
Au contraire, le HTML permet de donner des indications sur le rôle de chaque contenu, faire de la mise en forme pour permettre d'aller à l'essentiel, d'utiliser des couleurs, etc.
Je ne vois vraiment pas comment du texte brut pourrait être plus expressif que du HTML.
[^] # Re: vraiment?
Posté par Yth (Mastodon) . Évalué à 5.
Alors des sites web avec un travail fait pour différencier le contenu intéressant du reste, une utilisation technique des balises HTML pour les personnes mal-voyantes, etc, oui, on est parfaitement d'accord.
Et du web pur-texte sans aucun système d'enrichissement du texte, même Gemtext/Gemini ne fait pas ça, ça n'aurait pas tellement de sens.
Mais qui va faire ça dans un email ?
Qui a déjà fait ça dans un email ?
Qui a déjà vu ça dans un email ?
Le HTML dans un email ça sert à :
- rajouter
du *gras*, de l'/italique/, _souligner_, ou -barrer-;- mettre un peu de couleur ;
- faire des liens dont on ne voit pas directement l'URL, mais un texte plus propre et explicatif (idéal pour le phishing) ;
- intégrer une image au milieu du texte plutôt qu'en pièce jointe affichée à la fin du texte ;
- faire d'immondes publipostages ;
- rajouter des signatures de merde avec des images (en texte il y a l'ASCII-Art pour faire de la merde, ça prend autant de place mais moins d'octets, zéro partout, la balle au centre).
Y'a-t-il d'autres cas d'usage réellement utiles ou utilisés ?
[^] # Re: vraiment?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Justement, avec du HTML bien fait ça ne devrait poser aucun problème.
On devrait avoir des emails qui ressemblent à ça. Pas des trucs qui clignotent comme un sapin de Noël.
Et du coup ça se redimensionne bien à la taille de la police de caractères et à la taille de la fenêtre dans laquelle on l'affiche. Où à la taille du papier si on l'imprime.
Ce n'est pas le cas avec les emails au format texte où c'est l'expéditeur qui choisit combien de caractères par ligne il veut mettre. Par exemple sur mon téléphone, si quelqu'un envoie un mail avec une ligne un peu trop longue, mon téléphone réduit la taille du texte pour faire rentrer cette ligne sur une ligne, et tant pis si ça donne une taille de texte microscopique. Ou alors, il ne le fait pas, et il faut faire défiler le mail de gauche à droite pour le lire.
On peut commencer à se dire qu'on va reformater le texte et ajouter ou supprimer des retours à la ligne là ou ça va bien mais, ce n'est pas comme ça que les mails au format texte sont supposés fonctionner. D'où l'introduction du HTML qui permet de
transporter du texte en indiquant clairement les endroits ou il y a des paragraphes normaux, et les endroits ou il y a un schéma en ASCII art par exemple, qu'il ne faut surtout pas transformer sous peine de les rendre incompréhensibles.
[^] # Re: vraiment?
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 3.
Mouais c'est pas plutôt des logiciels codés avec les pieds ?
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: vraiment?
Posté par barmic 🦦 . Évalué à 6.
Non parce que tu ne peux pas déterminer ce qui est un retour à la ligne qu'il faut garder (pour garder du sens) ou pas.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par sobriquet . Évalué à 4.
Le seul cas que je vois où il ne faut pas garder un retour à la ligne, c'est éventuellement quand il y en a plusieurs à la suite. Il y en a d'autres ? Un retour à la ligne manuel marque un changement de paragraphe. On n'en fait pas au milieu d'une phrase, on laisse le logiciel du destinataire se débrouiller pour les mettre où il faut lors de l'affichage. S'il ne le fait pas, c'est que le destinataire préfère avoir des paragraphes unilignes, c'est son problème.
Je vote aussi pour le logiciel codé avec les pieds.
[^] # Re: vraiment?
Posté par barmic 🦦 . Évalué à 7.
Voilà pour ce que j'ai en tête, mais on doit pouvoir en trouver d'autres.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par sobriquet . Évalué à 2.
Pour moi, ce ne sont que des cas où il faut conserver les retours à la ligne. Soit tu mets réellement des retours à la ligne au milieu de tes phrases, et c'est pour moi une mauvaise pratique, soit je comprends rien :/
[^] # Re: vraiment?
Posté par barmic 🦦 . Évalué à 4.
Si je prends le dernier mail envoyé par un humain à l'heure où j'écris sur la LKML.
https://lkml.org/lkml/2022/8/26/1221
Si mon dispositif d'affichage est configuré pour avoir des lignes plus petites que le nombre de caractères de large que ce qu'il a utilisé, j'aurais un saut de ligne là où je mis attend et en cours de route systématiquement. Et c'est ça la pratique la plus rependu avec cet usage text plain. C'est pour ça que j'en ai fais un exemple dans mon premier message.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par sobriquet . Évalué à 2.
Merci, je comprends mieux ! En fait, c'est l'éditeur de texte de l'expéditeur qui rajoute des retours à la ligne que je qualifierais d'intempestifs. C'est vraiment un comportement bizarre, pour les raisons que tu as bien exposées. Je suis très étonné que les contributeurs de la LKML semblent l'employer si abondamment. Quelqu’un saurait m'expliquer ce choix ? C'est parce qu'ils envoient leurs mails avec leur éditeur de code ?
La logique "retour à la ligne = nouveau paragraphe" me semble bien plus naturelle et facile à gérer.
[^] # Re: vraiment?
Posté par barmic 🦦 . Évalué à 10.
Comme dit ted la RFC5322 pose une limite à 998 caractères en consultant de se limiter à 78.
78 parce que au doigt mouillé ils ont trouvé que ça marchait bien avec la plupart des MUA (en octobre 2008)
le paragraphe qui parle de ça dans RFC5322
la partie qui parle de ça dans la RFC5321 mais c'était présent dès la première RFC sur le sujet la 821 de 1982
Tu remarquera que les RFC elles-mêmes utilisent cette convention, mais comment sont écrites les RFC ? Je veux dire, la RFC 821 qui décrit le mail. Les 820 premières RFC n'ont pas été envoyées par mail.
Elles étaient tapées à la machine à écrire et les machines à écrire ont longtemps eu des limitations à 80 caractères. 78 c'est 80 moins CR LF.
Tout n'est pas complètement figé car depuis 2019, ils publient les RFC en text (toujours en 78 colonnes faudrait pas trop brusquer), html, pdf et xml (un exemple).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par sobriquet . Évalué à 3.
Merci pour cette réponse très complète qui va me donner du grain à moudre.
J'ai tendance à penser que les contraintes logicielles ne devraient pas tant interférer avec la forme rédactionnelle. Il est certainement possible de faire des choses au niveau de la couche de présentation pour qu'il n'y ait pas de limite tangible à la longueur de ligne et que l'utilisateur ne soit pas gêné par les choix de longueurs de ligne des autres utilisateurs.
[^] # Re: vraiment?
Posté par barmic 🦦 . Évalué à 6.
Oui mais c'est un peu le problème avec les couplages, tu peux totalement les ignorer et passer à côté. La RFC821 qui crée smtp a 40 ans ce mois ci. On a plus de recul.
Tout à fait ça demande d'avoir un encodage entre ce qui est affiché et ce qui passe sur le réseau, par exemple tu encode en base64. HTML peux être vu comme une forme d'encodage dans ce contexte. Aux débuts d'internet on pensait que les protocoles en mode texte était géniaux car très facile à debuger. En effet tu peux directement lire ce qui passe sur le réseau. Dans les faits c'est une très mauvaise idée en particulier quand tu passe des données utilisateur. Actuellement de moins en moins de protocoles n'ont plus l'avantage d'être lisibles car ils transitent sur du TLS tout en gardant les inconvénients du mode texte (le contenu transmis impact le protocole et il passe en base64 s'il y a conflit entre le contenu et le fonctionnement du protocole ce qui augmente le volume a envoyer).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par PR . Évalué à 3. Dernière modification le 28 août 2022 à 10:05.
Au début d’internet, les machines étaient aussi beaucoup plus diversifiées et l’envoi en mode binaire ne se serait pas résumé à fixer l’endianness…
Par exemple le protocole SMTP autorise des bytes de 7 bits. D’où ses limitations.
Rien n’empêche la transmission de données arbitraires dans un protocole purement texte (exemple HTTP).
Mort aux cons !
[^] # Re: vraiment?
Posté par barmic 🦦 . Évalué à 3.
Bof tu avais déjà des protocoles binaires à l'époque.
HTTP est bien plus simple et il n'utilise des caractères de contrôle que sur ses en-têtes et la première ligne.
Je ne sais pas ce qu'il en est pour http3 mais il avait été question pour http2 de passer les en-tête en binaires.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par ted (site web personnel) . Évalué à 3.
Ayant déjà eu à créer des mails envoyés par PHP, j'allais répondre que la norme impose de ne pas dépasser 78 caractères par ligne, mais je viens d'apprendre que ce n'est qu'une recommandation, la limite stricte étant de 998 caractères.
Un LUG en Lorraine : https://enunclic-cappel.fr
# Sylpheed
Posté par Yth (Mastodon) . Évalué à 10.
Sylpheed ou claws-mail, sont des clients mails très efficaces mais qui de base ne font que du texte.
J'utilise personnellement Sylpheed, et je ne parlerai pas des différences avec Claws.
Si tu reçois un mail en HTML pur, il est transformé en texte, parfois avec plus ou moins de succès, mais en général c'est lisible sauf pour les publipostages bien pourris.
De toute façon Sylpheed n'affiche que du texte.
Les liens sont correctement pris en compte et cliquable, que le mail soit texte ou qu'on ait une balise A du HTML (dans ce cas il affiche bien le contenu de la balise, et on clique vers son HREF, comme un lien classique).
Ensuite on peut voir la liste des pièces jointes, et les mails texte et HTML sont présentées comme des pièces jointes particulières, donc si tu as un mail avec les deux versions, tu peux afficher l'une ou l'autre (et parfois avoir dans la version texte : ton client gère pas le HTML, dégage s'il-te-plaît).
Mais aussi, comme avec n'importe quelle pièce jointe, tu peux l'ouvrir dans un outil externe, et donc ouvrir ton mail en HTML dans un vrai navigateur web, si vraiment tu en as besoin.
Dans la très grande majorité des cas, tout fonctionne au poil. Les seuls mails posant des soucis étant les publipostage souvent très surchargés en HTML, et régulièrement sans version texte associée (aaah, les promos GoG…). Ou les mails pro à la con genre réunion Teams, ou ticket Jira, qui sont aussi assez généralement mal foutus (mais lisible, en général on voit bien les liens, et on peut cliquer sur le truc important sans lire le contenu généré et inutile)…
Et au final, vivre dans un monde où ton client mail ne gère pas plus le HTML que ça, bah ça marche pas mal. C'est toujours rapide parce qu'il n'y a jamais de rendu web, et donc les ressources externes (un des vrais drames des mails en HTML), bah il ne cherche même pas à savoir, ça ne sert à rien.
En ce qui concerne la réponse en haut ou en bas, franchement ça dépend.
Si c'est une conversation standard en texte, en général je simplifie le message reçu en ne gardant que ce à quoi je réponds, et je poste en dessous, mais ce sont des efforts, il faut que la conversation mérite toute cette attention.
S'il s'agit d'une discussion de groupe où tout le monde réponds au dessus, je fais comme tout le monde et je réponds au dessus.
Et si c'est une réponse express, je réponds en dessous sans dire bonjour ni rien en mode Crocker.
Bref, c'est pas si difficile le mail en texte, mais je conseille d'utiliser un outil qui ne fait que ça.
Je trouve le côté bâtard de Thunderbird assez pénible, et lourd, quand on l'utilise en mode pur texte et pas HTML (bâtard parce qu'on utilise un outil pensé pour rendre du HTML mais en fallback texte).
[^] # Re: Sylpheed
Posté par freem . Évalué à 4.
Juste un commentaire quand même, pour préciser que ces logiciels (enfin, au moins claws, mais je doute que sylpheed n'en ait pas) ont un plugin pour faire le rendu HTML directement.
Pour ma part, je ne l'utilise pas, et en effet, quand je peux utiliser claws mail, mes mails sont… juste efficaces.
Oui, c'est du rendu texte, mais personne ne s'en est jamais offusqué, tout comme je ne m'offusque pas qu'ils utilisent du html… pour la simple et bonne raison que je ne m'aperçois pas qu'ils utilisent html, et qu'eux ne s'aperçoivent pas que j'utilise du texte brut avec une fonte mono-space.
La seule chose qu'ils voient, c'est que je ne mets pas de couleur dans mon texte, et qu'au lieu de souligner, mettre en gras, italique, etc, j'utilise en gros du markdown (qui tire ses origines… du mail, justement, me semble?).
Bref, ça juste marche. Le seul moment ou ça ne marche pas, c'est pour les rendez-vous, mais je n'ai pas testé depuis un bail (peut pas utiliser claws a mon poste actuel, malheureusement… je dois me farcir les horribles outlook lourd et web qui sont totalement inutilisable à mes yeux) ça a peut-être changé (extension vcalandar? Je ne sais pas ce qu'elle supporte exactement.)
[^] # Re: Sylpheed
Posté par Astaoth . Évalué à 4. Dernière modification le 26 août 2022 à 19:08.
Pour avoir utilisé Claws-mail et encore utiliser Sylpheed à côté de Thunderbird (pour des usages différents), je les trouve tout les deux particulièrement pénibles pour leur absence de multi-thread. Quand on a pas mal de boites de courriels, le temps de relève est assez long. Si c'est par hasard juste au moment où on regardait ses boîtes, on a le temps d'aller se faire un thé avant de pouvoir les consulter.
Emacs le fait depuis 30 ans.
# Mon avis
Posté par Psychofox (Mastodon) . Évalué à 10.
le text brut ne pose aucun problème particulier, sauf si tu veux illustrer un truc. Mais bon au pire c'est pas si gênant si tu nommes bien tes attachements.
Top posting, bottom posting, aucun n'a des sens: il faut arrêter de citer toute la conversation, c'est idiot. Il est plus intelligent de ne citer que les passages auxquels on répond, de manière individuelle. Quand on répond à un courrier, on ne renvoie pas une enveloppe avec sa réponse + le courrier précédent. Le destinatarie en connait déjà le contenu!
comme dit plus haut, DdV a quelques bonnes idées, beaucoup de temps à perdre et beaucoup de productivité mais ça n'en fait pas un gourou qu'il faut écouter les yeux fermés.
[^] # Re: Mon avis
Posté par Dring . Évalué à 7.
100% d'accord pour le point sur Top posting, bottom posting.
En entreprise, quand on se retrouve avec un mail qui fait 300 ko de simple texte juste parce que tout s'accumule depuis le début de la discussion il y a 5 mois, ce n'est pas vraiment de la frugalité numérique.
Et évidemment, retrouver la bonne info dans ce merdier…
[^] # Re: Mon avis
Posté par Christophe B. (site web personnel) . Évalué à 4.
Sans parler du fait que la plupart des "utilisateurs" (en restant polis) utilise leur boite mail comme une base de données
Certains on compris la différence en POP et IMAP le jour ou le disque dur de leur ordi portable a rendu l’âme … sans sauvegarde bien sur, c'est pour les lâches
Bref si le mail ne servait qu'a véhiculer de l'information et qu'il y a avait un outil pour stocker correctement l'info de manière pertinente et efficace on n'en serait pas la …
C'est vrai un peu comme un forum …
[^] # Re: Mon avis
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 3.
Eh eh, ça fait partie des trucs que je pense traiter cette histoire de mails.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Mon avis
Posté par Christophe B. (site web personnel) . Évalué à 2.
Oui j'ai toujours pensé qu'il y avait un gaspillage énorme avec ces mails
de temps et de ressources informatiques.
Et ce avant même de prendre en considération les spams et autres péniches qu'il faut élargir …
[^] # Re: Mon avis
Posté par flan (site web personnel) . Évalué à 2.
le texte brut me pose pas mal de problèmes, on ne peut par exemple pas faire de la typographie même de base (couleur, italique, indices, exposants, gras, …), ni faire de liens utilisables.
garder l'historique est bien pratique quand le message est transmis à une personne qui n'était pas dans les échanges initiaux (très fréquent). Bien évidemment, il faut que tout le monde utilise la même chose… et continuer au-dessus du dernier message permet d'accéder directement au dernier message (donc la partie utile dans 99% des cas).
[^] # Re: Mon avis
Posté par Dring . Évalué à 8.
Mon expérience (et pas qu'une fois) : le mail qui contient juste "peux-tu regarder ?" suivi de 30 pages de mails, avec l'information pertinente perdue au milieu des signatures, des entêtes, des suivis, et j'en passe.
Le temps gagné à ne pas avoir à recopier l'information utile vaut-il le temps perdu par tous les autres à errer dans le monstre d'information inutile que cela engendre ?
[^] # Re: Mon avis
Posté par barmic 🦦 . Évalué à 5.
Ce genre de mail consiste justement à extraire et détailler l'information utile. Si celui qui te donne la tâche le fait à ta place, il n'a pas besoin de toi. Il peut aussi faire des erreurs de transcription, penser qu'un point n'est pas pertinent alors que si, etc
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mon avis
Posté par gouttegd (site web personnel) . Évalué à 8.
Bah non, pas forcément, je ne vois pas ce qui te fait dire ça.
Ce qu’on te demande quand on t’envoie ce genre de mails n’est pas forcément une information contenue dans l’historique de la discussion. On peut te demander ton avis sur une idée qui a été proposée dans la discussion, on peut te demander de rajouter des infos inconnues des participants, etc.
Et comme dit PsychoFox plus bas, si après une discussion qui s’est potentiellement étalée sur plusieurs semaines (voire mois) et a consisté en plusieurs dizaines de messages, on décide de solliciter une personne extérieure à la discussion pour son avis/aide/commentaire pertinent/etc, la moindre des choses c’est de synthétiser la discussion et de poser une question précise, au lieu de laisser le destinataire fouiller l’historique à la recherche de la question.
D’autant plus que dans une discussion suffisamment longue, il est tout-à-fait possible qu’il y ait eu plusieurs questions abordées, ce n’est pas forcément évident pour le destinataire de savoir sur quoi on lui demande son avis si tout ce qu’il a, c’est un message comme ça :
Quand bien même on n’en aurait rien à faire de la politesse, c’est aussi une question d’efficacité.
(Et même dans le cas où on demande une synthèse, ça n’interdit pas de le demander clairement : « Tu peux me faire une synthèse de cette discussion pour la réunion de demain ? », au lieu encore une fois de laisser le destinataire deviner ce qu’on attend de lui.)
[^] # Re: Mon avis
Posté par barmic 🦦 . Évalué à 0.
C'est exactement pareil. Le demandeur n'est probablement pas à même de déterminer ce qui est l'information pertinente ou non pour que tu donne ton avis.
La personne qui va faire passe et quasiment systématiquement moins compétente sur le sujet, lui demander d'ajouter un travail amène facilement une détérioration de l'information. Prendre un mauvais choix ou devoir repartir à la pêche aux informations n'est pas plus efficace. Si la personne est aussi compétente que toi, alors c'est par manque de temps qu'elle ne répond pas elle même au mail donc lui demander de prendre du temps en plus ne marche pas bien.
Mais ça n'a rien à voir avec la manière dont tu gère l'historique de la conversation.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mon avis
Posté par gouttegd (site web personnel) . Évalué à 6.
Not buying it, sorry. Il participe à une discussion s’étalant sur plusieurs dizaines de messages et il n’est même pas fichu de faire un résumé du problème ? Peut-être qu’il n’avait rien à faire dans la discussion en premier lieu, alors.
Encore une fois, not buying it. S’il était assez compétent pour participer à la discussion jusqu’au moment où il se rend compte qu’une personne mieux placée pour résoudre le problème n’est pas là, il devrait être assez compétent pour exposer le problème en question.
Voilà. Je veux bien accepter l’excuse du manque de temps, mais par contre essayer de faire passer ça pour de l’humilité en mode « mes compétences si inférieures aux vôtres ne ne permettent pas de vous faire un résumé, aussi je vous transmets l‘intégralité des trois dernières semaines de discussion », c’est du foutage de gueule, désolé. En réalité, le message c’est « mon temps est plus précieux que le tien, débrouille-toi avec ça. »
[^] # Re: Mon avis
Posté par barmic 🦦 . Évalué à 2.
C'est loin d'être aussi simple. Pour un mail qu'il t'a renvoyé comme ça, combien il t'a évité ?
Je déteste les compte-rendus. C'est chiant à faire c'est chiant à relire c'est toujours bourrés d'erreurs et les 3/4 sont incompréhensibles si tu n'a pas le matériau initial ce qui en fait un non sens absolu. Traiter une chaîne de mail c'est simple et tu esquive d'avoir emmerdé tout le monde pour t'économiser au mieux quelques minutes.
Les compte-rendus devraient être réservés pour les nécessité absolue et pas devenir une règle au quel cas c'est exactement la même chose que les réunions. Tu fais des CR des CR de CR, tu te retrouve avec des professionnels du compte rendu qui ne produisent plus rien.
Chaque organisation à son contexte, mais je souhaite ne jamais avoir à travailler avec un chef avec le quel je n'accepte pas d'échange hyper formel. Mon temps n'est pas plus précieux que le mien, on regarde au cas par cas quel est le côté où c'est le plus efficace de travailler. Ça a toujours été du côté du dev dans tous les contextes que j'ai pu voir parce que même si on peut trouver ça rébarbatif, éviter une abstraction évite beaucoup de problèmes.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mon avis
Posté par gouttegd (site web personnel) . Évalué à 3.
Et alors ? Je ne connais personne qui aime ça. Ça n’enlève rien au fait qu’il y a des situations où un bon compte-rendu est utile.
Il y a plein de choses dans le même genre. La documentation, les tests unitaires… je ne connais personne qui aime ça. C’est chiant à faire, c’est jamais complet, pendant qu’on fait ça on n’avance pas sur ce qui est important, etc.
Je comprends très bien qu’on veuille s’épanouir dans son travail en passant plus de temps sur les choses qu’on aime faire, mais perso je souhaite ne jamais avoir à travailler avec des types qui poussent ça jusqu’à refuser de consacrer la moindre seconde de leur temps aux tâches qu’ils n’aiment pas — et pire encore, qui tentent de justifier ça en disant « ça sert à rien d’toute façon, j’suis un dev moi, pas un gratte-papier qui ne produit rien ! »
[^] # Re: Mon avis
Posté par barmic 🦦 . Évalué à 1. Dernière modification le 28 août 2022 à 15:49.
Quand l'accès au contenu brut est trivial ce n'est que du bruit voir de la désorganisation.
Je dis justement que je peux aussi faire l'analyse sans qu'on m'ai préparé un compte rendu. Tu inverse les rôles !
Et tu as omis mon dernier paragraphe qui dis que chaque organisation voit comment elle se gère et que c'est à voir qui doit faire l'analyse celui qui transmet ou celui qui reçoit. Dans mon expérience c'est plus efficace que ce soit le second.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mon avis
Posté par gouttegd (site web personnel) . Évalué à 3.
Analyse basée sur l’hypothèse que l’historique qu’on t’a transmis contient tout ce que tu as besoin de savoir. J’espère pour que pour toi que c’est bien le cas. (Voir mon message plus bas sur les discussions en plusieurs threads, et l’absence totale de garantie que le thread qu’on te passe contient bien toute la discussion.)
Putain, c’est magique…
La discussion commence par quelqu’un qui raconte son expérience :
Tu répliques par une affirmation péremptoire :
Je fais remarquer que non, ce n’est pas une généralité :
Nouvelle réponse péremptoire :
Et nouvelle généralité (à peine tempérée par un modeste « quasiment ») :
(OK, à partir de là je généralise aussi en postulant que quelqu’un d’assez compétent pour participer à une discussion est aussi compétent pour en extraire un résumé compréhensible. Je plaide coupable. Je veux bien admettre que ce n’est pas forcément toujours le cas — mais ça le devrait¹).
Et à la fin tu conclus que non, mais chaque organisation fait comme elle l’entend, hein, moi je ne faisais que partager mon expérience qui dit que ma façon de faire est la bonne, c’est tout.
Merci pour la rigolade, mais j’ai assez perdu de temps, j’ai des compte-rendus à rédiger.
¹ Je soupçonne au passage que si la personne est incapable de faire une synthèse correcte, ce soit beaucoup plus parce que ça la gonfle de devoir faire une synthèse, que parce qu’elle n’en a pas les compétences. Mais je généralise, désolé.
[^] # Re: Mon avis
Posté par freejeff . Évalué à 2. Dernière modification le 28 août 2022 à 17:17.
Barmic a bien du courage d'essayer de te répondre pour te faire comprendre son point de vue … Tes réponses sont d'une agressivité inutile, d'un cynisme impressionnant et de renversements de charges systématiques, que c'est désagréable, j'ai juste suivi pour encourager barmic dans sa démarche, mais pour le coup, c'est bien toi, qui répond un peu à coté à chaque fois avec un ton agressif. Tout ça un dimanche … la magie de LinuxFR …
-->[]
[^] # Re: Mon avis
Posté par Dring . Évalué à 5.
Nos expériences sont franchement différentes.
Déjà, c’est pas souvent mon boss qui m’envoie ce genre de chose. Au contraire mon boss fait de son mieux pour qu’aucun de nous ne perde de temps.
Non, en général c’est plutôt quelqu’un qui sait que le sujet pourrait me concerner, voire que je pourrais être celui qui pourra répondre à des interrogations qui bloquent le sujet.
Comme je suis un gentil garçon et que j’aime bien faire « l’extra-mile » je décortique le tout et comme suggéré par un autre je me retrouve à renvoyer un mail avec « c’est bien le sujet XXX qui t’intéresse ? » potentiellement avec un début de réponse et/ou de partage de connaissance.
Début seulement car je n’exclue pas d’avoir mal interprété la demande et je ne veux pas perdre (trop) de temps.
Pour moi pas de doute : le gars en face ne voulais juste pas se faire chier. Il m’aurait demandé « c’est bien toi qui gère XXX » on aurait déjà gagné beaucoup de temps. Avec un peu de contexte supplémentaire « c’est lié à la demande du client YYY » j’aurais carrément aimé.
Le pire que j’ai eu c’est :
- mail totalement flou avec grosse chaîne d’historique
- réponse avec des détails et demande de confirmation
- réponse « j’en sais rien je m’occupe pas de ça »
La médiocrité et le jenfoutisme n’ont aucunes limites. La politesse et le respect si, hélas.
[^] # Re: Mon avis
Posté par flan (site web personnel) . Évalué à 1.
Pourquoi systématiquement partir du principe que les autres correspondants sont à la fois impolis et incompétents ?
[^] # Re: Mon avis
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 6.
Parce que c'est le pire cas qu'il va falloir gérer proprement.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Mon avis
Posté par barmic 🦦 . Évalué à -1.
Pas nécessairement si ça arrive peu fréquemment tu t'en fou.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mon avis
Posté par barmic 🦦 . Évalué à 3.
Alors pour moi c'est pas une question d'incompétence générale mais sur la question qu'il pose. Si je t'envoie un message pour te demander quelque chose, c'est généralement parce que je te considère comme plus compétent que moi sur le sujet, sinon je répondrai moi même à la question. Note que ça marche même à compétence égale en fait, si j'ai un avis et que je te demande le tiens d'une part je ne sais pas complètement sur quoi se base ton avis donc je ne sais pas forcément quoi enlever et quoi garder, mais en plus si je le fais je vais inclure mon biais dans ta prise de décision.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mon avis
Posté par Thomas Debesse (site web personnel) . Évalué à 5. Dernière modification le 27 août 2022 à 19:00.
Dans ce cas il convient d’exprimer l’intention clairement. Comme dans l’exemple déjà proposé : « Tu peux me faire une synthèse ? ».
La même question peut d’ailleurs être posée en ces termes exacts même s’il n’est pas question d’être plus ou moins compétent, simplement par répartition de charge/répartition de tâche/délégation/spécialisation/autres motifs relevant de l’organisation du travail et de l’effort social.
Défendre le « peux-tu regarder ? » contre le « tu peux me faire une synthèse » (ou autre besoin/intention explicite) c’est défendre un ordre social qui exige que l’autre doive connaître les intentions sans les exprimer, ce qui à un certain niveau peut même relever d’une forme d’abus : 1. l’exigence peut-être démesurément élevée, 2. l’investissement pour y satisfaire (ou s’en approcher) peut être démesurément élevé.
Évidement on est en droit d’exiger une connaissance commune et une culture partagée jusqu’à un certain niveau (exiger que rien ne soit implicite serait une autre forme de violence) mais les transfert de mail en mode sans intention explicite où l’on ne sait pas si ça demande une synthèse, un commentaire, ou même une mise en œuvre, c’est quand même un exemple classique de dysfonctionnement de communication.
La bonne recette du boulot pourri : 1. Intention non explicite, 2. Insatisfaction, 3. « comment ça c’est pas évident, mais ça devrait être évident, en fait c’est ça ton problème !!!! ». :D
Ça se désamorce généralement bien en proposant une question façon « c’est bien ça que tu me demandes ? ». Au pire, le « mais ça devrait être évident » arrive à ce moment-là avec moins de violence, plutôt que d’avoir sur le dos les conséquences de l’incompréhension. Et puis si l’autre ne répond pas à la question, la responsabilité de son insatisfaction lui revient objectivement. :D
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Mon avis
Posté par barmic 🦦 . Évalué à -1.
Blablabla
C'est complètement HS et il était question de gestion de l'historique des mails. Personne n'a défendu une formulation particulière.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mon avis
Posté par sobriquet . Évalué à 3. Dernière modification le 27 août 2022 à 00:23.
C'est une bonne remarque, même si je ne trouve pas que ce soit si fréquent. Pour ceux qui comme moi, utilisent le mode Conversation il suffirait que le client mail offre une fonction "Reprendre l'historique" qui mette toute la conversation dans le mail, et le problème serait alors réglé.
[^] # Re: Mon avis
Posté par eingousef . Évalué à 2.
Je n'ai jamais eu à le faire mais c'est pas bête comme fonctionnalité, du coup j'ai cherché si ça existait dans mutt.
Il y a un raccourci "Shift+A" qui permet d'attacher des mails en pièce jointe. On sélectionne la boite mail, puis on taggue les mails dans l'index ( "t" ), on quitte la vue et ça les ajoute dans le mail. Je ne sais pas comment il se débrouille pour l'ordre par contre, j'ai l'impression qu'il va les chercher dans l'ordre chronologique. Du coup si on veut faire plaisir à un adepte du top-posting qui aime lire les conversations de bas en haut, il faut attacher les mails un par un du plus récent au plus ancien.
*splash!*
[^] # Re: Mon avis
Posté par Psychofox (Mastodon) . Évalué à 9.
La courtoisie de base est de faire une synthèse des échanges et du statut actuel. Renvoyer tout l'historique, avec une bonne partie qui est probablement erronnée, obsolète et corrigée entre temps c'est d'une part rude, mais aussi prone à rajouter des confusions car le destinataire va forcément devoir lire en diagonale pour ne pas y perdre des heures.
C'est la pire des choses à faire.
La bonne pratique c'est de faire un résumé, et d'énoncer clairement ce qui est attendu du destinataire. Si on veut y ajouter l'historique complet, c'est dans un fichier en attachement.
[^] # Re: Mon avis
Posté par Psychofox (Mastodon) . Évalué à 3.
s/rude/malpoli/
[^] # Re: Mon avis
Posté par Claude SIMON (site web personnel) . Évalué à 2.
s/prone/propre/ :-)
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Mon avis
Posté par Psychofox (Mastodon) . Évalué à 3.
Ah bien vu, merci. C'était pire que ce que je pensais.
[^] # Re: Mon avis
Posté par Dring . Évalué à 4.
Toutafé et d’autant que non, la partie utile n’est pas dans le dernier message dans 99% des cas ; ce serait plutôt du 50% hélas.
[^] # Re: Mon avis
Posté par gouttegd (site web personnel) . Évalué à 8.
Parfois c’est encore pire, la partie utile n’est même pas dans l’historique joint au message.
Pour peu que la discussion ait duré suffisamment longtemps ou ait impliqué un grand nombre d’intervenants, elle risque fort d’être éclatée en plusieurs threads, et rien ne garantit que la partie utile sera dans le thread dont l’historique a été passé au nouvel intervenant.
Raison de plus pour faire une synthèse de la discussion, qui d’ailleurs ne bénéficiera pas seulement à la personne dont on sollicite l’avis mais aussi à tous les autres participants à la discussion.
# Comme Gemini, un standard à refaire
Posté par Benjamin Henrion (site web personnel) . Évalué à 2.
Comme Gemini, il faut refaire le protocole de mail, pour utiliser par défaut du mixing et de l'encryption obligatoire.
Les apps de chat ont déjà pris de l'avance.
[^] # Re: Comme Gemini, un standard à refaire
Posté par Toufou (site web personnel) . Évalué à 3.
Marrant on parle d'économies de bout de chandelles en utilisant du plaintext au lieu de HTML, sachant que si on veut vraiment gagner de la ressource sur le mail, on commence par interdire et sanctionner réellement la pub en ligne.
Et blam, tu nous parles de rajouter une couche de consommation de ressource en chiffrant systématiquement :D
On a pas sorti le cul du CO2 :D
[^] # Re: Comme Gemini, un standard à refaire
Posté par David Demelier (site web personnel) . Évalué à 4. Dernière modification le 29 août 2022 à 13:20.
Ouais enfin entre une publicité et du chiffrement il y a une différence. Le chiffrement ça consomme pas 3Mo de Javascript contrairement à une page web illisible.
En revanche, moi je serais assez partant pour un nouveau protocol d'échange 100% chiffré parce que recevoir mes mots de passe de mailing list et mes fiches de paies par mail ça me gonfle.
Les mails, c'est probablement la chose la moins bien faite de l'histoire d'internet (après ftp, ok) et son utilisation encore plus. (multipart, bottom-posting, séparation des couches, etc, etc.).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Comme Gemini, un standard à refaire
Posté par flan (site web personnel) . Évalué à 3.
C'est sûr, le moindre film en HD représente des milliers de courriels.
[^] # Re: Comme Gemini, un standard à refaire
Posté par Toufou (site web personnel) . Évalué à 1.
ah oui je les avais oubliés les films. D'après ça en 2019 c'était 60% du trafic internet… Dommage qu'on n'ait pas la consommation électrique pour le décodage vidéo !
[^] # Re: Comme Gemini, un standard à refaire
Posté par flan (site web personnel) . Évalué à 2.
J'avais eu les stats d'un FAI français, et c'était encore plus important (de l'ordre de 80 ou 90%).
[^] # Re: Comme Gemini, un standard à refaire
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
https://www.arcep.fr/actualites/les-prises-de-parole/detail/n/interview-bfm-tv-rapport-etat-internet-france-2022-300622.html
"En 2021, c'est le trafic vidéo qui occupe la majorité de nos réseaux de télécommunications, avec cinq gros fournisseurs qui utilisent 50% de notre trafic"
Rapport Arcep repris par https://www.usine-digitale.fr/article/la-video-a-represente-plus-de-la-moitie-du-trafic-internet-en-france-en-2021.N2021922
54% pour Sandvine https://www.latribune.fr/technos-medias/telecoms/la-video-cet-ogre-du-trafic-internet-923839.html
84% en 2020 dans le monde prédiction cisco
http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/vni-hyperconnectivity-wp.pdf
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.