![](https://habrastorage.org/files/d33/1fc/6e5/d331fc6e5fdc42b2a6044286b1712dcf.png)
В блоге Печкина на Хабре мы много пишем об интересных техниках работы с email-рассылками. Ранее мы рассматривали распространенные ошибки при создании форм в почтовых письмах, а сегодня представляем вашему внимани адаптированный перевод заметки итальянского дизайнера Массимо Кассандро, который решил выяснить, стоит ли вообще применять этот инструмент в верстке email-cообщений.
Зачем это может быть нужно
Сам Кассандро говорит, что не считает использование форм в email хорошей практикой — пользователям все равно придется переходить на веб-страницу, так что никакого удобства в плане юзабилити это не даст. Вдобавок, теряется возможность осуществления валидации на клиенте, поскольку ограничения JavaScript и HTML5 неконсистентны.
Иногда могут существовать юзкейсы, при которых форма в письме появляется в качестве опции — например, для стимулирования немедленного взаимодействия с пользователями (возможно, нужно попросить его комментарий). В таких случаях простой ссылкой на внешнюю страницу отделаться не удастся.
Возможно, вы встречали в письмах что-то типа этого:
![](https://habrastorage.org/files/14d/aed/812/14daed812f254b47813545028abab08e.png)
Реализовать это проще всего, добавив ссылку с переменной для записи выбора пользователя на каждый смайл.
Но что, если нужно реализовать что-то похожее на это:
![](https://habrastorage.org/files/8a9/086/8ab/8a90868ab046426fbe48ac940203deea.png)
Очевидно, что использовать уникальную ссылку для сохранения информации об оценке и комментария одновременно не получится. Поэтому, чтобы не посылать пользователей на внешнюю веб-страницу, в письмо нужно добавить форму.
К сожалению, в сети не так уж и много информации о том, в каких почтовых программах будут поддерживаться формы. Есть пара старых статей на английском (раз и два), а на русском найти что-либо вообще крайне сложно. По большому счету, со времени написания тех материалов ситуация не особенно изменилась, но будет не лишним получить представление о том, как дело обстоит сейчас.
Форма
Массимо Кассандро решил провести эксперимент, создав простую форму, которая содержит несколько элементов:
- Поле ввода текста;
- Две радиокнопки;
- Чекбокс;
- Элемент Select;
- Зону с текстом.
Для каждого из них было установлено дефолтное значение, кроме того у поля ввода текста был атрибут required.
Тест проводился для доктайпов HTML5 и XHTML 1 strict. Обе версии прошли через валидатор W3C. Ниже представлен использовавшийся код:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Email form test</title>
</head>
<body>
<h1>Email form test</h1>
<form id="form1" action="result_page.html" method="get">
<div style="margin-bottom:10px">
<label for="text">Text field</label><br>
<input required type="text" id="text" name="text" value="Some text">
</div>
<div style="margin-bottom:10px">
<input type="radio" id="radio1" name="radio" value="radio 1 value" checked>
<label for="radio1">Radio button 1</label><br>
<input type="radio" id="radio2" name="radio" value="radio 2 value">
<label for="radio2">Radio button 2</label>
</div>
<div style="margin-bottom:10px">
<input type="checkbox" id="checkbox" name="checkbox" value="checkbox value" checked>
<label for="checkbox">Checkbox</label>
</div>
<div style="margin-bottom:10px">
<label for="select">Select</label><br>
<select id="select" name="select">
<option value="select option 1">Select option 1</option>
<option value="select option 2" selected>Select option 2</option>
<option value="select option 3">Select option 3</option>
</select>
</div>
<div style="margin-bottom:10px">
<label for="textarea">Textarea</label><br>
<textarea cols="60" rows="5" name="textarea" id="textarea">More text</textarea>
</div>
<div>
<button type="submit" name="Submit">Submit</button>
</div>
</form>
</body>
</html>
Вот так это все выглядит в Chrome для Mac:
![](https://habrastorage.org/files/5d4/4b2/f14/5d44b2f14f1148f0a2a45d32b52c5018.png)
XHTML-версия практически не отличается от представленного выше.
Участвующие клиенты
Обе версии формы проверены на следующих почтовых программах:
Десктоп:
- Apple Mail (v.8.2)
- Thunderbird (OSX, v.31.4)
- Windows Live Mail 2012 (Windows 7)
- Outlook 2013 (Windows 7
Мобайл:
- iPad Mail (IOS 8.2)
- Gmail App on iPad
- Yahoo Mail on iPad
- Outlook for IOS
- Gmail App on Android (v.5.0.1)
- Native E-Mail App on Android 4.4.4
- Yahoo Mail on Android (v.4.8.4)
- Gmail Inbox Android (v.1.2)
Веб:
- Gmail
- Yahoo Mail
- Outlook.com
Веб-клиенты тестировались в браузере Firefox 35 для OSX.
Результаты
Прежде всего, стоит отметить, что смена доктайпа никак не повлияла на результаты. Все протестированные клиенты корректно отобразили форму.
Исключением стал лишь Outlook для Windows и iOS. В случае этой программы форма не срендерилась ни на Outlook 2013/Win7 ни на iOS. Элементы формы были либо полностью вырезаны (iOS), либо показаны плейнтекстом (Outlook 2013):
![](https://habrastorage.org/files/183/42a/d28/18342ad28ef04283850b5f47aec827ab.png)
На Outlook.com форма корректно отобразилась, но отправить введенные данные было нельзя.
Возможно вы знаете о том, что Outlook Desktop используется в качестве движка рендеринга HTML Microsoft Word, что многое объясняет. Word разработан для создания документов, а не отображения веб-форм. С чего в Microsoft решили, что использовать его для создания email будет отличной идеей — отдельный вопрос.
Кассандро не имел прямого доступа к другим версиям Outlook, но тесты проведенные с помощью софта Litmus, показали, что результат в их случае был бы примерно таким же.
Более старые версии Outlook, которые использовали движок рендеринга Trident из Internet Explorer, и Outlook 2011 For Mac (использует WebKit) отображают форму корректно, но остается вопрос о возможности отправки данных.
Часто почтовые программы отображали алерт, предупреждающий получателя письма о том, что он отправляет данные на внешний сайт. С точки зрения безопасности, не самое плохое решение. Вот так алерт выглядел в веб-клиенте Gmail:
![](https://habrastorage.org/files/ecb/fc2/ec4/ecbfc2ec476b411ea222be90e7717307.png)
Интересный момент — атрибут required был проигнорирован почти всеми email-клиентами. Исключением стали лишь Thunderbird — подсветил помеченные атрибутом поля, но отправить форму можно было и без их заполнения — и Opera Mail — тут поведение было похоже на браузер, с отображением сообщения об ошибке и невозможностью отправки.
![](https://habrastorage.org/files/6be/142/654/6be1426546aa4b30b77e5d39c3079ee3.png)
К слову, Opera Mail оказался одним из самых быстрых и простых в использовании почтовых клиентов.
Также выяснилось, что Yahoo Mail for iOS — единственный клиент, который отображает результат без использования внешнего браузера. Ценный навык, с точки зрения UX.
![](https://habrastorage.org/files/39c/2a4/600/39c2a46007a34362be2a3a2327906d00.png)
Ниже представлена таблица с результатами эксперимента (скриншоты и код доступны в репозитории на GitHub):
Клиент | Форма отображается | Форма работает |
---|---|---|
Thunderbird 31 (OSX) | Y | Y (2) |
Apple Mail 8.2 (OSX) | Y | Y (1) |
Opera Mail 1 (OSX) | Y | Y |
Windows Live Mail 2012 (win 7) | Y | Y (1) (3) |
Outlook 2013 (Win 7) | N | N |
Outlook.com (web) | Y | N |
Yahoo Mail (web) | Y | Y (1) (3) |
GMail (web) | Y | Y (1) (3) |
GMail App (Android) | Y | Y (1) (3) (4) |
GMail Inbox (Android) | Y | Y (1) (3) (4) |
Yahoo Mail App (android) | Y | Y (1) (4) |
Android Mail (4.4.4) | Y | Y (1) (4) |
Gmail App (IOS 8.1.3) | Y | Y (1) (3) |
Apple Mail (IOS 8.1.3) | Y | Y (1) |
Outlook for IOS (IOS 8.1.3) | N | N |
Yahoo Mail for IOS | Y | Y (1) (5) |
- Атрибут required проигнорирован.
- Поля с required подсвечены в случае, если в них нет данных, но форму можно отправить.
- Возникает алерт при отправке.
- Текст в форме нельзя вводить и редактировать.
- Страница с результатами открывается внутри приложения.
Заключение
Результат эксперимента позволяет заявить о том, что использовать формы в email не стоит. Поддержка этой функциональности весьма ограничена, часто не будут работать даже самые базовые элементы.