Комментарии
38
Я бы решал эту проблему при помощи UserJS, чтобы вообще не писать сложные парсеры, в браузерах это уже все есть, достаточно после загрузки страницы пройтись по всем элемента и дописать в style.cssText стили, полученные при помощи getComputedStyle.
Хотя серверное решение конечно же может понадобиться…
Javascript в почтовом сообщении штука сомнительная. Например, в Thunderbird 3 он выключен.
Javascript в самом сообщении и не нужен, здесь о преобразовании перед отправкой речь идет.
ммм, интересная идея, только письма-то заранее сделанные, типа активации пользователя, прогонять их через браузер совсем не хочется, не удобно это
вот если бы можно было поставить на сервер браузер какой-нибудь, типа firefox-а и заставить его что-то сотворить с html-кой + css в фоне, чтобы это было не на стороне пользователя — вот это было бы круто
оно возвращает значения в пикселях. по твоему у всех монитор такой же как у тебя?
Css parser отлично работает, я например просто составляю css-ки с расчетом на то что они будут использоваться в письмах, т.е. не использую сложные селекторы и наследование, получаются классы вроде strong_text и strong_red_text, различающиеся только цветом.
тоже вариант, но отказываться от всех перимуществ css из-за почты — я не могу пойти на такое
Ну тут уже зависит от ваших писем и задач конечно. Но с другой стороны — это всего лишь письмо, я на своей практике ни разу не видел письма где нельзя было бы обойтись без вложенности стилей и всяких таких примочек.
Ну и кстати вы можете генерировать css) Sass вам в помощь.
Ну и кстати вы можете генерировать css) Sass вам в помощь.
если бы это было просто письмо — то да, можно было бы обойтись без вложенности стилей и всяких примочек, но хочется-то использовать уже существующий код, который используется на основном сайте, например, на сайте есть красивая панелька, она уже сверстана и оттестирована, находится в отдельном partial-е, хочется в письме сделать:
render :partial => 'shared/panel'
и не заморачиваться больше. Да, я понимаю, что по большому счету для лучшей поддержки почтовыми клиентами было бы круто переверстать все это дело таблицами, убрать все сложные, неподдерживаемые css-правила и т.п. но хочется-то, хотя бы на первое время, сделать быстрое решение, чтобы показать его начальству, а потом уже в фоне по мере сил и возможностей перевестать по-правильному.
render :partial => 'shared/panel'
и не заморачиваться больше. Да, я понимаю, что по большому счету для лучшей поддержки почтовыми клиентами было бы круто переверстать все это дело таблицами, убрать все сложные, неподдерживаемые css-правила и т.п. но хочется-то, хотя бы на первое время, сделать быстрое решение, чтобы показать его начальству, а потом уже в фоне по мере сил и возможностей перевестать по-правильному.
Неправильное решение. Сайт — это сайт. Письмо — это письмо. По-хорошему, вы не должны использовать в письме такие элементы сайта, как красивая панелька. Вы хоть в одной рассылке такой бред видели? Подпишитесь на рассылку Apple и посмотрите как надо правильно офорлять рассылки.
это от каких? неужели так сложно более общие селекторы писать вначале?
Самое главное правило HTML-писем: обязательно включать в сообщение и plain text-версию.
вы безусловно правы! но что делать с html-версией? :)
Фтопку
Если в письме есть аттачмент картинки, то в HTML-ке ее можно отобразить. Возможно, и со стилями такой трюк пройдет.
Техника такая:
где 25bc9b0e72ffee30f74314732989afd7 — Content-Id картинки в письме. На сколько помню, Content-Id может быть любым, я ставил имя файла.
Техника такая:
где 25bc9b0e72ffee30f74314732989afd7 — Content-Id картинки в письме. На сколько помню, Content-Id может быть любым, я ставил имя файла.
Немного неправильно отправил.
Техника такая:
<img src="cid:25bc9b0e72ffee30f74314732989afd7">
где 25bc9b0e72ffee30f74314732989afd7 — Content-Id картинки в письме. На сколько помню, Content-Id может быть любым, я ставил имя файла.
Техника такая:
<img src="cid:25bc9b0e72ffee30f74314732989afd7">
где 25bc9b0e72ffee30f74314732989afd7 — Content-Id картинки в письме. На сколько помню, Content-Id может быть любым, я ставил имя файла.
не все почтовики поддерживают вставленный CSS документ
хотя конечно не поддерживают его только браузерные типа gmail, по очевидным причинам
хотя конечно не поддерживают его только браузерные типа gmail, по очевидным причинам
По-моему, лежащее на поверхности решение — отказаться от семантики и использовать CSS-классы вроде «red» «100-percent-wide».
Мерзко, но в случае с почтой может быть оправдано.
Мерзко, но в случае с почтой может быть оправдано.
или не отказываться и генерить страшный css.
В любом случае придется обходить ограничения email-клиентов — от них пока никуда не деться
В любом случае придется обходить ограничения email-клиентов — от них пока никуда не деться
Такая же проблема стоит перед верстальщиками виджетов для вставки в блоги.
Например, ЖЖ еще и некоторые инлайновые объявления режет (position: relative и absolute).
Мне кажется, можно написать простенькое расширение для внутреннего пользования (под FF или Chrome), по совету тов. Octane, и генерить с его помощью шаблоны. Не так уж часто эти шаблоны меняются, имхо.
Например, ЖЖ еще и некоторые инлайновые объявления режет (position: relative и absolute).
Мне кажется, можно написать простенькое расширение для внутреннего пользования (под FF или Chrome), по совету тов. Octane, и генерить с его помощью шаблоны. Не так уж часто эти шаблоны меняются, имхо.
да, наверное так и придется делать, спасибо за совет!
аутлук ваще жжёт. у него свой собсвенный движок рендеринга ХТМЛ, который очень похож на то, как рендерит разметку Word. так что для писем основной принцип — чем проще, тем лучше. иначе есть все шансы взорвать себе мозг, пытаясь понять почему в аутлуке письмо выглядит так странно
Мы в свое время отказались от html в письмах, из-за неадекватного восприятия — половина пользователей отправляет письмо с html в корзину не читая даже заголовок. Необходимый контент генерировался на сервере, а в письмо была вставлена личная ссылка.
Это далеко не универсальный способ, во-первых лишний клик, во-вторых безопасность.
Это далеко не универсальный способ, во-первых лишний клик, во-вторых безопасность.
Мы тоже рассылаем html письма, но их читает далеко не 50%.
Все нормальные импортные магазины присылают html письма.
Все чинно, красиво и никакого спама и люди читают. Так что не стоит наезжать на красивые письма.
Все нормальные импортные магазины присылают html письма.
Все чинно, красиво и никакого спама и люди читают. Так что не стоит наезжать на красивые письма.
apple.com рассылает офигенно красиво сверстанные письма.
Я уверен, что они немного больше вас.
Я уверен, что они немного больше вас.
пора бы уже и email стандартам начать развиваться.
хрестоматийное от Зельдмана:
«E-mail is not a platform for design»
www.zeldman.com/2007/06/08/e-mail-is-not-a-platform-for-design/
Русский перевод:
www.newsland.ru/News/Detail/id/82184/
«E-mail is not a platform for design»
www.zeldman.com/2007/06/08/e-mail-is-not-a-platform-for-design/
Русский перевод:
www.newsland.ru/News/Detail/id/82184/
По-моему, поскольку проблема описана, проще всего форкнуться и решить её.
В методе
def render_inline(css_doc, html_doc)
надо просто получить список всех селекторов и потом просто отсортировать по увеличению важности.
Цитирую Википедию:
Приоритеты рассчитываются таким образом (от большего к меньшему):
свойство задано при помощи !important?
стиль прописан напрямую в теге?
количество идентификаторов (#id) в селекторе (чем больше, тем больше приоритет);
количество классов (.class) и псевдоклассов (:pseudoclass) в селекторе;
количество имён тегов в селекторе;
Кроме того, имеет значение относительный порядок расположения свойств — свойство, указанное позже, имеет приоритет.
В общем, вполне реализуемо, за небольшое время. Если бы мне было нужно, я бы реализовал.
В методе
def render_inline(css_doc, html_doc)
надо просто получить список всех селекторов и потом просто отсортировать по увеличению важности.
Цитирую Википедию:
Приоритеты рассчитываются таким образом (от большего к меньшему):
свойство задано при помощи !important?
стиль прописан напрямую в теге?
количество идентификаторов (#id) в селекторе (чем больше, тем больше приоритет);
количество классов (.class) и псевдоклассов (:pseudoclass) в селекторе;
количество имён тегов в селекторе;
Кроме того, имеет значение относительный порядок расположения свойств — свойство, указанное позже, имеет приоритет.
В общем, вполне реализуемо, за небольшое время. Если бы мне было нужно, я бы реализовал.
надо попробовать, но что-то мне подсказывает что тут не все так просто как кажется
в общем, я реализовал задуманное
вот сопутствующая статья: rails.vsevteme.ru/items/show?id=15682
а вот код: github.com/goganchic/awesome_email
вот сопутствующая статья: rails.vsevteme.ru/items/show?id=15682
а вот код: github.com/goganchic/awesome_email
Молодцом!
Теперь можно отправить pull request и все мы будем благодарны тебе при случае!
Теперь можно отправить pull request и все мы будем благодарны тебе при случае!
Microsoft часто делает рассылку и все отображается очень корректно, картинки к картинкам, тексты к текстам, все, что не хочешь — не открываешь. Просто заверстанная страничка — очень удобно мне кажется…
Отлично! RC очень порадовал. Правда сначала было немного непривычно, т.к. изменились некоторые обыденные команды, а так очень нравится. Ждём полного Релиза"
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Как быть с HTML-письмами?