Wiadomość HTML zostaje zbudowana, sprawdzona w przeglądarce, wysłana — i u części odbiorców dociera jako rumowisko: kolumny jedna pod drugą zamiast obok siebie, przyciski bez zaokrągleń, kroje pisma podmienione, tła obrazkowe zniknęły. Powód jest otrzeźwiający: nie istnieje standard mówiący, jak program pocztowy ma wyświetlać HTML. Każdy robi to inaczej, a niektóre bardzo inaczej.
Główny powód nazywa się Word
Pojedynczą największą przyczyną jest decyzja z 2007 roku. Outlook na Windows przeszedł wtedy z komponentu wyświetlającego Internet Explorera na silnik składu Worda.
Klasyczny Outlook wyświetla więc pocztę nie silnikiem przeglądarki, tylko tym, co edytor tekstu uważa za skład. Word zna tabele i akapity znakomicie. Nowoczesnego CSS nie zna — nie słabo, tylko wcale.
To tłumaczy niemal wszystko, co w Outlooku wygląda inaczej: brak zaokrąglonych rogów, brak teł obrazkowych przez CSS, brak zapytań o media, brak flexboksa, brak krojów z sieci, a przy obrazach ruchomych tylko pierwsza klatka.
Pozostałe różnice
Gmail w przeglądarce usuwa część tego, co stoi w nagłówku wiadomości, i nie honoruje niektórych właściwości, bo zaburzałyby układ strony — na przykład position i ujemnych marginesów. Kroje z sieci przez @font-face są usuwane.
Apple Mail korzysta z tego samego silnika co Safari i jest zdecydowanie najbardziej wyrozumiałym programem. Kto sprawdza tylko tam, błędnie uzna wiadomość za w porządku.
Thunderbird stoi blisko Firefoksa i również jest wyrozumiały, z ograniczeniami przy krojach pobieranych z sieci.
Tryb ciemny, drugie pęknięcie
Odkąd większość programów oferuje ciemną prezentację, istnieje drugie źródło niespodzianek — i jest przykrzejsze od pierwszego, bo dotyka także wiadomości dobrze zbudowanych.
Programy postępują rozmaicie. Część zostawia wiadomość nietkniętą. Część podmienia tylko barwy, które nie zostały wyraźnie ustawione. A część odwraca barwy całej wiadomości, łącznie z ustawionymi.
Powstaje z tego znajomy obraz: ciemne logo na tle, które przed chwilą było białe, a teraz jest czarne. Albo tekst, który byłby czytelny, gdyby nie odwrócono jego barwy, a barwy tła otaczającego prostokąta już nie.
Najpewniejszym przeciwdziałaniem jest rzecz nieefektowna: dać obrazom obramowanie działające w obu trybach albo dostarczać je jako PNG z przezroczystym tłem i ustawiać barwę pod spodem. I nie używać barwy tekstu czytelnej wyłącznie na jednym określonym tle.
Reguły, które z tego wynikają
- Skład na tabelach. Nie dlatego, że to eleganckie, tylko dlatego, że
<table>jest jedyną rzeczą rozumianą jednakowo przez każdy silnik — Worda włącznie. - CSS przy elemencie, nie w nagłówku. Atrybut
styleprzeżywa wszędzie. Blokstylenie wszędzie. - Jedna kolumna, najwyżej 600 pikseli szerokości. Z taką szerokością radzi sobie panel podglądu Outlooka, a na telefonie i tak jest to jedyny sensowny układ.
- Przyciski jako komórka tabeli z barwą tła, nie jako ostylowany
<a>. Odnośnik bez zaokrąglenia pozostaje odnośnikiem, przycisk bez powierzchni jest niewidoczny. - Tekst alternatywny przy każdym obrazie. Wiele programów wczytuje obrazy dopiero po zgodzie — do tego czasu tekst alternatywny jest całą wiadomością.
- Nic ważnego wyłącznie na obrazie. Jeśli wysokość rabatu stoi tylko na banerze, odbiorcy z wyłączonymi obrazami nigdy jej nie zobaczą.
- Dołącz prawdziwą wersję tekstową. Nie służy wyłącznie programom tekstowym; wchodzi też do oceny, czy wiadomość wygląda na wysyłkę.
Sprawdzać, nie liczyć na szczęście
Wyglądu nie da się wywnioskować, można go tylko obejrzeć. Droga jest nieefektowna: dla każdego programu występującego wśród odbiorców założyć adres i wysłać tam wiadomość.
Do tego właśnie przydają się adresy krótkotrwałe — jeden na program, jeden na przebieg, bez zakładania kont. Przez interfejs programistyczny da się to również zautomatyzować: utworzyć adres, wysłać tam wiadomość, pobrać odebraną część HTML i porównać ją z tym, co zostało wysłane. Tego, co program z tym zrobi, wprawdzie nie widać — ale co usunięto po drodze, jak najbardziej.