Zasady kodowania mailingów
Czas czytania:
Zaczynając przygodę z kodowaniem mailingów, musimy zapomnieć o wszystkich dobrodziejstwach wprowadzonych przez ostatnie lata w HTML i CSS. Chcąc stworzyć wiadomość, która poprawnie wyświetli się na każdym kliencie poczty elektronicznej, korzystamy ze specyfikacji XHTML (rekomendacja zatwierdzona w 2010 roku). Dodatkowo ograniczeni jesteśmy w stosowaniu niektórych atrybutów. Możliwe, że odbiorcą naszej wiadomości będzie użytkownik korzystający z Outlook’a 2003.
Szkielet
Cały proces tworzenia mailingów oparty jest na tabelach i zagnieżdżaniu się w nich kolejnych tabel. Mailing powinien być zbudowany na tabelach, gdyż pozwalają one ustawić szerokość wyświetlanego obiektu bez użycia stylów. Rozpoczynając zatem kodowanie, tworzymy tabelę główną, w której zagnieżdżone będą kolejne tabele odpowiedzialne za kolejne sekcje.
<!-- Tabela wyrównania-->
<table border="0" cellpadding="0" cellspacing="0" width="100%" align="center">
<tr>
<td>
<!-- Tabela główna -->
<table border="0" cellpadding="0" cellspacing="0" width="600" align="center">
<tr>
<td>
<!-- Tabela nagłówka -->
<table border="0" cellpadding="0" cellspacing="0" width="600" align="center">
<tr>
<td>
<!-- Tabela z nawigacją -->
<table border="0" cellpadding="0" cellspacing="0" width="600" align="center">
<tr>
<td>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td>
<!-- Tabela z wiadomością -->
<table border="0" cellpadding="0" cellspacing="0" width="600" align="center">
<tr>
<td>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
Ograniczenia
Odstępy i wypełnienia
Chcąc wykonać odstęp między wierszami, musimy wstawić dodatkowy, pusty wiersz ze zdefiniowaną wysokością. Komórka powinna zawierać dodatkowo niełamiącą się spację i kilka atrybutów zwiększające kompatybilność.
Powodem jest Outlook 2007/10/13, który nie wspiera atrybutów padding i margin. Dla przykładu posłużymy się widokiem ze strony.
<table border="0" cellpadding="0" cellspacing="0" width="485">
<tr>
<td>
Potrzebujesz programisty front-end do projektu?
</td>
</tr>
<tr>
<td height="50" style="margin: 0; padding: 0; font-size: 0;"> </td>
</tr>
<tr>
<td>Wynajmij zespół lub jednego programistę do swojego projektu. Zbudujemy dla Ciebie interfejs o dowolnym poziomie złożoności.</td>
</tr>
</table>
Skróty atrybutów
Definiując atrybut style=”” nie możemy stosować skrótów CSS.
Przykład: Chcąc dodać obramowanie, musimy zadeklarować border dla każdego boku.
<td style="border-left: 1px solid #FFFFFF; border-right: : 1px solid #FFFFFF; border-top: : 1px solid #FFFFFF; border-bottom: : 1px solid #FFFFFF;">
</td>
Modyfikowanie czcionek
Każda komórka zawierająca treść musi zawierać całą deklarację stylu dla topografii. Dodatkowo definiowanie koloru odbywa się wyłącznie przez HEX pisany wielkimi litery.
<td style="font-size: 18px; color: #F5E1E9; font-weight: bold; font-style: italic;">Hello</td>
Niestandardowe czcionki
Jedynie kilka klientów obsługuje deklarację @font-face, więc używanie niestandardowych czcionek będzie miało ograniczoną kompatybilność. Najbezpieczniej korzystać z bezpiecznych czcionek (domyślne zainstalowanych czcionek na większości systemów operacyjnych) podczas ustalania stylu topografii. Kompletną listę można znaleźć na stronie cssfontstack.com.
Jeśli zajdzie potrzeba użycia niestandardowych czcionek zadeklarujmy ich kilka formatów dla większej kompatybilności, oraz dodajmy odpowiednie atrybuty dla tagu <body> poprawiając ich renderowanie.
@font-face {
font-family: 'NotoSans';
src: url('fonts/notosans-regular-webfont.eot');
src: url('fonts/notosans-regular-webfont.eot?#iefix') format('embedded-opentype'),
url("'fonts/notosans-regular-webfont.woff2') format('woff2'),
url('fonts/notosans-regular-webfont.woff') format('woff'),
url('fonts/notosans-regular-webfont.ttf') format('truetype'),
url('fonts/notosans-regular-webfont.svg#'NotoSans', Arial, Helvetica, sans-serif') format('svg');
font-weight: normal;
font-style: normal;
}
body {
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
text-rendering: optimizeLegibility;
font-family: 'NotoSans', Arial, Helvetica, sans-serif;
font-weight: normal;
}
<td align="left" style="font-size:11px; text-decoration: none; color:#FFFFFF; font-family: 'NotoSans', Arial, Helvetica, sans-serif; font-weight: normal;" width="280">
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin vulputate interdum ullamcorper.
</td>
Stosowanie grafik
Można pomyśleć, że najłatwiej stworzyć e-mail tworząc go jedynie z obrazka. Rzeczywistość jednak inaczej weryfikuje naszą pomysłowość. Klient poczty może domyślnie mieć włączoną opcję do niewyświetlania grafik. Główny powód są zabezpieczenia przed pobraniem plików mogących wykorzystać luki w systemie. Użytkownikowi w takim wypadku zostanie wyświetlona wiadomość składająca się z pustego pliku graficznego.
Pamiętajmy, że tylko najpotrzebniejsze elementy niedające się zakodować przez HTML wyświetlamy za pomocą tagu <img>. Dodatkowo upewnijmy się, że każda grafika posiada podstawowe atrybut takie jak: alt, width, height, border i display:block. Tworzymy plik HTML zgodny ze specyfikacją XHTML, więc niezbędne będzie zamknięcie tagu <img> ukośnikiem
<img alt="Logo" border="0" width="46" height="46" style="display: block;" src="logo.jpg" />
Grafika w tle
Atrybut background-image nie jest wspierany w Outlook’u (dla każdej wersji). Sprawia to wiele trudności i zmusza do podjęcia kompromisu. Obejściem tego problemu jest przycięcie grafiki i stworzenie czterech mniejszych grafik, które będą otaczać tekst. Oczywiście tekst będzie znajdować się na jednolitym tle, więc przygotujmy do tego odpowiedni widok. Pamiętajmy o wyliczeniu na sztywno szerokości i długości dla wszystkich elementów, aby wynik był pozytywny.
Typowe problemy
- line-height
Jeśli istnieje możliwość stworzenia obejścia dla tego atrybutu, lepiej go zastosować. Line-height rządzi się swoimi prawami w różnych klientach pocztowych, które mogą całkowicie zepsuć wygląd całego wiersza w tabeli.
- cellpadding/cellspacing
Najbezpieczniej nie posługiwać się atrybutami cellpadding i cellspacing. Pozostawiając je zdefiniowane w tabeli na 0, zwiększamy kompatybilność dla każdego klienta poczty.
- tworzenie łącza
Każde łącze powinno zawierać atrybut target=”_blank”. Łącze nie może zawierać elementów tabeli (<tr>/<td>), ponieważ nie są zgodne ze specyfikacją W3C.
- rozwiązywanie innych problemów
Częstym powodem występowania błędów są problemy walidacji HTML. Kopiując plik HTML do walidatora W3C, zmniejszamy prawdopodobieństwo występowania niepożądanych efektów w wyświetlaniu wiadomości.
Testowanie
Po zakodowaniu mailingu nadszedł czas na drugi etap – testowanie. Wysyłamy wiadomość do różnych klientów pocztowych i sprawdzamy, czy nie pojawiają się błędy w ich wyświetlaniu. Jest to monotonny proces, bo każda poprawka niesie za sobą ponowne testy. Warto sprawdzić nasz mailing na takich klientach jak:
- Outlook 2003
- Outlook 2010
- Outlook 2013
- iPad
- iPhone Gmail
- iPhone Mail
- AOL
- outlook.com
- Yahoo!
- Apple Mail
- Thunderbird
- Android Gmail
- Gmail Web
Testy zmniejszają ryzyko błędnego wyświetlenia się wiadomość na kliencie pocztowym użytkownika.
Podsumowanie
Przed przystąpieniem do tworzenia mailingów musimy poznać zasady ich kodowania. Nie chroni nas to jednak przed występowaniem błędów. Ciągłe testowanie widoku wiadomości w różnych klientach pocztowych jest jedynym rozwiązaniem, aby stworzyć wiadomość kompatybilną ze zdecydowaną większością klientów pocztowych.
Może Cię również zainteresować:
Co wyróżnia profesjonalne wdrożenie serwisu bazującego na WordPress?
Post pochodzi z naszych kanałów w Social Media. — Nasi klienci często pytają, czym różnią… Read More
Czy warto decydować się na usługę wdrożenia WooCommerce i na czym ona polega?
Wtyczka do WordPressa WooCommerce wydaje się być prostym sposobem na stworzenie sklepu internetowego. Wystarczy instalacja,… Read More