Was sind die richtigen Vorgehensweisen beim Entwerfen einer E-Mail mit der begründeten Erwartung, dass sie für Outlook 2003, 2007 und in einem Webmail-Client korrekt angezeigt wird? Ich habe verschiedene E-Mail-Newsletter abonniert und habe die Quelle auf ihnen angesehen und einige von ihnen haben 2000 Zeilen HTML & amp; CSS zusammen mit IF-Anweisungen, die ich nie zuvor gesehen habe (ich nehme an, bezogen auf die Festlegung von Outlook-Versionen) / p>
Gibt es ein kostenloses oder kommerzielles Tool, mit dem das Markup erstellt werden kann? Gibt es ein Standardmuster für die Anwendung dieser riesigen Stylesheets, die ich gesehen habe?
Ich würde ein Präprozessor-basiertes Framework wie Foundation for Emails empfehlen.
Oy. Solche schrecklichen Antworten.
Siehe? Dies geschieht, wenn jeder entscheidet, dass die Verwendung von Tabellen anstelle von CSS eine Art Tabu ist. Jeder begrenzt sich mit solcher CSS Arroganz und Elitismus. Wenn alles ein Hammer ist, sieht alles wie ein Nagel aus. Unglaublich.
Ein Plakat schrieb: "Das war mein Ausgangspunkt und selbst das ist nicht zuverlässig, selbst eine einfache einzelne Spalte Tabelle mit einer festen Breite wird durcheinander gebracht, wo die Tabellenzellen ohne Grund über die Breite hinaus expandieren."
Die feste Breite hat dich in Schwierigkeiten gebracht. Eine 600-Pixel-Tabelle mit fester Breite ist offensichtlich breiter als ein 400-Pixel-E-Mail-Betrachtungsfenster / -bereich. Es erweitert sich nicht weiter, es ist IS breiter. [Sheesh]
Es kann nicht vorhergesagt werden, wie groß das E-Mail-Anzeigefenster / der E-Mail-Bereich des Empfängers sein wird. Erstellen Sie also eine einzelne Tabelle, aber setzen Sie die Breite auf 100%, nicht auf eine bestimmte Anzahl von Pixeln. Und setze seine Höhe auf "auto". Machen Sie seine Polsterung schön und breit ... 7 bis 10 Pixel, Minimum.
Dann tun Sie einfach alles innerhalb dieser Tabelle, wie Sie normalerweise würden, aber bleiben Sie mit Vanille HTML4, XHTML vermeiden, DHTML, XML, Java, Javascript, etc., nur HTML4. Kein CSS, auch nicht. Nur HTML4. Zeitraum.
Verwenden Sie Bilder, die sich auf einem Webserver befinden und mit normalen http: // URLs verknüpft werden können, und verknüpfen Sie sie dann mit normalen IMG-Tags, indem Sie die gesamte URL des Bildes (einschließlich http: // Teil) zwischen den Anführungszeichen, wie in ...
src="http://www.website_url.com/filename.jpg" (oder .gif oder was auch immer)
... und vermeiden Sie die Verwendung der "alt" -Funktion oder etwas Besonderes.
Wenn Sie die Schriftgröße streng kontrollieren möchten, zögern Sie nicht, das "span" -Tag zu verwenden, da es in fast jedem E-Mail-Client funktioniert ... einfach nicht zu schick damit.
Machen Sie Ihre Bilder auch nicht zu groß ... besonders, machen Sie nicht das, was der "Header" oder das obere Bild zu weit ist. Die Einstellung der Tischbreite auf auto wird nicht viel helfen, wenn die Grafik 600 Pixel breit bleibt und der E-Mail-Viewer des Empfängers 400 Pixel breit ist. Verwenden Sie eine Grafik, die sich gut in der oberen linken Ecke der E-Mail-Nachricht einfügt. und verwende ziemlich kleine Fotos und andere Grafiken.
Machen Sie das alles und Sie sollten feststellen, dass die E-Mail in fast jedem E-Mail-Client gleich aussieht. Überprüfen Sie mit ...
... als ein weiteres Poster hier vorgeschlagen.
Ich hoffe, das hilft.
Es gibt definitiv einige Best Practices bei der Erstellung einigermaßen client-kompatibler E-Mails.
2 der wichtigsten Konzepte zu erinnern sind:
Verwenden Sie nur Inline-CSS. Dies wird Ihnen viele Kopfschmerzen ersparen, da Gmail und viele andere E-Mail-Clients daran scheitern, CSS in einem & lt; style & gt; Tag.
Wie viele Leute schon gesagt haben, sind Tabellen der richtige Weg für Dimensionierungselemente (anstelle von CSS).
Ich habe gerade Post mit einigen Best Practices zu diesem Thema geschrieben, wenn Sie interessiert sind:
Es ist extrem schwierig, E-Mails zu erstellen, die auf allen Clients funktionieren, da sie unterschiedliche Rendering-Engines aus Webbrowsern verwenden, in denen das Design wahrscheinlich entwickelt wurde. Versuchen Sie es mit dem E-Mail-Testservice von LitmusApp, der Screenshots zeigt, wie Ihre E-Mails in verschiedenen E-Mail-Clients angezeigt werden.
HTML kann aus drei Gründen nicht erfolgreich in E-Mails implementiert werden.
1) HTML funktioniert nur für das HTTP-Protokoll (Web) und nicht für das SMTP-Protokoll (E-Mail). Dies wird deutlich, indem der Kopf eines HTML-Dokuments Daten liefert, die für die Verarbeitung des Dokuments gemäß einer Übertragung über HTTP relevant sind. Da HTML die vom SMTP-Protokoll gelieferten Bedingungen nicht erfüllt, ist es auf seinem Gesicht kompatibel. Seit dieser Zeit gibt es keinen Standard mehr, um das Format von Inhalten in E-Mails zu beschreiben.
2) HTML ist keine Präsentationssprache. HTML soll dem Inhalt strukturierte Metadaten liefern und ist niemals für die Präsentation gedacht. HTML wird nur in E-Mails zur Präsentation verwendet und wird daher oft missbraucht und in völliger Verletzung der Standards verwendet.
3) Ein einzelnes Dokument in E-Mail kann mehrere Autoren mit jeweils unabhängigen Header-Informationen haben. Ein solches Dokument wird als E-Mail-Thread bezeichnet. HTML hat keine solche Konvention. Wenn HTML in E-Mails bereitgestellt wird, kann es für den ursprünglichen Benutzer, der es empfängt, gut aussehen, aber wenn es geantwortet oder weitergeleitet wird, wird es wie Mist aussehen und seine Aufgabe nicht erfüllen, was wahrscheinlich sowieso nicht der Fall ist. Nach meinem Wissen ist Mail Markup Language die einzige Markup-Sprache, die Funktionen enthält, um mehrere Autorenbeiträge zu einem einzelnen Markup-Language-Dokument ohne Konflikte zu adressieren und zu liefern, wie es notwendig ist, um einen E-Mail-Thread genau zu unterstützen.
Aus diesen drei Gründen ist HTML völlig inkompatibel mit E-Mails und kann nicht erfolgreich sein.