Ого! На деалкстреме он $345.60 аж, меньше 10 — тогда проблем с таможней нет.
Запросил еще цену на алибабе у Siglent'а напрямик. Может, в 300 уложится :)
Будет отцу подарок на ДР.
Ни разу до сих пор с отказом доставки не встречался. По крайней мере, из Гонконга кто.
Ну и качество — если 99.8 с возрастом в несколько лет — да нет никаких проблем :)
Но вообще, алибаба рулит для восточного рынка, надёжней ебея.
Да ебей и алибаба не хуже. Я за этот месяц понабрал столько, что уже стыдно перед женой.
При этом я с железом не вожусь, возится отец, я только ПО к результату пишу…
Черт. Я так с вашими статьями все деньги солью на непонятные шняги! (Ушел на алибабу исследовать цены на сервы. А то старые шаговики из 5" флоповодов заканчиваются)
«в любом случае будет отличаться» — пиксельное соответствие можно получить как дивной вёрсткой десятком способов так и табличной вёрсткой несколькими способами.
и хотя они будут все отличаться по байтам, их определяющими, итоговый рендер будет идентичен.
Я согласен, что через xslt _можно_ генерировать два разных вида — для редактора и для почты. Но это потребует создания трёх версток — 1) под редактор, 2) под почту, 3) сам xslt процессор, который становится не универсальным, а заточенным под задачу.
Другими словами — стоимость поддержки решения втрое выше чем 1 див верстка под все случаи жизни. Dixi.
Ну вот смотри. Пользователю надо добавить заголовок.
В гуёвом редакторе он жмёт кнопку h2. Добавляется h2.
Он видит сразу какие стили применены.
Отсылает письмо — видит то же самое.
Открывает опять редактор — там всё еще h2, и он всё еще может его изменить. Например — заменить на h3.
Теперь берём xslt решение. Что добавляет пользователь? Как трансформируется это добро?
Какая верстка будет получаться верстальщик и так имеет контроль — есть кнопка посмотреть на сгенерированное, а общую обёртку хедер-футер-итд он и так может на таблицах делать (хотя у нас всё сверстано нормально дивно, фактически используется стандартная верстка сайта с микроскопическими изменениями для корректной передачи в почту).
О да, забыл сказать о самом важном: position запрещены. Почему — для меня загадка, казалось бы — оборачивающему диву с письмом поставить overflow: hidden и проблема перекрытия элементов интерфейса элементами письма исчезает.
Во-1х найти хорошего верстальщика на дивах в разы проще, чем найти XSLT программиста.
Во-2х все стили придётся верстать другим образом, не в CSS а в XML, иначе их XSLT не обработать.
В общем, плясок с бубнами получится в разы больше. И смысл?
Зависимость от font-size я не видел ни разу. Думаю, это из-за слишком маленького шрифта.
Они стараются проверять наличие «невидимого» текста (display: none или там color: white; background: white, и другие варианты) — и при наличии невидимого маркируют как спам, ибо это обычная практика спама.
Я не говорю, что нельзя. Их можно и даже нужно. Вот только стоимость поддержки табличной почтовой рассылки значительно выше поддержки дивной верстки. При том, что результат после пост-обработки может быть идентичным с изначально табличным. Так зачем интимиться больше?
Типичная верстка имеет такие пути:
/some.html
/styles/screen.css
/images/somepic.png
относительный путь из html это images/somepic.png
относительный путь из css это ../images/somepic.png
Не работает потому, что тот же гугль прост вырезает url() из всех стилей жестко. Путем выкидывания атрибута, в котором встречается url()
Я был бы согласен, если бы не убогость и неудобство использования меркуриала с ветками вообще.
И единственное достоинство — принудительный трекинг ветки — решается административным способом — заставлением писать номер бага в комментариях.
Запросил еще цену на алибабе у Siglent'а напрямик. Может, в 300 уложится :)
Будет отцу подарок на ДР.
Ну и качество — если 99.8 с возрастом в несколько лет — да нет никаких проблем :)
Но вообще, алибаба рулит для восточного рынка, надёжней ебея.
При этом я с железом не вожусь, возится отец, я только ПО к результату пишу…
и хотя они будут все отличаться по байтам, их определяющими, итоговый рендер будет идентичен.
Я согласен, что через xslt _можно_ генерировать два разных вида — для редактора и для почты. Но это потребует создания трёх версток — 1) под редактор, 2) под почту, 3) сам xslt процессор, который становится не универсальным, а заточенным под задачу.
Другими словами — стоимость поддержки решения втрое выше чем 1 див верстка под все случаи жизни. Dixi.
В гуёвом редакторе он жмёт кнопку h2. Добавляется h2.
Он видит сразу какие стили применены.
Отсылает письмо — видит то же самое.
Открывает опять редактор — там всё еще h2, и он всё еще может его изменить. Например — заменить на h3.
Теперь берём xslt решение. Что добавляет пользователь? Как трансформируется это добро?
Какая верстка будет получаться верстальщик и так имеет контроль — есть кнопка посмотреть на сгенерированное, а общую обёртку хедер-футер-итд он и так может на таблицах делать (хотя у нас всё сверстано нормально дивно, фактически используется стандартная верстка сайта с микроскопическими изменениями для корректной передачи в почту).
Во-2х все стили придётся верстать другим образом, не в CSS а в XML, иначе их XSLT не обработать.
В общем, плясок с бубнами получится в разы больше. И смысл?
Они стараются проверять наличие «невидимого» текста (display: none или там color: white; background: white, и другие варианты) — и при наличии невидимого маркируют как спам, ибо это обычная практика спама.
Что делать, чтобы не падало в спам хорошо видно вот тут:
mail.google.com/support/bin/answer.py?hl=ru&answer=81126
Да, более сложная, но число геморроя с рассылкой после введения фильтра упало значительно.
/some.html
/styles/screen.css
/images/somepic.png
относительный путь из html это images/somepic.png
относительный путь из css это ../images/somepic.png
Не работает потому, что тот же гугль прост вырезает url() из всех стилей жестко. Путем выкидывания атрибута, в котором встречается url()
И единственное достоинство — принудительный трекинг ветки — решается административным способом — заставлением писать номер бага в комментариях.