Comments 16
background: url(../images/h2-bg.png) no-repeat left top #ef5580;<table background="images/h2-bg.png">Может, в первом случае не работает из-за неправильного пути? Стиль лежал в папке css, было правильно. Теперь стиль прописан напрямую в html — получилось неправильно. Или все равно работать не будет?
Типичная верстка имеет такие пути:
/some.html
/styles/screen.css
/images/somepic.png
относительный путь из html это images/somepic.png
относительный путь из css это ../images/somepic.png
Не работает потому, что тот же гугль прост вырезает url() из всех стилей жестко. Путем выкидывания атрибута, в котором встречается url()
/some.html
/styles/screen.css
/images/somepic.png
относительный путь из html это images/somepic.png
относительный путь из css это ../images/somepic.png
Не работает потому, что тот же гугль прост вырезает url() из всех стилей жестко. Путем выкидывания атрибута, в котором встречается url()
Аргументы почему нельзя использовать таблицы как-то совсем меня не убедили (ну пусть контентщики дримвевер возьмут на крайняк, или сделайте им гуй-страницу для правильного заполнения), поэтому оставлю это здесь: htmlemailboilerplate.com/
А есть ли какие-то рекомендации по верстке, чтобы письма не попадали в спам?
Ибо сие от верстки вполне может зависеть. Я как-то экспериментировал и обнаружил, что указывая font-size у одного из элементов, письмо попадало в спам в google mail, а без font-size — не попадало.
Вообще, верстка под почтовые клиенты — штука более сложная, чем обычная html верстка.
Ибо сие от верстки вполне может зависеть. Я как-то экспериментировал и обнаружил, что указывая font-size у одного из элементов, письмо попадало в спам в google mail, а без font-size — не попадало.
Вообще, верстка под почтовые клиенты — штука более сложная, чем обычная html верстка.
Зависимость от font-size я не видел ни разу. Думаю, это из-за слишком маленького шрифта.
Они стараются проверять наличие «невидимого» текста (display: none или там color: white; background: white, и другие варианты) — и при наличии невидимого маркируют как спам, ибо это обычная практика спама.
Что делать, чтобы не падало в спам хорошо видно вот тут:
mail.google.com/support/bin/answer.py?hl=ru&answer=81126
Да, более сложная, но число геморроя с рассылкой после введения фильтра упало значительно.
Они стараются проверять наличие «невидимого» текста (display: none или там color: white; background: white, и другие варианты) — и при наличии невидимого маркируют как спам, ибо это обычная практика спама.
Что делать, чтобы не падало в спам хорошо видно вот тут:
mail.google.com/support/bin/answer.py?hl=ru&answer=81126
Да, более сложная, но число геморроя с рассылкой после введения фильтра упало значительно.
тогда на кой тут вообще дивы сдались? пишем хмл вида [head][a href="//..']mysite[a][/head] вешаем на него xslt с примерно такими шаблонами:
[template match='head']
[table background=«img.png»]
[tbody]
[tr]
[td]
[apply-templates select /]
[/td]
[/tr]
[/tbody]
[/template]
и не нужны никакие пляски с бубнами
[template match='head']
[table background=«img.png»]
[tbody]
[tr]
[td]
[apply-templates select /]
[/td]
[/tr]
[/tbody]
[/template]
и не нужны никакие пляски с бубнами
Во-1х найти хорошего верстальщика на дивах в разы проще, чем найти XSLT программиста.
Во-2х все стили придётся верстать другим образом, не в CSS а в XML, иначе их XSLT не обработать.
В общем, плясок с бубнами получится в разы больше. И смысл?
Во-2х все стили придётся верстать другим образом, не в CSS а в XML, иначе их XSLT не обработать.
В общем, плясок с бубнами получится в разы больше. И смысл?
а не надо на xslt программировать. пишем шаблончики типа того, что я показал и не паримся.
[table style=«color:red;width:100%»] — ну прям такой «другой образ», что прям ах: О
смысл в том, что мы имеем полный контроль за тем, какая вёрстка будет получаться, а не писать костыли типа tablify на каждый чих
[table style=«color:red;width:100%»] — ну прям такой «другой образ», что прям ах: О
смысл в том, что мы имеем полный контроль за тем, какая вёрстка будет получаться, а не писать костыли типа tablify на каждый чих
Ну вот смотри. Пользователю надо добавить заголовок.
В гуёвом редакторе он жмёт кнопку h2. Добавляется h2.
Он видит сразу какие стили применены.
Отсылает письмо — видит то же самое.
Открывает опять редактор — там всё еще h2, и он всё еще может его изменить. Например — заменить на h3.
Теперь берём xslt решение. Что добавляет пользователь? Как трансформируется это добро?
Какая верстка будет получаться верстальщик и так имеет контроль — есть кнопка посмотреть на сгенерированное, а общую обёртку хедер-футер-итд он и так может на таблицах делать (хотя у нас всё сверстано нормально дивно, фактически используется стандартная верстка сайта с микроскопическими изменениями для корректной передачи в почту).
В гуёвом редакторе он жмёт кнопку h2. Добавляется h2.
Он видит сразу какие стили применены.
Отсылает письмо — видит то же самое.
Открывает опять редактор — там всё еще h2, и он всё еще может его изменить. Например — заменить на h3.
Теперь берём xslt решение. Что добавляет пользователь? Как трансформируется это добро?
Какая верстка будет получаться верстальщик и так имеет контроль — есть кнопка посмотреть на сгенерированное, а общую обёртку хедер-футер-итд он и так может на таблицах делать (хотя у нас всё сверстано нормально дивно, фактически используется стандартная верстка сайта с микроскопическими изменениями для корректной передачи в почту).
ты точно также не решаешь эту проблему, ибо контент-менеджер (кстати, какое ему вообще дело как это выглядит?) редактирует див, а пользователям рассылается этот див завёрнутый в пачку табличек с распорками. визуализация в любом случае будет отличаться.
впрочем, натравливаем на наш xslt такой шаблон:
[template match=" xsl:template "]
[value-of select=«h2» /] {
[value-of select=" .//html:*[1]/@style " /]
}
[/template]
и получаем на выходе css:
h2 {
color: red;
width: 100%;
}
впрочем, натравливаем на наш xslt такой шаблон:
[template match=" xsl:template "]
[value-of select=«h2» /] {
[value-of select=" .//html:*[1]/@style " /]
}
[/template]
и получаем на выходе css:
h2 {
color: red;
width: 100%;
}
«в любом случае будет отличаться» — пиксельное соответствие можно получить как дивной вёрсткой десятком способов так и табличной вёрсткой несколькими способами.
и хотя они будут все отличаться по байтам, их определяющими, итоговый рендер будет идентичен.
Я согласен, что через xslt _можно_ генерировать два разных вида — для редактора и для почты. Но это потребует создания трёх версток — 1) под редактор, 2) под почту, 3) сам xslt процессор, который становится не универсальным, а заточенным под задачу.
Другими словами — стоимость поддержки решения втрое выше чем 1 див верстка под все случаи жизни. Dixi.
и хотя они будут все отличаться по байтам, их определяющими, итоговый рендер будет идентичен.
Я согласен, что через xslt _можно_ генерировать два разных вида — для редактора и для почты. Но это потребует создания трёх версток — 1) под редактор, 2) под почту, 3) сам xslt процессор, который становится не универсальным, а заточенным под задачу.
Другими словами — стоимость поддержки решения втрое выше чем 1 див верстка под все случаи жизни. Dixi.
Для детального изучения какие тэги использовать можно, какие нет советую почитать www.campaignmonitor.com/css/
UFO just landed and posted this here
Sign up to leave a comment.
Почтовые рассылки на базе DIVной верстки: это возможно!