Comments 25
На самом деле это главная причина, по которой я этим занимаюсь. Верстать под 5 браузеров не так интересно, как под over40 почтовиков.
Это реально круто, что есть верстальщики, которые заморачиваются как будет выглядеть письмо в веб-клиентах. Письмо, которое откроют, посмотрят и перейдут к следующему. Но для меня, как программиста, хочется получить какой-нибудь API, например под node.js, чтобы как-то абстрагироваться от всех этих нюансов верстки и просто знать, что мои письма (а я отправляю разные отчеты, таблицы, графики) будут и красиво, и корректно отображаться на различных устройствах и в разных почтовых клиентах.

API, который бы позволил быстро сделать емейл как одностраничный сайт, как лендинг, сформированный из разных блоков: заголовок, красочный блок с картинкой, три колонки с основными вещами, блок с таблицей, блок с графиком, блок с формой сбора данных, блок со ссылками и трекингом, блок с логотипом сервиса и слоганом (что-то еще может быть?)

Может уже такое есть? Планируете ли вы такое сделать на основе своих изысканий?
Тут скорей не API, а некий сверстанный UI KIT(фреймворк если угодно), на основе которого можно будет собирать необходимые письма. Сейчас есть в таком виде моего исполнения. Если нужно нечто более заточенное под ваши нужды, велкам в личку.

Я неспроста начал эту серию статей. Ибо то, что вы ищите в принципе не существует толком. Есть Zurb Ink framework, но он ущербен и поддерживает малое количество почтовых клиентов.
Может быть и UI kit.

Я смотрел Zurb Ink и еще MUI. Была мысль написать небольшую обертку для MUI для красоты емейлов. Вроде попроще. После отпуска надо заняться.

>>Я неспроста начал эту серию статей.
А какова конечная цель? Серия статей это хорошо, но это не «взял и стал использовать». Есть ли предложения, патчи к zurb ink для устранения ущербности, внесения ваших предложений в их фреймворк?
Я в принципе на руках уже имею более чем достойный конкурент Зурбу. Ссылку на него и дал в комментарии выше. Но использовать его в лоб было бы глупым, ибо у стороннего пользователя просто нет понимания принципов верстки писем. А писать документацию к готовому решению я не хочу. Цель моих статей — донести то самое понимание для обычного верстальщика.
Вспомнил, что еще недавно видел такую штуку (собственно где и есть немного зачатков «лендинг, сформированный из разных блоков»): github.com/bevacqua/campaign
Неплохое решение, так как там уже прикручено Mandrill API.
Но шаблон ни разу не гибкий, и сверстан отвратительно, увы.
Я как раз занимаюсь не только маркетинговым шлаком, но и триггерными рассылками, о которых вы, скорее всего говорите. Будь то служебные письма или отчеты какого нибудь дэшборда с графиками и статистикой. Мне это в любом случае интересно.
Да, всякие ежедневные отчеты о количестве действий, емейлы при совершении различных действий на сайте, заполнении форм и т.п. В любое такое письмо полезно вставлять фирменную шапку, логотип и контакты техслужбы в футер.
Дело в том, что медиа квери создавало много проблем, поэтому мы от него отказались в пользу более универсального метода. Не все маил клиенты, особенно десктопные и мобильные, понимают media
Дело в том, что описанная в этой статье методика полностью адаптивна без единого медиазапроса.
я почему-то увидел медиа запросы у вас в коде, вот и пишу)) раз так — то ок
Конкретно в этой статье присутствует всего один медиазапрос, который является перестраховкой для Outlook 2011 и Apple Mail версий ранее шестой. Там медиазапросы работают.

Будучи автором статьи по верстке писем стыдно невнимательно относится к подобному материалу.
А ка же
media only screen and (max-width: 400px) {
/* причесываем верстку на малых мобильных экранах */
}
media screen and (min-width: 401px) and (max-width: 600px) {
/* причесываем верстку на средних мобильных экранах */
}
media screen and (min-width: 600px) {
.newsletter { width:600px !important; }
}


С этой конструкцией как раз инлайнер и не справляется нормально...?
А это инлайнеру и не нужно. Эти записи для тех почтовых клиентов, которые медиазапросы поддерживают. Мы делаем адаптивный шаблон без медиазапросов, но можем их использовать для финальной «прически» шаблона. Пример использования я приведу в следующих частях.
Тестировалось во всех версиях Аутлука, Бате, Яндексе, Мейле, Яху, Рамблере, Мейлбоксе, Гмейле, Спэрроу, ЭйрМейле, Яблочном Мейле, Андроид Мейле, АОЛ, МайКом, Тандерберде. Как на десктопах и вебмордах, так и на всех мобильных приложениях.
C кнопкой поскромничали, мне кажется, она не нажимается по всей площади, а для триггерных писем это важно, так как там обычно одна кнопка большая на все письмо

Как вариант можно на td указать vertical-align: middle, ну и кнпоку сделать display: inline-block c paddingами. Где padding не работают, там она будет маленькая, а где работают будет все пучком
Качество кликабельности текущей кнопки не раз тестировалось. Надо быть суперкриворуким, чтобы по ней не попасть. Если критично, можно сделать кнопку картинкой. Тогда уж точно будут все счастливы. Тем не менее замечание уместно и кнопкой я займусь, но у этого момента меньший приоритет, чем у других.
А стоит ли embed'ить картинки в html в base64? Или оставлять лучше просто ссылки на внешние ресурсы, полагась на их загрузку почтовиками? Или еще есть возможность через content id ссылаться на картинки в письме?
За content id не скажу, ибо не приходилось сталкиваться. А base64 избыточен как по мне. Бытует легенда, что за злоупотребление base64 можно улететь в спам. Да и незачем засорять письмо картинками. Это назойливо и реакция получателя может быть отрицательной. Я все картинки размещаю на внешнем ресурсе, просто прописывая к ним url. Хотя кодировать в base64, например, логотип компании или крайне смысловую картинку — нормальная практика.
Only those users with full accounts are able to leave comments. Log in, please.