Tableless em emails
Marcio Ghiraldelli
Faço aquele layoutzinho lindo, tudo em div, css, etc.
Daí preciso enviar esse conteúdo por email. Leitores de email (gmail, no caso, pois não uso outros) não aceitam classes CSS, o que faz sentido, senão você poderia quebrar todo o webmail redeclarando tags.
Reescrevo tudo em tabelas e fica lindo, resolve o problema.
Qual o defensor que vai me resolver o "reescrevo tudo"?
E não me venham com aquela solução de trazer todo o CSS inline, pois é nojento.
Guilherme David da Costa
Qual o defensor que vai me resolver o "reescrevo tudo"?
E não me venham com aquela solução de trazer todo o CSS inline, pois é nojento.
Na minha opinião é melhor um CSS inline do que um e-mail html sem estrutura, mas
como eu não entendo muito disso, então vou guardar essa opinião.
Marcio Ghiraldelli
Fica totalmente inadministrável (o que eu defini como nojento)
diego nunes
> (...) Leitores de email (gmail, no
> caso, pois não uso outros) não aceitam classes CSS, o que faz sentido, senão
> você poderia quebrar todo o webmail redeclarando tags.
Pois cabe ao webmail limitar isso. O webmail que eu administro
aceita qualquer formatação css sem ser inline, renderiza perfeito e
não permite que você alopre com o design.
O GMail e qualquer outro webmail pode fazer o mesmo (acho que o
Yahoo faz), é só querer.
--
diego nunes
dnunes.com
Antonio Jozzolino
--
Antonio Jozzolino
www.sgd.com.br
Marcio Ghiraldelli
body {
color: pink;
}
Jonas Raoni
> Mas... como esse seu webmail limita redefinição de tag? Tipo:
Manda em txt, eu ficarei feliz haha xD
--
Se deus é o caminho, Edir Macedo é o pedágio
Jonas Raoni Soares Silva
http://jsfromhell.com
Lúcio Kleber
que se chama ESP e lá existem recomendações para desenvolvimento para
os diversos ou mais utilizados leitores de e-mail, segue.
http://www.email-standards.org/
Abraços a todos e ótema pascoa, ;)
Marcio Ghiraldelli
Eu estou lançando um desafio aos defensores carnais do tableless pra solucionar esse problema de duplo desenvolvimento na situaão acima, pois já me ocorreu mais de uma vez.
Ah, podem responder depois da Páscoa! Só estou até agora postando na lista pq estou lançando um site de e-commerce compricado... estou doido pra ir comer meus chocolates e tomar cerveja! (não necessariamente nessa ordem)
[]s e feliz páscoa!
Camilo Oliveira
Funciona.
--
Camilo Oliveira
Design Coletivo - http://designcoletivo.com
Portfólio - http://www.camilo87.com
Conexão Needforlumbriga - http://conexao.needforlumbriga.com
Lúcio Kleber
sugiro que siga o conselho do amigo Camilo, seria inviável ?
Abrax
On 20 mar, 19:15, "Marcio Ghiraldelli" <marcio...@gmail.com> wrote:
> Eu já vi esse projeto email-standards... meu problema é: meu HTML foi
> desenvolvido sem prever que seria enviado por e-mail. Depois apareceu a
> necessidade. Se eu soubesse que seria necessário enviar por e-mail,
> obviamente teria feito um CSS bem simplezinho, bem próximo à um TXT. Ou
> melhor ainda, teria feita uma tabelona logo de vez, que funciona na web e
> email perfeitamente.
>
> Eu estou lançando um desafio aos defensores carnais do tableless pra
> solucionar esse problema de duplo desenvolvimento na situaão acima, pois já
> me ocorreu mais de uma vez.
>
> Ah, podem responder depois da Páscoa! Só estou até agora postando na lista
> pq estou lançando um site de e-commerce compricado... estou doido pra ir
> comer meus chocolates e tomar cerveja! (não necessariamente nessa ordem)
>
> []s e feliz páscoa!
>
Camilo Oliveira
Nas opções do slice dá até pra colocar texto alternativo em cada slice.
Nojento, porco, mas funciona.
diego nunes
> Mas... como esse seu webmail limita redefinição de tag? Tipo:
>
> body {
> color: pink;
> }
Eu leio de um servidor IMAP e, antes de exibir, uso expressões
regulares para reescrever as regras do usuário.
Todos os seletores do CSS contido no email são prefixadas com um
"#ID", onde ID é o ID da div que exibe o email. Também é necessário
reescrever algumas regras-base (como o caso do "body", que passa a ser
aplicado a outro elemento) e precisa-se adaptar alguns nomes de
classes/IDs dos elementos no email para evitar que se choquem com as
classes/IDs já usados no webmail (se o email contiver um <p
id="menu">, não se deve aplicar a formatação do menu pra ele também,
naturalmente).
No fim das contas é mais simples do que parece. Pra manter os
"position: absolute" da formatação funcionando, a div que engloba a
mensagem tem um "position: relative;", e pra evitar que o usuário, com
um "position: absolute; top: -900px;" faça que outras coisas fiquem
sobrevoando a interface, usa-se uma div um "overflow: hidden;" na
mesma div que engloba tudo.
--
diego nunes
dnunes.com
MultiPage
Se vc não quer declarar no código, sempre vai esbarrar em questões de
segurança, pois está "incluindo" um objeto externo.
O lançe é criar um padrão bem enxuto e declarar no código mesmo. Eu
também não gosto disso.
Rochester oliveira
funcionará (a não ser que o usuário só leia email em modo texto).
Se o problema é te "convencer" que usar padrões não é ter trabalho
dobrado, cabe a você pesquisar por exemplo a imcompatibilidade de
browsers, a acessibilidade, o peso dos arquivos, a otimização pra
buscas..
Agora com o lançamento do IE8 então.. não use padrões e aprecie o
desastre :) (IE6 + IE7 + IE8 ao mesmo tempo com participação razoável
no mercado.. algo no mínimo perigoso, certo? :D)
[]'s
Irapuan Martinez
> Essa é para os defensores do tableless:
Essa que vou responder é para os defensores que e-mail precisa de layout.
A arte do web design consiste em achar complicadores como soluções de
problemas que não existem.
Mande a mensagem sem formatação. Simples, fim do problema.
"Ah, mas o cliente quer a parada".
Então o problema não são os e-mail clients que não suportam o CSS. O
seu cliente que está mal instruído, achando que a lindura dos spam,
digo, e-mail marketing com opt-in que ele recebe e vê direitinho, não
gera ônus enorme.
Pra começo de conversa, eu nem entendo porque empresas mandam e-mail.
Usam aquele linguajar impessoal de "Senhor(a)". E tem a plena
convicção que a mensagem é irrelevante, por isto quer confeitar com a
imagem.
E o fluxograma é assim: Eles criam e reparam os erros que aparecem em
seus próprios e-mail clients. Na hora que está perfeito na plataforma
particular deles, despacham a mensagem. Daí então dizem que o mercado
está em recessão para justificar o baixo recall.
Vamos ignorar que a conexão sem fio em aparelhos portáteis é uma
realidade. Que apenas nivelando por baixo a formatação, assegura a
acessibilidade. O que obriga a caprichar na relevância.
Mas como assumir perante ao cliente que o principal motivo do seu
trabalho, o produto do Photoshop, é irrelevante?
Por isso querem que e-mail clientes se comportem como browsers.
Irapuan Martinez
> Eu estou lançando um desafio aos defensores carnais do tableless pra
> solucionar esse problema
Nossa, estou me sentido tão incentivado a resolver o seu problema pessoal.
Irapuan Martinez
> Fatia com os slices do Photoshop e dá um Save for Web, HTML e Images.
> Funciona.
Exceto que o tamanho da mensagem irá multiplicar por 40.
Agora multiplique isto por 1000 vítimas de spam, digo, assinantes de
opt-in. Considerando que o protocolo do e-mail não é HTTP, considere o
consumo de banda. Considere o consumo de banda das mensagens que irão
retornar, por gente que usa filtros automáticos que detectam e-mail
formato como sintoma de spam.
:: guFigueiredo
colou. Mal mal dá pra estilizar algumas coisas.....mas usar DIV...vai
tentar vai... eu mesmo já passei inúmeras dores de cabeça tentando
adaptar...e sempre acaba que quebra num leitor aqui ou ali. Não é tão
simples igual adaptar um site pra rodar no IE6, IE7 e Firefox. É
muito, mais muito mais dor de cabeça.
Infelizmente, a velha e inutilizável tabela ainda é á salvação de
todos os problemas, pelo menos neste caso.
Emanuel Santos Lima
+55 85 8831 08 25
Quique
newsletters e imagens na web não tem outro jeito, nem o css inline as
veces pega. Muita imagem e pouca formatação e o meu conselho sempre
que não possa ser enviado o email como texto.