Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 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, так как куча корпоративных клиентов сидит именно на нем.
Какая у вас замечательная коллекция граблей. Спасибо.
Обожаю программировать сервисы связанные с рассылкой и разбором почты. Обожаю почтовые протоколы как таковые и в особенности каждого мейл-агента со всей их отсебятиной обожаю. Веселое это дело. Веселее браузерных граблей.
Это объясняет, почему так часто встречаются рассылки ввиде нарезки из картинок-ссылок вообще без верстки. :)
HTML письма должны умереть.
По опыту верстки писем, самое слабое звено — аутлук 2007. У него вордовский движек.
Предложил дизайнерам рисовать макеты писем в ворде, обещал сделать все что они смогут там нарисовать:)))
Предложил дизайнерам рисовать макеты писем в ворде, обещал сделать все что они смогут там нарисовать:)))
А если у клиента (как у меня) по дефолту стоит не отображать HTML? Какие предложение вы внесете?
Обычно такие письма высылаются в html и в plaintext, и человеку показывается письмо в соответствии с его настройками.
Кстати, об этом есть упоминание в топике:
Кстати, об этом есть упоминание в топике:
В текстовой версии нельзя использовать html entities, потому что это текстовая версия, а не HTML. Также, в текстовой версии нельзя использовать unicode символы, которых нет в windows-1251, т.к. mail.ru зачем то перекодирует письмо в эту кодировку;
> В Gmail если у картинки, которая является единственной в ячейке таблицы, появляется 3px отступ снизу, его можно устранить, указав style=«display:block» этой картинке;
Ну еще бы, строчный элемент, выравнивается видимо по базовой линии, это скорее не особенность Gmail, а особенность HTML.
Ну еще бы, строчный элемент, выравнивается видимо по базовой линии, это скорее не особенность Gmail, а особенность HTML.
«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, тоже помагает решить проблему с 3pxЗарегистрируйтесь на Хабре, чтобы оставить комментарий
Грабли при верстке HTML писем