Dónde se aplica la corrección
En el momento de la generación, y de forma idéntica para los cinco casos: el envío de una campaña, el envío de una secuencia, un envío de prueba, la vista previa del editor y una generación solicitada mediante la API. Dos consecuencias. Las plantillas y campañas guardadas hace tiempo se benefician sin tocarlas: el HTML se genera cuando se envía, no cuando se escribe. Y no hay que corregir nada plantilla por plantilla.Qué le hace a tu documento
- Se inyecta un bloque
@media (prefers-color-scheme: dark), con declaraciones!important, para que pueda imponerse a tus estilos en línea sin que el producto tenga que analizar tu HTML. - Outlook.com se gestiona mediante sus propios ganchos (
[data-ogsc],[data-ogsb]), que sustituye por clases en modo oscuro. - Gmail ignora
prefers-color-schemepor completo y aplica su propia inversión parcial. Se cubre de otra manera: todo elemento que lleva un fondo recibe un color de texto explícito. - Las etiquetas meta
color-schemeysupported-color-schemesse añaden solo cuando las reglas oscuras van con ellas, y se quitan cuando no es posible.
color-scheme le dice al cliente "yo me encargo del oscuro", así que deja de aplicar su propia inversión, que al menos invertía fondo y texto a la vez. Sin nada detrás de la promesa, el fondo se oscurece y el texto sigue negro. La declaración sola es peor que nada.
Un
!important en línea deja tu documento fuera de alcance. Una regla en un bloque <style>
gana a un estilo en línea, pero no a un estilo en línea que es a su vez !important. Frente a
style="background-color:#ffffff !important" la corrección pierde: el fondo sigue blanco
mientras el texto se aclara. Quita el !important de tus colores en línea.Avisa, nunca bloquea
Cuando el generador encuentra un par de colores arriesgado, lo corrige y lo dice. Ningún envío se rechaza nunca por el contraste. Existen tres avisos: el contraste se corrigió, no se pudo verificar, o se quitó una declaracióncolor-scheme porque no se pudieron producir las reglas que la respaldan.