Comments 104
Первое правило верстки писем в HTML — не пишите письма в HTML.
честно говоря, сам никогда в жизни не писал :) (поэтому и возникло столько неожиданных трудностей)
а вот для корпоративной рассылки — понадобилось
а вот для корпоративной рассылки — понадобилось
Речь идет не об обычных письмах, а о «рассылках». Такой «спам» подразумевает картинки и более-менее оформленный текст.
когда-то пришлось по требованию заказчика отправлять письмо с подтверждением заказа в виде красиво оформленного HTML письма с картинками. намучался я тогда очень много, пока не добился адекватного отображения этого письма в почтовых клиентах и в вебовых почтовых ящиках.
желание заказчика — закон
желание заказчика — закон
А если заказчик пожелает рассылать по почте файло по 100 мегабайт? Тоже под козырек возьмете, или все же обнаружите в себе специалиста, и попробуете разъяснить заказчику, в чем именно он не прав?
Года через четыре эта фраза будет звучать так же, как сейчас прозвучала бы «а может вы в письме историю переписки не удаляете и еще аттачи по 500 кБ прикладываете? „
У меня заказчик рассылает по 5-6 тыс. писем, в каждое письмо кладет картиночку в жпеге весом 200 — 300 кб (подсчитать объем трафика можете?), а в картиночках почти сплошной текст.
Я им уже 150 раз говорил, чтоб делали картиночку в гифе, не а, не понимают :(
ЗЫ. спамом не занимаюсь. все по подписке.
Я им уже 150 раз говорил, чтоб делали картиночку в гифе, не а, не понимают :(
ЗЫ. спамом не занимаюсь. все по подписке.
Вы пробовали? В RFC на относительные URL`ы говорится ясно: для multipart/* частей базовый URL — это сам контейнер, т.е. //host/path в них работать не должен. Только с указанием схемы. А Болк писал про https:/http: URLы.
P.S. Впрочем, в рассылках, ориентированных на web-мэйлы, это, возможно, сработает. Но идея вставлять ссылки на картинок вместо самих картинок — плоха.
P.S. Впрочем, в рассылках, ориентированных на web-мэйлы, это, возможно, сработает. Но идея вставлять ссылки на картинок вместо самих картинок — плоха.
Почему?
11) Если делаете письмо в HTML, то обязательно(!!!) шлите вместе с ним письмо в тексте.
о ужас. оказывается, когда я верстал письмо для рассылки в хтмл, я сделал почти все неправильно. хотя при этом письмо корректно отображалось в аутлуке.
по поводу 3 пункта — вообще-то в былые времена в правую и левую колонки вставлялись 1-пиксельные прозрачные гифы, а ширина (или высота) изображения делалась равной 10, иначе все и так сбивалось обычно (как в пункте 4).
На счёт картинок в письме. Как известно они часто режутся почтовиком (если ссылки внешние), а без них письмо обычно очень страшное. Так что их лучше кодировать в base64 и отправлять в самом письме. В таком случае они нормально открываются. Только это большой гемморой.
Виидел спорный, но интересный вариант решения этой проблемы. На серверной стороне по запросу к скрипту генерится картинка. Всё письмо соответственно представляет из себя одну эту картинку и ссылк в духе «Нажмите, если письмо отображается некорректно». Главный плюс в том, что можно не заморачиваться с вёрсткой и с помощью графической библиотеки скриптом на сервере накидать поверх картинки-шаблона текст. Кстати, ссылки можно делать как map на картинку. В целом получается неплохо. Для сайтов с малой и средней нагрузкой вариант достаточно привлекательный.
Виидел спорный, но интересный вариант решения этой проблемы. На серверной стороне по запросу к скрипту генерится картинка. Всё письмо соответственно представляет из себя одну эту картинку и ссылк в духе «Нажмите, если письмо отображается некорректно». Главный плюс в том, что можно не заморачиваться с вёрсткой и с помощью графической библиотеки скриптом на сервере накидать поверх картинки-шаблона текст. Кстати, ссылки можно делать как map на картинку. В целом получается неплохо. Для сайтов с малой и средней нагрузкой вариант достаточно привлекательный.
ну это уже дело программистов — как на сервере это письмо генерировать, чтобы картинки показывались… вроде как у нас как раз в base64 кодируется :)
Ну это смотря чем вы занимаетесь. Если просто верстаете основной шаблон, то это действительно не ваша проблема.
Программистам же могу посоветовать почитать что-то типа этого: www.spravkaweb.ru/php/sovet/mail/image
Коротко и корявенько, но по делу. Суть в том, чтобы пришивать файл к самому письму, а в аттрибуте src тега img cid-идентификатор. Суть в том, что т.к. такая картинка не берётся из внешнего источника она скорее всего не будет порезана почтовиком как возможно небезопасная. Так что письмо сразу отразится по-человечески.
Программистам же могу посоветовать почитать что-то типа этого: www.spravkaweb.ru/php/sovet/mail/image
Коротко и корявенько, но по делу. Суть в том, чтобы пришивать файл к самому письму, а в аттрибуте src тега img cid-идентификатор. Суть в том, что т.к. такая картинка не берётся из внешнего источника она скорее всего не будет порезана почтовиком как возможно небезопасная. Так что письмо сразу отразится по-человечески.
Вот здесь достаточное количество информации по письмам. Делали рассылку с вложенными изображениями, работает нормально, только на mail.ru отображается немного иначе, на остальных сервисах и в почтовиках отображается как и задумывалось. На mail'е добавляются только отступы большие, в остальном письмо такое же…
возможно отступы у вас были вот в связи с чем:
на mail'е добаляются отступы из-за табов в структурированом коде.
тоесть если в коде было:
<table>
<tr>
<td>
какая-то фигня
</td>
</tr>
</table>
то при просмотре письма в веб-интерфейсе будут отступы.
А если в коде будет:
<table>
<tr>
<td>
какая-то фигня
</td>
</tr>
</table>
то отступов не будет
на mail'е добаляются отступы из-за табов в структурированом коде.
тоесть если в коде было:
<table>
<tr>
<td>
какая-то фигня
</td>
</tr>
</table>
то при просмотре письма в веб-интерфейсе будут отступы.
А если в коде будет:
<table>
<tr>
<td>
какая-то фигня
</td>
</tr>
</table>
то отступов не будет
насколько я понял, отступы там добавляются попросту из-за перекрывания стилей — попробуйте посмотреть фаербагом
Да не, с табами всё нормально
В изначальном шаблоне письма они есть, но зачем их слать в письмах :) шаблон обрабатывается и лишнее всё удаляется при формировании письма. Отступы появляются из-за мэйловских стилей…
В изначальном шаблоне письма они есть, но зачем их слать в письмах :) шаблон обрабатывается и лишнее всё удаляется при формировании письма. Отступы появляются из-за мэйловских стилей…
Да, так и есть, сделал только что.
Спасибо!
Спасибо!
Для меня тема весьма актуальна, так что буду рад новым публикациям, спасибо за эту.
Изучил приведенные в конце поста ссылки, увидел, что сервис по рассылкам получает статистику об открытых, forwarded и даже помеченных как спам письмах из рассылки — как они это делают? На ум приходит только картинка-счетчик и сбор авто ответов о прочтении (), но эти цифры не дадут точной картины… А уж forwarded и помеченные как спам… Просветите меня, а?
Изучил приведенные в конце поста ссылки, увидел, что сервис по рассылкам получает статистику об открытых, forwarded и даже помеченных как спам письмах из рассылки — как они это делают? На ум приходит только картинка-счетчик и сбор авто ответов о прочтении (), но эти цифры не дадут точной картины… А уж forwarded и помеченные как спам… Просветите меня, а?
Мы для себя установили правило: письма — только в plain text. Даже редкие рассылки.
есть мнение, что в письмах нужно посылать гипертекст, а не вэб-страницы…
Реально 90-е. А в чем интересно проблема, поддерживать стиль, css?
Кстати Mail Apple читал css вложенную.
Кстати Mail Apple читал css вложенную.
Web-интерфейсы многих почтовых сервисов режут стили.
Для веб-интерфейсов почтовых сервисов существует такая штука, как фрейм, исключающая конфликты стилей письма и обвязки веб-интерфейса.
Скрипты перед отображением в рамках фрейма, разумеется, следует удалять; задача банальная.
Код письма перед отображением можно отфильтровать как угодно, вырезав из него что угодно и заменив на что угодно.
В каком фрейме? Во фрейм выводится то, что посчитает нужным вывести программист веб-интерфейса. Никакого JS там не будет, а всем ссылкам в письме можно автоматически проставить какой угодно
target.Или я вас не вполне понимаю, или вы не вполне понимаете, о чём говорите.
Вы, видимо, ещё ни разу не сталкивались лично с другой расшифровкой аббревиатуры CSS: XSS.
Поясните, каким образом вы собираетесь создавать фрейм? iframe?
Поясните, каким образом вы собираетесь создавать фрейм? iframe?
Фрейм или не фрейм, в плане безопасности в рамках веб-интерфейса почты не играет никакой роли: и страница, и фрейм, в неё включённый, генерируются средствами одного и того же сайта, и код их сколь угодно безопасен вследствие сколь угодно строгой фильтрации исходного кода письма.
Сколь угодно строгая — это отключение большинства стилей вообще для предотвращения фишинга? Так об этом и тред.
Но вот в том, что скрипты легко обрезать, не обрезая при этом кучу сторонней функциональности, вы не правы, мне кажется.
Но вот в том, что скрипты легко обрезать, не обрезая при этом кучу сторонней функциональности, вы не правы, мне кажется.
Речь в ветке только и именно о том, чтобы сохранить стили и не провоцировать применение нарочитого old-school-HTML в HTML-письмах.
Фрейм нужен только для исключения конфликтов со стилями «обвязки» веб-интерфейса почты. Скрипты (элементы
Фрейм нужен только для исключения конфликтов со стилями «обвязки» веб-интерфейса почты. Скрипты (элементы
script и обработчики в атрибутах) вырезаем (с использованием DOM-парсера задача простейшая). По-прежнему что-то неясно? ;-)А в чем интересно проблема, поддерживать стиль, css?
сказали бы вы это заказчику
А статистику по читаемости расылки у клиентов собирали?
Речь не про шефа, а про заказчика. Заказчику говорили? Он после этого не пожал плечами и не пошёл к другому подрядчику, который не встаёт в позу, не говорит — «а пусть эту проблему решают мейл.ру и гымейл.ком», а просто делает то, что требуется? :)
так я и подозревал, что будут такие гневные комментарии, т.к. им оказался ваш — вам и отвечу :)
а) я руками и ногами ЗА веб-стандарты;
б) в данном случае, статья — просто попытка облегчить жизнь тем, кто столкнулся вдруг с такой задачей;
в) с другой стороны:
— посмотрите на буржуйские интернеты: все рассылки приходят в формате HTML (причём, обильно сдобренные css'ом, видимо, динозавров типа mail.ru там не осталось);
— думаю, всем понятно, что красиво оформленное письмо «продаст» эффективнее и лучше (я не спам сейчас имею ввиду)
— это я не с потолка взял, а наткнулся в процессе гугления на иностранную статью-исследование (сейчас не могу ссылку найти, потом, возможно, повешу).
а) я руками и ногами ЗА веб-стандарты;
б) в данном случае, статья — просто попытка облегчить жизнь тем, кто столкнулся вдруг с такой задачей;
в) с другой стороны:
— посмотрите на буржуйские интернеты: все рассылки приходят в формате HTML (причём, обильно сдобренные css'ом, видимо, динозавров типа mail.ru там не осталось);
— думаю, всем понятно, что красиво оформленное письмо «продаст» эффективнее и лучше (я не спам сейчас имею ввиду)
— это я не с потолка взял, а наткнулся в процессе гугления на иностранную статью-исследование (сейчас не могу ссылку найти, потом, возможно, повешу).
пральна! двачую)
а зачем семантика в html-письмах?
У меня во время приёма на работу в одну из контор были именно такое задание. Их и гемору я натерпелся тогда, потому что пришлось верстать практически чистым html
Письма в HTML — это как обычные письма на ватмане.
Имхо, стоит отграничиться минимальным набором: h1-h6, p, ul, ol, dl, img, a и не пытаться превратить письмо в веб2.0 страницу.
Aralot, а вы, случайно, не в cpeople.ru работаете?
нет, а откуда такие выводы? :)
(место работы у меня в профиле указано)
(место работы у меня в профиле указано)
Aralot, пардон
Просто этот пост мне напомнил недавнюю историю.
Я делал один фриланс и в рамках работы нужно было создать email-рассылку, а дизайн письма делали ребята из вышеупомянутой компании. Так вот они повторяли все пункты описанные в статье :) В начале мне прислали html-шаблон, в котором все сверстано на дивах, после того как я протестировал его и понял, что нужно делать все в таблицах, они переделали в таблицы. Затем ошибка с выносом css в файл (об этом я даже не говорил им, проще было самому включить css в документ) и т.д. по списку в указанном вами порядке :)
Эта эпопея с переслыкой мне невалидного шаблона длилась недели две, пока терпение мое не кончилось и я набросал для них программу на C# через которую можно было отправлять html-письмо, скопировав код шаблона в поле ввода. Отправил прогу со словами :«Пока не протестируете не прислылайте шаблон». Ребята пропали месяца на два… и вот буквально два дня назад объявились, прислали письмо с протестированным шаблоном :) и тут этот пост…
Совпадение :)
Просто этот пост мне напомнил недавнюю историю.
Я делал один фриланс и в рамках работы нужно было создать email-рассылку, а дизайн письма делали ребята из вышеупомянутой компании. Так вот они повторяли все пункты описанные в статье :) В начале мне прислали html-шаблон, в котором все сверстано на дивах, после того как я протестировал его и понял, что нужно делать все в таблицах, они переделали в таблицы. Затем ошибка с выносом css в файл (об этом я даже не говорил им, проще было самому включить css в документ) и т.д. по списку в указанном вами порядке :)
Эта эпопея с переслыкой мне невалидного шаблона длилась недели две, пока терпение мое не кончилось и я набросал для них программу на C# через которую можно было отправлять html-письмо, скопировав код шаблона в поле ввода. Отправил прогу со словами :«Пока не протестируете не прислылайте шаблон». Ребята пропали месяца на два… и вот буквально два дня назад объявились, прислали письмо с протестированным шаблоном :) и тут этот пост…
Совпадение :)
Гайдлайны для спамеров?
Отличная тема и спасибо за подробный рассказ про возможные грабли — надеюсь, что другие меньше из-за этого потратят времени.
Пишите ещё по этой теме — думаю, не только я прочитают с удовольствием.
Пишите ещё по этой теме — думаю, не только я прочитают с удовольствием.
По п. 3 — задание padding-left, padding-right. В комментариях уже было, я лишь подтверждаю, что в mail.ru работает так:
По п. 9) картинки в оформлении. Я использую такой смешанный вариант (подходит для mail.ru, yandex, rambler, gmail.com):
p.s. В почтовых клиентах не проверял, что является упущением, конечно. Было бы интересно узнать статистику, сколько процентов пользователей ими пользуется. Как теперь вижу по комментариям — есть проблемы с отображением внешних изображений в почтовых клиентах.
<table cellpadding="0" cellspacing="0" border="0" width="100%">
<tr>
<td><img src="spacer.gif" width="10" height="1"></td>
<td width="100%"></td>
<td><img src="spacer.gif" width="10" height="1"></td>
</tr>
</table>
По п. 9) картинки в оформлении. Я использую такой смешанный вариант (подходит для mail.ru, yandex, rambler, gmail.com):
<td background="http://www.moysite.ru/bg.gif" style="background:url(http://www.moysite.ru/bg.gif);"> <img src="spacer.gif" width="50" height="1"> </td>
p.s. В почтовых клиентах не проверял, что является упущением, конечно. Было бы интересно узнать статистику, сколько процентов пользователей ими пользуется. Как теперь вижу по комментариям — есть проблемы с отображением внешних изображений в почтовых клиентах.
Пропустил заголовок и думал речь идет о вэб верстке. Сильно испугался. :)
красиво спамим
Разметка в письмах не нужна совсем.
>Самый распространенный почтовый сервис на данный момент (mail.ru)
Так уж самый распространенный?
Так уж самый распространенный?
Сейчас занимаюсь вёрсктой для мобильных телефонов (xhtml mp) — та же ерунда, back to 90s.
полезно! спасибо.
«10) программы и инструментарий … точнее его отстутсвие — для тестирования рассылки я, к моему сожалению (и удивлению), ничего лучше outlook express»
Я когда шаблоны для рассылки верстал, делал сообщение в виде обычного HTML, открыть в Опере или ИЕ и сохранял «как веб-архив», затем менял расширение с mht на msg, а уже msg-файлы замечательно импортируются в почтовые клиенты.
Я когда шаблоны для рассылки верстал, делал сообщение в виде обычного HTML, открыть в Опере или ИЕ и сохранял «как веб-архив», затем менял расширение с mht на msg, а уже msg-файлы замечательно импортируются в почтовые клиенты.
Насчет паддингов на mail.ru, у них есть класс pad_null, если его поставить всем используемым тегам table — паддинги обнуляться.
Это свойство в css файле mail.ru помечено «для партнерских рассылок»…
Это свойство в css файле mail.ru помечено «для партнерских рассылок»…
только вот как поставить класс, если стили режутся? :)
а вы попробуйте написать так:, увидите сами, это останется не тронутым. На mail.ru вырезается атрибут style (переименовывается в xstyle, как уже писали выше) и вырезается тег
Сорри. атрибут class в тегах не режется, режется тег style, который пишется в шапке HTML и содержит стили для используемых на странице классах. Поэтому использовать классы, которые определены в CSS файлах mail.ru можно, но лично я не нашел в них ничего полезного, кроме pad_null, который обнуляет отступы…
Блин, мне аж поплохело.
Почтовики находят текст, похожий на ссылку, и обрамляют его в теги a, прописывают href.
Есть ли способ запретить это делать?
Есть ли способ запретить это делать?
Отличная статья, спасибо!
Sign up to leave a comment.
10 рекомендаций по html-верстке электронных писем