Caniemail.com - serviço de verificação de compatibilidade de conteúdo de e-mail (versão de e-mail do caniuse)

Suporte à propriedade CSS transition (29 de março de 2024)

• Resumo do status de suporte à propriedade CSS transition em clientes de e-mail
• A propriedade CSS transition permite aplicar um efeito de animação à mudança de valores de propriedades CSS ao longo de um determinado período de tempo
• Ainda não há suporte amplo nos clientes de e-mail

Suporte à propriedade CSS text-wrap (3 de abril de 2024)

• Resumo do status de suporte à propriedade CSS text-wrap em clientes de e-mail
• A propriedade CSS text-wrap define como palavras longas devem ser quebradas em linha
• Ainda não há suporte amplo nos clientes de e-mail

Suporte às propriedades CSS word-spacing, shape-margin, shape-outside (13 de março de 2024)

• Resumo do status de suporte às propriedades CSS word-spacing, shape-margin, shape-outside em clientes de e-mail
• word-spacing é a propriedade que ajusta o espaçamento entre palavras
• shape-margin e shape-outside são propriedades que definem como o texto contorna imagens ou outros elementos
• Ainda não há suporte amplo nos clientes de e-mail

Notícias de atualização do Caniemail de março de 2024 (29 de março de 2024)

• Notícias que resumem as atualizações adicionadas ao site Caniemail em março de 2024

Notícias de atualização do Caniemail de fevereiro de 2024 (29 de fevereiro de 2024)

• Notícias que resumem as atualizações adicionadas ao site Caniemail em fevereiro de 2024

Status de suporte a propriedades CSS em clientes de e-mail

• Apple Mail (macOS): 267 de 284 suportadas
• Apple Mail (iOS): 266 de 284 suportadas
• Samsung Email (Android): 239 de 284 suportadas
• SFR (Desktop Webmail): 226 de 257 suportadas
• WEB.DE (iOS): 222 de 235 suportadas

Introdução ao site Caniemail

• Site lançado e mantido por @HTeuMeuLeu e pela equipe da Tilt Studio
• Baseado no caniuse.com original de @Fyrd e com design de @Lensco
• Baseado na ideia e no nome originais de @M_J_Robbins e da equipe Rebel
• A comunidade de desenvolvedores de e-mail no GitHub apoia a contribuição de dados
• O site orienta a reportar bugs no GitHub caso haja algum problema

Opinião do GN⁺

• É um site muito útil para desenvolvedores de e-mail, pois permite visualizar de relance o status de suporte a propriedades CSS em cada cliente de e-mail. É um site indispensável para verificar compatibilidade ao aplicar novas propriedades CSS em e-mails.
• O suporte a CSS em clientes de e-mail ainda é bastante inferior ao dos navegadores web. Propriedades relacionadas a animação ou layout quase não são suportadas, o que acaba limitando o design de e-mails.
• Como o site publica atualizações regularmente, parece útil para que desenvolvedores de e-mail acompanhem as informações mais recentes. No entanto, o ritmo de atualização pode ser curto demais e difícil de acompanhar.
• Existem sites semelhantes como EmailOnAcid e Litmus, mas a diferença é que eles oferecem capturas de tela de pré-visualização de como o conteúdo é renderizado em cada cliente. Usados junto com o Caniemail, podem gerar um bom efeito de sinergia.

[GN⁺]

Comentários do Hacker News

• Excelente recurso, e o Outlook é realmente uma dor de cabeça, com suporte a pouquíssima coisa.
  Eu costumava sofrer ao criar templates de e-mail para notificações de apps da empresa, mas depois que mudei para MJML(https://mjml.io/), tudo fluiu muito melhor.
  Entre os vários dispositivos testados, o resultado parecia ter a melhor compatibilidade, e verifiquei a renderização em diversos apps e dispositivos com Litmus(https://litmus.com). Também usei o https://testi.at/ mencionado em outra thread, e funcionou bem.

  • MJML parece interessante. Seria bom se as organizações tivessem um motivo de negócio para se importar com e-mails acessíveis e legíveis por máquina.
    E-mails em HTML estão parados como a web na época do IE6; para as poucas tarefas de e-mail que exigem mais do que uma lista de tags de imagem, tenho usado Foundation for Emails(https://get.foundation/emails.html), e sou grato por ele existir.
  • MJML é disparado a melhor ferramenta nessa área, e eu a uso com frequência. Se você está criando e-mails em 2024, é um atalho importante para evitar ou reduzir as grandes dores de cabeça do e-mail em HTML.
  • Para criação de e-mails, também recomendo react-email(https://react.email). Os componentes oferecidos são suficientes, e é muito melhor do que montar e-mails colocando tags a cada cinco linhas, como nos velhos tempos de marketing por e-mail.
  • Parece que hoje o Outlook é o Internet Explorer dos e-mails.

• Há uma história engraçada sobre este site. O operador disse uma vez que havia muitos rastros nos logs de uso de pessoas que entenderam errado o objetivo do site, digitando nomes de celebridades e tentando enviar e-mails para elas.

  • No começo tentei entender do que se tratava, mas não encontrei muita explicação. Dizem que é “algo como o caniuse para conteúdo de e-mail”, mas, se você não sabe o que é caniuse, fica difícil entender.
    Antes de lançar um novo serviço, seria bom incluir uma breve seção explicando o que ele é de um jeito que uma pessoa comum consiga entender.

• Quanto menor a pontuação, melhor. Conheço bastante gente com a política de que “e-mail só deve permitir texto puro, anexos sem acordo prévio não são aceitos, e o restante é excluído automaticamente”.

  • Faz sentido expandir um pouco além do texto puro. Não é só uma questão de decoração: para usos como idiomas escritos da direita para a esquerda, listas e links, um pouco de marcação ajuda, e HTML é suficiente.
    O problema está no uso excessivo de CSS ou em permitir JavaScript. Não me vem à mente nenhum problema de segurança em e-mail causado apenas por HTML, sem CSS ou JavaScript.
  • Conheço pelo menos duas pessoas que enviam e-mails em que a versão HTML está vazia ou só diz “não use um cliente inchado”, enquanto o conteúdo real fica no corpo alternativo em texto puro.
    Acho que, para ler no Thunderbird, era preciso ver o código-fonte do e-mail.

• Links relacionados:
  Can I Email? - https://news.ycombinator.com/item?id=27112960 - maio de 2021, 273 comentários
  Can I Email: ‘Can I Use’ for email - https://news.ycombinator.com/item?id=20948826 - setembro de 2019, 196 comentários
  'Can I Use' for Email - https://news.ycombinator.com/item?id=20934601 - setembro de 2019, 1 comentário

• Os dois clientes mais populares, Gmail e Outlook, aparecem respectivamente em 25º e 41º lugar, ou seja, perto do fim da lista.

  • Olhando para os recursos que o Gmail não suporta, há coisas como display: none, animações e outros CSS que não parecem exatamente essenciais em e-mails.
    O básico está coberto, então uma posição alta no ranking talvez não seja necessariamente um bom objetivo.
  • Isso lembra o Internet Explorer, que era o mais popular, mas tinha poucos recursos.

• Um “documento” HTML com todos os recursos é, na verdade, mais próximo de uma aplicação do que de um documento, então faz sentido que clientes de e-mail limitem o suporte.
  Mas, por causa dessa fragmentação, eu gostaria que existisse um padrão de verdade. Precisamos de um subconjunto oficial de HTML não aplicativo, que não possa buscar recursos remotos nem executar código. Bastaria ser um formato de documento com mídia incorporada, animações, estilização etc.

  • Dá para chamar de “documento” algo que inclui animações e mídia de vídeo não estática?
  • Sinceramente, não há motivo para outras pessoas me enviarem código para executar ou recursos para buscar.
    Entendo que a indústria de adtech queira usar meu e-mail como outdoor, mas eu preferia que sumisse. Texto puro e anexos são suficientes.

• A propósito, jsx-email tem um recurso integrado de verificação de compatibilidade de clientes de e-mail via CLI usando o dataset do caniemail: https://jsx.email/docs/core/cli#check

• Acho que seria mais útil listar apenas as poucas propriedades CSS reconhecidas por todos os clientes de e-mail. Sem brincadeira, digo isso a sério.
  A resposta do CanIEmail? geralmente é “não”.

  • Em https://www.caniemail.com/clients/, se você selecionar “check all”, dá para ver separadamente os recursos compatíveis com todos os clientes de e-mail e aqueles com suporte divergente.
    O que parece ter suporte universal é, aproximadamente, border-collapse, o atalho font, list-style-type, várias unidades CSS (cm, em, ex, in, mm, pc, %, pt, px), vertical-align, alguns elementos HTML e o atributo valign, além dos formatos de imagem JPG/PNG.

• No começo achei que fosse um site de brincadeira que só mostrava “No.” em letras grandes.

  • Quando o time de design pede uma atualização nos templates de e-mail, minha resposta padrão normalmente também é essa. “Não dá. Só formatação básica. Se quiser ousar um pouco, talvez tabelas. Mais do que isso, não.”

• O suporte a modo escuro em e-mails está entre as coisas mais frustrantes que já enfrentei como desenvolvedor front-end que programa desde a era do IE6.
  Basicamente, resta implementar apenas o design em modo claro e escolher cores que ainda pareçam aceitáveis quando clientes de e-mail com modo escuro malfeito aplicam inversão automática.
  O Gmail é um dos piores casos. Não há absolutamente nenhuma forma de escolher diretamente as cores no modo escuro.