Accéder au contenu.
Menu Sympa

technique - Re: [TECH] [April] [ABUL/tech] version kmail, kde et kde applications

Objet : Liste pour les discussions techniques (liste à inscription publique)

Archives de la liste

Re: [TECH] [April] [ABUL/tech] version kmail, kde et kde applications


Chronologique Discussions 
  • From: Nicolas VINOT <nvinot AT april.org>
  • To: "patrick.agelinux" <patrick.agelinux AT free.fr>
  • Cc: april AT april.org, tech AT abul.org, technique AT april.org
  • Subject: Re: [TECH] [April] [ABUL/tech] version kmail, kde et kde applications
  • Date: Sun, 04 Dec 2016 12:16:36 +0100
> J'utilise kmail depuis quelques années.
> Lorsque le message est en HTML, il devrait y avoir une partie texte lisible,
> ne serait-ce pour tenir compte de la compatibilité des messages avec les
> anciens lecteurs de courrier, et pour faciliter l'accessibilité.

Cette possibilité ne dépend que de l’émetteur.
S’il ne souhaite pas mettre de partie texte, il peut le faire.

Après, les émetteurs de listes de diffusion type spam^W commerciale prennent
rarement le temps de rédiger correctement leurs mails :
* corps HTML dupliqué dans le corps text/plain
* contenu HTML dans corps text/plain et pas de corps HTML
* corps HTML avec un corps text/plain vide
* etc
Selon la sensibilité du client mail du lecteur, le contenu peut être atroce à
lire. Pour les exemples précédent, un courrieleur respectant le format MIME
devrait afficher :
* 1 & 2 : du code HTML
* 3 : un courriel vide
Certains courrielleurs cherchent à s’écarter du format officiel en cas de
problème pour tout de même afficher un rendu correct au lecteur malgré le non-
respect du standard MIME par l’émetteur. C’est par exemple le cas de KMail
qui
cherchera à interpréter un contenu HTML dans un corps plain/text ou qui
affichera le contenu HTML s’il n’y a pas de corps plain/text même si l’option
est désactivée.

> Dans le cas que j'ai rencontré, il n'y a pas cet encadré, et donc :
> - ni message texte alternatif
> - ni lien de kmail pouvant afficher le code interprété.

A priori, l’émetteur n’a donc juste pas respecté le format MIME et envoyé
plus
ou moins n’importe quoi (ici je dirais un contenu HTML dans un unique corps
text/plain…).

> Pour ce second point de mon message original, je souhaite confirmation
> - qu'il y a bien eu confusion entre KDE base (qui en est à la version 5) et
> KDE Applications (qui en est à la version 16), ne sachant toutefois si
> Kmail fait partie de KDE Applications, ni dans ce cas si Kmail ne serait
> effectivement pas daté

KMail a subit une lourde refonte avec KDE 5, en particulier sur le composant
d’analyse des mails MIME HTML + plain/text.
Mais la version 4 fonctionnait déjà plutôt correctement là-dessus, il s’agit
plus d’amélioration d’ergonomie que d’une réelle réécriture du moteur de
rendu.

> - que la version stable de Debian permet
> de lire tout courrier suivant les RFC concernant les courriels

C’est surtout le courrielleur qui va faire ce travail plus ou moins
correctement. Sous Debian stable, Thunderbird n’aura pas du tout le même
comportement que KMail qui implémente de manière plus fine la RFC 2045.

> Eventuellement, j'aimerais avoir une idée précise des causes techniques
> ayant pu causer ce défaut d'affichage, permettant d'incriminer un défaut de
> lecture de kmail ou un défaut de codage du message.

Le support des mails HTML est une véritable horreur, c’est un peu un reste
des
problèmes de compatibilité d’Internet Explorer 6…
Il n’y a pas réellement de format HTML standard, et le support du mail est à
des années lumières du support d’une page web. Les moteurs de rendu sont
moins
bons et complets que leurs équivalents pour un navigateur.
Par exemple on en est encore à devoir utiliser des tableaux <table> pour la
mise-en-page car le support du CSS et des <div> y est généralement mauvais
voire inexistants.
Il se pose aussi le problème des webmail, qui revient à lire un mail HTML
dans
une page HTML, et donc à devoir supprimer des morceaux du contenu HTML pour
l’afficher sans problème (suppression du <head>/<body>, donc disparition du
CSS du <head>, seuls les styles en ligne resteront) ou à rencontrer des
conflits entre le CSS de la page web et celui du mail.
Si tu appliques toutes les bonnes pratiques HTML/CSS et que tu codes une page
HTML5 responsive 100% valide HTML/CSS, il y a de fortes chances que tu
obtiennes un résultat plus qu’horrible si tu l’envoies par mail.
En bref, rédiger un mail commercial en HTML est un véritable enfer que seuls
les grosses régies de newsletter savent faire proprement (mailchimp, mailjet
&
cie).

Librement,
--
Nicolas VINOT
Groupe crypto-terroriste individuel auto-radicalisé sur l’Internet digital
https://imirhil.fr/

Protégez votre vie privée, chiffrez vos communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

Attachment: signature.asc
Description: This is a digitally signed message part.


Archives gérées par MHonArc 2.6.19+.

Haut de le page