Тёмная тема — не один режим отображения; это семейство поведений, специфичных для каждого клиента. Одни приложения уважают цвета, которые вы отправили, другие принудительно инвертируют их алгоритмами, которыми вы не управляете, а третьи позволяют вашему CSS явно включиться тёмными стилями. Протестировать все комбинации невозможно, и именно попытки сводят людей с ума. Здоровый подход — маленькая матрица клиентов, которую вы можете поддерживать, знание конкретных паттернов отказов и чёткое разделение: что проверяют временные ящики (что отправлено) и что могут показать только реальные клиенты (как это отображается).
Почему тёмная тема вообще ломает письма
В светлой теме HTML писем отображается примерно как написано. В тёмной поведение расходится по клиентам:
- Одни клиенты затемняют только собственный интерфейс и отображают письмо ровно как отправлено — письмо с белым фоном становится яркой плитой внутри тёмного приложения.
- Другие применяют forced dark: клиентский алгоритм переотображает ваши цвета, так что светлые фоны становятся тёмными, а текст инвертируется для читаемости. Переотображение консервативно с малыми областями цвета и может превратить брендовые цвета в мутные серые полутона.
- Немногие уважают стандартные метаданные тёмной темы и media queries, позволяющие отправить явные тёмные стили, и игнорируют их, когда тех нет.
Одно и то же письмо даёт три разных результата — поэтому «у меня на телефоне выглядит нормально» не доказывает ничего.
Постройте матрицу, которую реально вести
1. Берите клиентов из собственной аналитики, а не из генерического списка — обычно Gmail в вебе и на мобильных, Apple Mail на macOS и iOS, Outlook на Windows и в вебе. 2. Классифицируйте тёмное поведение каждой ячейки: уважает исходные цвета, принудительно инвертирует или поддерживает opt-in тёмные стили. 3. Добавляйте тип аккаунта, где он важен: Gmail в браузере санизирует CSS иначе, чем Gmail, забираемый нативным клиентом. 4. Тестируйте каждый шаблон в свете и в темноте. Светлая тема регрессирует в тот момент, когда кто-то начинает добавлять тёмные хаки. 5. Перепрогоняйте после каждого изменения шаблона и после крупных обновлений клиентов — их поведение меняется без предупреждения.
Держите матрицу в системе контроля версий рядом с шаблонами, со скриншотом в каждой ячейке. Это превращает «тёмная тема сломана» в воспроизводимый баг вместо настроения.
Что реально ломается: логотипы, картинки, контраст
- Прозрачные PNG-логотипы исчезают при forced dark: алгоритм затемняет фон, но оставляет прозрачные пиксели как есть, и тёмный логотип невидимо парит.
- Картинки с запечённым белым фоном отображаются яркими прямоугольниками, пробивающими дыры в тёмной вёрстке.
- Кнопки из картинок инвертируются непредсказуемо; кнопки из HTML и CSS выживают лучше, потому что клиенты переотображают их согласованно.
- Тонкие линии и рамки в 1px теряют контраст первыми; тонкая элегантность становится невидимой.
- QR-коды всегда должны стоять на фиксированной светлой подложке, иначе переотображение forced dark может сделать их нечитаемыми.
Стандартные меры: давать логотипам поля и скруглять углы на фиксированной светлой подложке; отправлять тёмный вариант ассета для клиентов с поддержкой opt-in; объявлять поддержку color-scheme в head, чтобы сотрудничающие клиенты знали, что вы продумали оба режима; и аудит каждой картинки на предмет поведения, когда её фон исчезает.
Что временный ящик может и не может показать
Одноразовый ящик — не зависящая от рендеринга точка наблюдения. Он принимает письмо и позволяет изучить именно то, что было отправлено: полный HTML-исходник, CSS, URL картинок и заголовки. Это отвечает на конкретный, ценный набор вопросов:
- Пережили ли метаданные тёмной темы и media queries ваш отправляющий конвейер, или шаблонизатор и процессор предотправки молча вырезали их?
- Все ли URL картинок доступны, правильно ли размерены, отдаются ли по HTTPS и разумны ли по весу?
- Есть ли текстовая альтернатива и читабельна ли она — фолбэк, который не ломается ни в одном режиме?
- Существуют ли в исходнике вообще оба варианта ассетов, светлый и тёмный?
Чего он не может — эмулировать рендеринг клиента. Ни один ящик не покажет поведение Apple Mail или переотображение Outlook; для этого нужны реальные клиенты или сервисы скриншотов на реальных движках. Эффективное разделение: проверки исходника временным ящиком на каждой сборке — workflow описан в статье временная почта для тестирования шаблонов писем — и полная матрица клиентов по расписанию и перед релизами.
Быстрая проверка перед прогоном матрицы
1. [Создайте временный ящик](/) и отправьте кандидат-шаблон на него через реальный отправляющий конвейер, а не через локальный предпросмотр, чтобы предобработка была включена. 2. Заберите сырой HTML и убедитесь, что метаданные тёмной темы, media queries и оба варианта ассетов на месте. Если чего-то нет, сравните с исходником шаблона; а когда подозреваете, что отправляющая сторона испортила больше, чем стили, анализатор заголовков писем покажет, что произошло в пути. 3. Проверьте каждый URL картинки: статус, content type, размеры, вес. Чините сломанное до того, как тратить время матрицы клиентов. 4. Затем гоняйте матрицу и снимайте скриншот каждой ячейки в свете и в темноте.
Подготовка ящиков и получение исходника по API делает это проверкой на каждое развёртывание; см. статью автоматизация тестирования писем через API, а вызовы сначала отрепетируйте в песочнице API.
Частые вопросы
Можно ли полностью автоматизировать тестирование тёмной темы? Частично. Проверки уровня исходника — метаданные на месте, картинки валидны, текстовая версия существует — автоматизируются хорошо одноразовым ящиком. Финальный рендеринг требует реальных движков, поэтому автоматизируйте его скриншот-инструментами на реальных или виртуальных устройствах, запуская по расписанию, а не на каждый коммит.
Уважают ли почтовые клиенты prefers-color-scheme? Неравномерно. Одни клиенты поддерживают этот media query в хостинговых или встроенных контекстах, другие вырезают блоки стилей целиком, а веб-почта отличается от нативных приложений. Считайте поддержку индивидуальной для каждого клиента, проверяйте её в своей матрице и держите дизайн, безопасно деградирующий, когда запрос игнорируется.
Мой логотип нормально выглядит в Gmail, но исчезает в тёмной теме Outlook. Почему? Классическая принудительная инверсия: Outlook затемняет фон, но оставляет прозрачные пиксели нетронутыми, и тёмный логотип на прозрачности исчезает. Посадите логотип на светлую подложку с полями и скруглением или отправляйте тёмный вариант ассета там, где клиент его поддерживает.
Существует ли один дизайн, который работает везде? Почти: светлая, высококонтрастная вёрстка с фиксированным фоном, картинки на светлых подложках, кнопки из HTML и CSS вместо картинок и метаданные тёмной темы как прогрессивное улучшение. Она не будет идеально тёмной везде, но останется читаемой везде.
Итог
Тестирование тёмной темы остаётся здравым, когда вы делите проблему: проверяйте отправленное одноразовыми ящиками на каждой сборке, а отображение у клиентов — маленькой версионируемой матрицей по расписанию. Закрывайте сначала логотипы и картинки — именно там тёмная тема реально ломает вещи — и всегда тестируйте светлую тему рядом с тёмной, потому что хаки для одной и ломают другую.