Caniemail.com - servicio para comprobar compatibilidad de contenido de email (versión para email de caniuse)

Compatibilidad de la propiedad CSS transition (29 de marzo de 2024)

• Resumen del estado de compatibilidad de la propiedad CSS transition en clientes de email
• La propiedad CSS transition permite aplicar un efecto de animación a los cambios de valores de propiedades CSS durante un período de tiempo determinado
• Todavía no cuenta con un soporte amplio en los clientes de email

Compatibilidad de la propiedad CSS text-wrap (3 de abril de 2024)

• Resumen del estado de compatibilidad de la propiedad CSS text-wrap en clientes de email
• La propiedad CSS text-wrap especifica cómo manejar el salto de línea en palabras largas
• Todavía no cuenta con un soporte amplio en los clientes de email

Compatibilidad de las propiedades CSS word-spacing, shape-margin, shape-outside (13 de marzo de 2024)

• Resumen del estado de compatibilidad de las propiedades CSS word-spacing, shape-margin, shape-outside en clientes de email
• word-spacing es una propiedad que ajusta el espacio entre palabras
• shape-margin y shape-outside son propiedades que especifican la forma en que el texto rodea imágenes u objetos
• Todavía no cuentan con un soporte amplio en los clientes de email

Novedades de actualización de Caniemail de marzo de 2024 (29 de marzo de 2024)

• Noticias que resumen las actualizaciones añadidas al sitio de Caniemail en marzo de 2024

Novedades de actualización de Caniemail de febrero de 2024 (29 de febrero de 2024)

• Noticias que resumen las actualizaciones añadidas al sitio de Caniemail en febrero de 2024

Estado de compatibilidad de propiedades CSS en clientes de email

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

Introducción al sitio Caniemail

• Sitio lanzado y mantenido por @HTeuMeuLeu y el equipo de Tilt Studio
• Basado en el caniuse.com original de @Fyrd y diseñado por @Lensco
• Basado en la idea original y el nombre creados por @M_J_Robbins y el equipo de Rebel
• La comunidad de desarrolladores de email en GitHub apoya la contribución de datos
• Indican que, si hay problemas, se reporten bugs en GitHub

Opinión de GN⁺

• Es un sitio muy útil para desarrolladores de email, ya que permite ver de un vistazo el estado de compatibilidad de propiedades CSS por cada cliente de email. Es un sitio imprescindible para revisar compatibilidad al aplicar nuevas propiedades CSS en emails.
• El soporte de CSS en clientes de email sigue siendo bastante limitado en comparación con los navegadores web. Las propiedades relacionadas con animaciones o layout casi no están soportadas, lo que termina siendo una limitación para el diseño de emails.
• Como publican novedades de actualización con regularidad, parece útil para que los desarrolladores de email se mantengan al día con la información más reciente. Aun así, el ritmo de actualizaciones puede ser tan corto que resulte difícil seguirlo.
• Hay sitios similares como EmailOnAcid y Litmus, pero la diferencia es que estos ofrecen capturas de pantalla de vista previa de cómo se renderiza en cada cliente. Usarlos junto con Caniemail podría generar un efecto de sinergia.

[GN⁺]

Opiniones de Hacker News

• Es un recurso excelente, y Outlook de verdad es un dolor de cabeza y soporta muy poco.
  Normalmente sufría al crear plantillas de email para notificaciones de apps de la empresa, pero después de cambiar a MJML(https://mjml.io/) todo salió mucho mejor.
  Entre varios dispositivos que probé, el resultado parecía tener la mejor compatibilidad, y verifiqué el renderizado en distintas apps y dispositivos con Litmus(https://litmus.com). También probé https://testi.at/, que apareció en otro hilo, y funcionó bien.

  • MJML se ve interesante. Ojalá las organizaciones tuvieran una razón de negocio para preocuparse por emails accesibles y legibles por máquinas.
    El email en HTML está congelado como la web de la época de IE6, así que para los pocos trabajos de email que requieren algo más que una lista de etiquetas de imagen he usado Foundation for Emails(https://get.foundation/emails.html), y agradezco que exista.
  • MJML es, por mucho, la mejor herramienta en este ámbito y la uso seguido. Si vas a crear emails en 2024, es un atajo importante que evita o reduce los grandes dolores de cabeza del email en HTML.
  • Para crear emails también recomiendo react-email(https://react.email). Los componentes que ofrece son suficientes y es mucho mejor que armar correos metiendo etiquetas cada cinco líneas, como en los viejos tiempos del email marketing.
  • Parece que hoy Outlook es como el Internet Explorer del correo.

• Hay una anécdota graciosa sobre este sitio. Su operador dijo alguna vez que en los logs de uso había muchos rastros de personas que malinterpretaron el propósito del sitio, escribieron nombres de famosos e intentaron enviarles emails.

  • Al principio intenté entender qué era esto, pero no encontré mucha explicación. Dicen que es “algo como caniuse para contenido de email”, pero si no sabes qué es caniuse, es difícil entenderlo.
    Antes de lanzar un servicio nuevo, estaría bien incluir una breve sección explicativa para que una persona promedio pueda saber de qué se trata.

• Mientras más bajo sea el puntaje, mejor. Conozco a bastante gente con la política de que “el email solo permite texto plano, no se aceptan adjuntos sin acuerdo previo, y el resto se elimina automáticamente”.

  • Tiene sentido extenderse apenas un poco más allá del texto plano. No es solo una cuestión de decoración: para usos como idiomas que se escriben de derecha a izquierda, listas y enlaces, un poco de marcado ayuda, y HTML basta.
    El problema está en usar CSS en exceso o directamente permitir JavaScript. No se me ocurre ningún problema de seguridad de email causado por HTML solo, sin CSS ni JavaScript.
  • Conozco al menos a dos personas que envían emails cuya versión HTML está vacía o solo dice “no uses clientes inflados”, mientras que el contenido real está en el cuerpo alternativo en texto plano.
    Creo que para leerlos en Thunderbird había que ver el mensaje original del email.

• Enlaces relacionados:
  Can I Email? - https://news.ycombinator.com/item?id=27112960 - mayo de 2021, 273 comentarios
  Can I Email: ‘Can I Use’ for email - https://news.ycombinator.com/item?id=20948826 - septiembre de 2019, 196 comentarios
  'Can I Use' for Email - https://news.ycombinator.com/item?id=20934601 - septiembre de 2019, 1 comentario

• Los dos clientes más populares, Gmail y Outlook, están en los puestos 25 y 41 respectivamente, es decir, entre los últimos.

  • Si miras las funciones que Gmail no soporta, hay cosas como display: none, animaciones y otros CSS que difícilmente dirías que son indispensables en un email.
    Lo básico está cubierto, así que una posición alta no necesariamente sea un buen objetivo.
  • Me recuerda a Internet Explorer, que era el más popular pero tenía pocas funciones.

• Un “documento” HTML con funcionalidad completa en realidad no es un documento, sino algo más cercano a una aplicación, así que tiene sentido que los clientes de correo limiten el soporte.
  Pero por esta fragmentación, ojalá hubiera un estándar real. Hace falta un subconjunto oficial de HTML no aplicativo que no pueda traer recursos remotos ni ejecutar código. Bastaría con un formato de documento con medios incrustados, animaciones, estilos, etc.

  • ¿Se puede llamar “documento” a algo que incluye animaciones y medios de video no estáticos?
  • Sinceramente, no hay razón para que otros me envíen código para ejecutar o recursos para traer.
    Entiendo que la industria de la tecnología publicitaria quiera usar mi email como cartelera, pero que se vayan al diablo. Con texto plano y adjuntos alcanza.

• Como referencia, jsx-email trae integrada una función de verificación de compatibilidad de clientes de email por CLI que usa el dataset de caniemail: https://jsx.email/docs/core/cli#check

• Creo que sería más útil listar solo las pocas propiedades CSS que reconocen todos los clientes de email. No lo digo en broma, lo digo en serio.
  La respuesta de CanIEmail? casi siempre es “no”.

  • En https://www.caniemail.com/clients/, si eliges “check all”, puedes ver por separado las funciones que soportan todos los clientes de email y las funciones cuyo soporte varía.
    Lo que parece estar soportado por todos es, más o menos, border-collapse, la abreviatura font, list-style-type, varias unidades CSS (cm, em, ex, in, mm, pc, %, pt, px), vertical-align, algunos elementos HTML y el atributo valign, y formatos de imagen JPG/PNG.

• Al principio pensé que era un sitio de broma que solo mostraba “No.” en letras grandes.

  • Esa suele ser también mi respuesta por defecto cuando el equipo de diseño pide actualizar plantillas de email. “No se puede. Solo formato básico. Si quieren arriesgarse un poco, quizá tablas. Más que eso, no”.

• El soporte de modo oscuro en email es de las cosas más frustrantes que me han tocado como desarrollador frontend que viene codeando desde la época de IE6.
  Básicamente no queda más que implementar solo el diseño en modo claro y elegir colores que se vean aceptables incluso cuando clientes de email con modo oscuro mal hecho los invierten automáticamente.
  Gmail es uno de los peores casos. En modo oscuro no hay ninguna forma de elegir los colores directamente.