Hallo,
Zitat von "n00bert"Es geht auch nicht darum es jeden recht zu machen, sondern zu schaun was für Thunderbird möglich ist.
IMHO geht es genau darum nicht. Denn solche Ansätze führen einfach dazu, dass man unendlich viele Funktionen in ein einziges Programm presst, in der Hoffnung eine eierlegende Wollmilchsau zu schaffen, die alle nur denkbaren Anforderungen erfüllt.
Das ist aus meiner SIcht in mindestens zweierlei Hinsicht problematisch:
1. Um eine Mail zu schreiben, muss ich mir etliche Megabyte an Programmcoding auf die Platte hauen. Ja, Platten kosten heute nicht mehr die Welt, bleibt aber aus meiner Sicht trotzdem ein Nachteil. Viele Benutzer benötigen außerdem diese Funktionen nicht und schleppen somit unnötigen Balast in ihren Softwareinstallationen mit. *Ich* habe mich irgendwann z.B. für TB entschieden, weil ich eigentlich hoffte, dass zusätzliche Funktionen vor allem über die AddOns implementiert werden sollten. Ich hätte also ein schlankes Core-Programm, dass ich dann nach meinen Bedürfnissen aufbohren kann. Jede Programmzeile mehr erhöht außerdem die Gefahr einer Sicherheitslücke.
2. Sollte dann irgendwo in der Anwendung ein Fehler auftauchen, wird die Fehlersuche aufwendig. Man merkt es immer wieder an dem Zusammenspiel verschiedener AddOns, dass nicht alle Funktionen zueinander kompatibel sind. Je komplexer ein Programm wird, desto größer ist die Gefahr solche Inkompatibiltäten einzubauen. AddOns kann ich ausschalten, im Core eingebaute Funktionalität nicht (oder nur mit größerem Aufwand).
Außerdem möchte ich wiederholen, dass Thunderbird weder ein Programm zur Gestaltung von Dokumenten noch ein Dokumentenverwaltungssystem ist. Eigentlich. HTML als Seitenbeschreibungssprache ist nun eben nicht dafür gedacht, versandt zu werden, sondern um Webseiten optisch möglichst passend zu gestalten. Die Diskussion sit so alt wie HTML-Mails, aber bis heute scheint es für viele Leute schwer zu sein, zu verstehen, dass eMail als Medium der Informationsweitergabe dient. Punkt. Eine Information (also der Inhalt) wird aber nicht dadurch besser oder schlechter, dass sie in blau statt in rot oder schwarz übertragen wird.
Die unvollständige oder zumindest unübersichtliche Darstellung der gesendeten Information im Ziel-Client ist allerdings ein No-Go. Und da ich niemandem vorschreiben kann, welchen Client er benutzt, werde ich, sofern ich an der korrekten Rezeption der durch mich versandten Information interessiert bin, werde ich doch den kleinsten gemeinsamen Nenner für den Versand meiner Mails nutzen. Und das ist nach wie vor (Rein-)Text. Ich will hier gar nicht mit Spezialfällen wie z.B. Nutzung von Hilfsmitteln (Screenreader für Blinde z.B.) anfangen.
Für mich habe ich außerdem festgestellt, dass ich Reintextmails wesentlich effektiver verarbeiten kann - sowohl beim eigentlichen Lesen als auch in der Weiterverarbeitung (copy in andere Anwendungen [Quellcode]).
Insgesamt gesehen ist für mich HTML-Mail also eine ähnliche Verfehlung wie mit dem Auto zum eigenen Briefkasten zu fahren. Es ist schlicht überflüssig, kostet unnötig Ressourcen und schafft ebenso unnötig Inkompatibilitäten.
Bisher habe ich noch kein einziges Argument vernommen, das die Anwendung von HTML in eMails zwingend erfordert. Ich bin ja durchaus lernfähig, kann auch ToFu (Standard auch in meinem beruflichen Umfeld) und weiß, dass grafisch gut und aufwendig gestaltete Dokumente (!) anders auf Menschen wirken als eMails in Reintext. Nur unterscheide ich hier eben zwischen der Form und dem Inhalt. Letzterer kommt perfekt ohne Hintergrundbildchen und sogar ohne Tabellen aus. Dafür gibt es nämlich entsprechende Schiftarten und die Tabulatortaste.
Und ich habe sogar begriffen, dass ich damit gegen die berühmten Windmühlen kämpfe. Das ändert aber immer noch nichts an der Tatsache, dass es IMHO keinen einzigen Grund gibt, HTML in Mails einzusetzen.
Kennst Du einen?
Gruß
Dirk