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.
Yth, qui ne voit pas plus le lien avec le base64...
[^] # Re: vraiment?
Posté par Yth (Mastodon) . En réponse au journal "Use plaintext email" ? Vraiment ?. É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.