Comments 77
Полезно. Спасибо.
Уже была похожая подборочка: habrahabr.ru/blogs/webdev/60420/
Спасибо большое за хак для картинке в Gmail — очень помогло.
Делал шаблон рассылки для «Бигуди шоу» и была проблема стыковки двух картинок, думал, что с версткой что-то не так. Оказывается грабли в Gmail'е были.
Делал шаблон рассылки для «Бигуди шоу» и была проблема стыковки двух картинок, думал, что с версткой что-то не так. Оказывается грабли в Gmail'е были.
Как это относится к блогу «Спам (и антиспам)»?
Полезная сравнительная таблица для популярных почтовиков www.campaignmonitor.com/css/
Не нашел про цвет фона vs. цвет текста.
Очень часто люди жестко устанавливают цвет письма и забывают про установку цвета фона. И у людей типа меня, у которых по дефолту белый текст на черном фоне, получается совершено нечитаемый текст. Негры ночью крадут уголь. Кстати этой проблемой болеют и очень большие компании типа асуса.
Очень часто люди жестко устанавливают цвет письма и забывают про установку цвета фона. И у людей типа меня, у которых по дефолту белый текст на черном фоне, получается совершено нечитаемый текст. Негры ночью крадут уголь. Кстати этой проблемой болеют и очень большие компании типа асуса.
Я смотрю никто не придерживается стандартов, поэтому и такой бардак.
Я понимаю, безопасность, но не до такой степени, чтобы игнорировать стандарты.
Я понимаю, безопасность, но не до такой степени, чтобы игнорировать стандарты.
Конечно, не до такой же степени. Кому нужна эта безопасность. Лучше пусть запустится какой нибудь эксплойт чем картинка неправильно отобразится.
Если придерживаться стандартов безопасности и верстки, эксплойт не запустится, а вот картинку ты посмотришь :)
Согласитесь, то что сейчас — это бардак, причем я подозреваю пробои все равно есть.
Согласитесь, то что сейчас — это бардак, причем я подозреваю пробои все равно есть.
Разумеется 100% безопасность недостижима. Но это не значит что надо её игнорировать ради соблюдения стандартов верстки. Безопасность — компромис. Для почтовых систем закрытие ничтожной вероятности уязвимости, гораздо важнее чем правильное отображение навороченных писем. И для меня тоже, я буду выбирать именно безопасного почтового клиента, а не того в котором картинки красиво показываются. Собственно в моем почтовом клиенте по умолчанию вообще не отображаются картинки и разумеется съезжает верстка. И у меня к этому никаких притензий.
Поставьте сторонний os движок отображения верстки (для малых проектов — выход).
Я понимаю, что в картинке можно подложить свинью, но есть много методов проверки картинка это или эксплойт.
Я вам отвечу (к вам это не относится, а вот к «большим» организациям -да ), просто программистам влом проверять и писать модули — раз. Второе, стандарты для них вообще — не совет, спецификации для них нудны. Вот и получается бардак.
Вообще большим организациям, надо соблюдать стандарты и спецификации, иначе это просто не уважение к пользователям.
Вам нравится когда вас не уважают (мягко говоря) ;)?
Я понимаю, что в картинке можно подложить свинью, но есть много методов проверки картинка это или эксплойт.
Я вам отвечу (к вам это не относится, а вот к «большим» организациям -да ), просто программистам влом проверять и писать модули — раз. Второе, стандарты для них вообще — не совет, спецификации для них нудны. Вот и получается бардак.
Вообще большим организациям, надо соблюдать стандарты и спецификации, иначе это просто не уважение к пользователям.
Вам нравится когда вас не уважают (мягко говоря) ;)?
«есть много методов проверки картинка это или эксплойт» классно. Интересно почему бы их не использовать и не обезопаситься навсегда от эксплойтов?
Мне не нравятся стандарты ради стандартов.
Мне не нравятся стандарты ради стандартов.
Это не стандарты ради стандартов.
Стандарты придумали не для этого.
Кстати стандарты и придумали для безопасности в первую очередь. Вы просто или меня не поняли или вам нудно от них.
Стандарты придумали не для этого.
Кстати стандарты и придумали для безопасности в первую очередь. Вы просто или меня не поняли или вам нудно от них.
Нет, я понял. Вы знаете какие то универсальные методы проверки является ли картинка эксплойтом :)
Мне не нудно, мне скорее неприятно позиционирование стандартов отображения картинок в почте, выше чем требований безопасности в вашем исходном сообщении.
Мне не нудно, мне скорее неприятно позиционирование стандартов отображения картинок в почте, выше чем требований безопасности в вашем исходном сообщении.
Вы программист, должны знать, что есть, если бы не было, не было бы не граф редакторов, ни просмотрщиков и т.п.
Универсальный метод — сделать ресайз картинки или изменение качества. Сами знаете, что при этом будет с эксплойтом, а с картинкой ничего не случится.
Ну началось. Тот кто минус поставил — аргументируйте его.
Потому, что другие люди будут думать, что это не метод.
Минус без причины — признак дурачины.
Или кто-то хочет сказать, что уменьшив качество картинки, с кодом эксплойта ничего не случится?
Или картинка при этом будет другая?
Ну, аргументируйте.
Потому, что другие люди будут думать, что это не метод.
Минус без причины — признак дурачины.
Или кто-то хочет сказать, что уменьшив качество картинки, с кодом эксплойта ничего не случится?
Или картинка при этом будет другая?
Ну, аргументируйте.
В большинстве случаев ваш вариант будет работать очень хорошо. Но любое DKIM подписанно письмо не будет проходить проверку или с S/MIME подписью т.к. контент был изменен.
Это если мы говорим о том случае когда картинка изменяться прежде чем попадет к получателю т.е. гдето здесь MUA->MTA->(body change)MTA->MUA.
Это если мы говорим о том случае когда картинка изменяться прежде чем попадет к получателю т.е. гдето здесь MUA->MTA->(body change)MTA->MUA.
А мы и говорим о web интерфейсах в первую очередь, во вторую, при получении юзера почтовиком. Или при отправлении — сразу изменять, при создании письма. Это уже другой алгоритм.
Меня спросили — про проверку картинки на эксплойт ;)
Этот метод универсален, правда есть недостаток — ресурсоемкость на больших проектах. При них тоже есть алгоритмы определения, я просто предложил самый простой и универсальный.
Я вообще не понимаю (не к вам) — это опять тролль завелся? Все мои комменты- минусуют, причем везде, в не зависимости от контента.
Меня спросили — про проверку картинки на эксплойт ;)
Этот метод универсален, правда есть недостаток — ресурсоемкость на больших проектах. При них тоже есть алгоритмы определения, я просто предложил самый простой и универсальный.
Я вообще не понимаю (не к вам) — это опять тролль завелся? Все мои комменты- минусуют, причем везде, в не зависимости от контента.
в мемориз
сам верстал довольно много макетов, намучился
сам верстал довольно много макетов, намучился
стоило еще рассказать про lotus notes, так как куча корпоративных клиентов сидит именно на нем.
UFO just landed and posted this here
Какая у вас замечательная коллекция граблей. Спасибо.
Обожаю программировать сервисы связанные с рассылкой и разбором почты. Обожаю почтовые протоколы как таковые и в особенности каждого мейл-агента со всей их отсебятиной обожаю. Веселое это дело. Веселее браузерных граблей.
Это объясняет, почему так часто встречаются рассылки ввиде нарезки из картинок-ссылок вообще без верстки. :)
HTML письма должны умереть.
По опыту верстки писем, самое слабое звено — аутлук 2007. У него вордовский движек.
Предложил дизайнерам рисовать макеты писем в ворде, обещал сделать все что они смогут там нарисовать:)))
Предложил дизайнерам рисовать макеты писем в ворде, обещал сделать все что они смогут там нарисовать:)))
А если у клиента (как у меня) по дефолту стоит не отображать HTML? Какие предложение вы внесете?
Обычно такие письма высылаются в html и в plaintext, и человеку показывается письмо в соответствии с его настройками.
Кстати, об этом есть упоминание в топике:
Кстати, об этом есть упоминание в топике:
В текстовой версии нельзя использовать html entities, потому что это текстовая версия, а не HTML. Также, в текстовой версии нельзя использовать unicode символы, которых нет в windows-1251, т.к. mail.ru зачем то перекодирует письмо в эту кодировку;
> В Gmail если у картинки, которая является единственной в ячейке таблицы, появляется 3px отступ снизу, его можно устранить, указав style=«display:block» этой картинке;
Ну еще бы, строчный элемент, выравнивается видимо по базовой линии, это скорее не особенность Gmail, а особенность HTML.
Ну еще бы, строчный элемент, выравнивается видимо по базовой линии, это скорее не особенность Gmail, а особенность HTML.
UFO just landed and posted this here
«E-mail is not a platform for design» (с) Jeffrey Zeldman
www.newsland.ru/News/Detail/id/82184/
www.zeldman.com/2007/06/08/e-mail-is-not-a-platform-for-design/
www.newsland.ru/News/Detail/id/82184/
www.zeldman.com/2007/06/08/e-mail-is-not-a-platform-for-design/
Вот поэтому я и пользуюсь ThunderBird, который корректно показывает HTML-письма :)
Вы все еще отправляете письма в HTML? Тогда мы идем к вам. (с) ваш plain-text
Нет на вас юзабилистов… Попробуйте отправить по сотрудникам крупной компании информационный дайджест за две недели (10-15 новостей) в plain text — и посмотрите сколько из них прочитаю его дальше поля Subject.
А смысл его слать в теле письма? Шлите его нормально в PDF, не издевайтесь. Вот мне еженедельно почти приходит дайджест от MS — поубивал бы на хрен тех, кто решил это впихнуть в письмо.
Спасибо за совет, как-то не приходило это в голову… В этом есть свою плюсы, подумаю теперь есть ли минусы.
В этом есть минусы, во многих случаях pdf будет излишне громоздок с точки зрения времени просмотра. Тут нужен баланс. Но я уверен, что в 99% случаев можно обойтись без html-почты, тем более ничего кроме головняка обеим сторонам это не несет. И, да, в этом виноваты онлайн и оффлайн почтовые клиенты в том числе.
Вот так, к примеру, выглядит половина корреспонденции от MS в моем оффлайн клиенте.
Вот так, к примеру, выглядит половина корреспонденции от MS в моем оффлайн клиенте.
Ну у меня немного попроще ситуация — я ориентируюсь исключительно на получателей с корпоративным Outlook 2007. Поэтому даже довольно сложный дизайн нашего новостного дайджеста получается передать на 100%. А для рутинных писем-рассылок мы используем сверстанный в Word HTML с минимумом графики и разметки, что тоже упрощает жизнь.
Расскажите про свою ЦА. Откуда уверенность в наличие корпоративного Outlook и именно 2007 версии? Я знаю достаточно много крупных компаний (100+), который используют TheBat / GMail.com / Thunderbird (редко). В целом же да, инфраструктура Windows в компании — практически гарантия использования Outlook.
У нас в компании на всех рабочих ПК стоит единый образ ОС с единым и одновременно обновляемым дистрибутивом Office. Если кто-то предпрочитает пользоваться сторонним ПО — это его дело и его риск получать внутренние коммуникации в перекошенном виде, в таком случае (хоть я и тестировал свои шаблоны писем в разных клиентах — везде в целом все хорошо).
Может быть, если вы точно знаете что находится на машинах вашей ЦА (а это, как я понял, свежая платформа MS) использовать XPS, к примеру? Ниже вы писали, что PDF громоздок (на самом деле для 1.5 страниц, пожалуй, будет не лучший вариант), возможно XPS сможет заменить его полноценно.
Какого рода контент? Мне действительно интересно, возможно, я не прав в столь категоричном своем отношении к html-письмам в ряде случаев.
Какого рода контент? Мне действительно интересно, возможно, я не прав в столь категоричном своем отношении к html-письмам в ряде случаев.
Контент — картинка 800 на 200 в хедере, 6-8 картинок 145 на 110 в дайджесте новостной ленты, несколько килобайт текста с выдержками новостей и ссылками на полные версии текстов на внутреннем сайте. У меня все заверстано в тупую таблицу, вообще без CSS. Вот, собственно, как выглядит последняя рассылка:
PDF долго открывается, а html показывается сразу любой программой и веб-интерфейсом. Если нужно переслать документацию, результаты исследования, отчет или еще что-то большое — конечно PDF хороший вариант. Но рассылать в нем ежедневные новости или предложения — нереально, это не будут читать.
Постойте, но мы живем в 2010 году. То что кто-то шлет ежедневные новости в виде гигантского html-контента с помощью электропочты — это понятно. Но нужно ли это в таком виде на самом деле? В чем соль? И это все еще происходит в век, когда популярен RSS, доступен Интернет & etc. Конечно html показывается быстро, но для «крупной» информации есть браузер и контент на сайте, мелкие новости спокойно усваиваются plaint-text'ом.
И, да, plain-text тоже можно оформить читаемо, чтобы не возникало жаления просить читать сразу же после заголовка.
И, да, plain-text тоже можно оформить читаемо, чтобы не возникало жаления просить читать сразу же после заголовка.
Нет, речь идет о рассылке раз в две недели. Информации там — примерно на полтора листа А4.
Попробовал перевести это в PDF — получилось вполне прилично. Но вы правы — открывается медленно. Я попробовал на трех обычных рабочих компьютерах, которые используются у нас в компании, такой документ в PDF открывается до 15 секунд, что чертовски долго для современного пользователя.
Попробовал перевести это в PDF — получилось вполне прилично. Но вы правы — открывается медленно. Я попробовал на трех обычных рабочих компьютерах, которые используются у нас в компании, такой документ в PDF открывается до 15 секунд, что чертовски долго для современного пользователя.
Любители заверстать все в один gif смотрят на этот пост с недоумением :-)
При тестировании HTML в Windows Live обнаружил, что не работают ссылки с якорем #comment
В Outlook есть еще такой занятный параметр у тега — NOSEND. Он нужен для того, чтобы получателю письма приходило письмо без картинок, а картинки он мог по желанию подгрузить с сервера через контекстное меню. Пример:
Еще недавно этот прием у меня работал на ура, когда нужно было уместить в узкий лимит письмо с картинками общим объемом 150-200 Кб. Но пару месяцев назад работать перестало — картинки все равно шлются вставленными в тело письма.
Может кто-нибудь знает что с этим делать и как вернуть счастье?
<img src="внутренний_сервер_картинок/img1.jpg" width="145" height="110" NOSEND="1" />Еще недавно этот прием у меня работал на ура, когда нужно было уместить в узкий лимит письмо с картинками общим объемом 150-200 Кб. Но пару месяцев назад работать перестало — картинки все равно шлются вставленными в тело письма.
Может кто-нибудь знает что с этим делать и как вернуть счастье?
И вот представьте, в силу какого-либо рода обстоятельств (настройки почтового клиента, брандмауэра или еще сотни вариантов) у человека получившего письмо картинки не подгрузились с внешнего источника. Как это выглядит? А отсюда уже идет масса казусов.
Опять же, как писал выше, мои получатели все сидят на одном и том же клиенте с едиными настройками по-умолчанию и за одним и тем же корпоративным фаерволлом. Когда я однажды открыл для себя NOSEND — это было событие дня для меня, потому что реально сделало задачу проще в три раза. А теперь счастье ушло… Наверное снова закрутили гайки безопасности. Или тоже подумали о совместимости клиентов, как вы говорите.
Кто почтовые дизайны верстал, тот в цирке не смеется.
Еще фееричный момент mail.ru:
сочетание ">0<" заменяется на полный текст письма. Правится заменой на "> 0 <".
Пример: «Скидка: 0 руб.» в интерфейсе mail.ru отображается как
«Скидка: Скидка: 0 руб. руб.»
сочетание ">0<" заменяется на полный текст письма. Правится заменой на "> 0 <".
Пример: «Скидка: 0 руб.» в интерфейсе mail.ru отображается как
«Скидка: Скидка: 0 руб. руб.»
Тут просто необходимо вспомнить Email Standards Project. Цель этого проекта — улучшить поддержку веб-стандартов при верстке HTML-писем. Там, в частности, содержатся рекомендации по верстке писем и информация о поддержке HTML и CSS разными почтовыми сервисами и клиентами.
«Чтобы в IE6 внизу картинок не отображался 3px отступ, надо, чтобы между тегом картинки и тегом закрытия ячейки не было пробельных символов (при этом допускается использование для переноса строки комментария вида:
Можно инлайном прописать
<td>
<img src="" alt="" /><!--
--></td>»Можно инлайном прописать
line-height:0, тоже помагает решить проблему с 3pxSign up to leave a comment.
Грабли при верстке HTML писем