Version 11 — Mars 2012 — YannX
attention, un autre script est utilisé depuis le commit 54539 puis a finalement a été reverté donc finalement c’est bien le script dont il est question ici qui devrait être utilisé
Facteur est un script bien utile mais pas tout jeune et apparemment non maintenu, qui utilise un vieux script pas maintenu non plus pour transformer les css en css inline. Cette page documente la manière de coder les CSS dans un squelette de mails de manière à ce que le script puisse faire son boulot. Il porte en général sur les spécificités des CSS pour ce script donc, et non sur les spécificités du HTML et des CSS pour les mails en général (mais des liens plus bas portent sur cet autre sujet).
Tout n’est pas possible, les syntaxes officiellement supportées pour les CSS des mails sont les suivantes :
TAG { ... }
TAG1, TAG2, ... { ... }
TAG.class { ... }
.class { ... }
TAG:pseudo { ... }Les éléments dans le html peuvent être stylés avec l’attribut style=« ... » à condition que la valeur utilise les doubles quotes et pas les simples quotes, pour une bonne combinaison avec les styles mis inlines.
La doc indique que les styles suivants ne sont pas supportés :
- chaînes P UL LI { .... } or P UL LI.class { .... } ( 3 ou plus noms enchainements)
- #divname p { ... } and <tag id="...">
- a:hover, a:visited {...} multiple class:pseudoJLuc : toute combinaison avec 3 noms ou plus de tags ou de classes sur une ligne avant le { n’est pas supportée.
Précisions de l’auteur :
- la définition des styles doit être dans la partie HEAD
- les pseudo-classes comme a:hover {...} ne peuvent pas être mises inline : le script les déplace donc dans une déclaration de <style> créée au début du <body>. C’est une limitation du HTML, pas du script.
- Les définitions CSS peuvent être formattées comme on veut (espaces, tabulations, fins de ligne...). Le script les transforme en définitions tenant sur une même ligne pour les insérer inline dans les tags html du mail.
- Les definitions de classes (par exemple : .maclase {...}) sont traitées APRES les définitions de tags HTML (par exemple SPAN {...}, et sont donc insérées inline après les styles inlines des tags, de manière à préserver la priorité normale des CSS.
- il faut vérifier le rendu sur des clients mails différents, surtout pour les webmails qui souvent ne traitent qu’une très petite partie des styles habituellement utilisables dans une page html.
JLuc : Par ailleurs, les gestionnaires de mails suppriment (mystérieusement) le . devant un nom de classe dans un bloc de définition de CSS. Il faut donc ruser. Pour contourner : au lieu de .maclasse, s’arranger pour définir plus précisément : div.maclasse afin que le . ne soit pas supprimé.
La détection se fait par une regexp :
preg_match_all ( "/^[ \t]*([.]?)([\w, #]+)([.:])?(\S*)\s+{([^}]+)}/mi", $this->Body , $styles);JLuc : A première vue, le code est opaque. Vérifier la regexp et son traitement détaillé dans les recoins des ifs then else. Il faudrait définir ce que ça fait et ne fait pas et le faire ou manifester de manière plus claire. ç’a n’a pas l’air parfaitement au point - mais là j’arrive pas à débuguer là car aucun match ne se fait, je sais pas pourquoi !
- http://www.campaignmonitor.com/css : quelle css est supportées par quels visionneurs de mails
- http://www.pompage.net/pompe/cssemail : on y découvre que c’est habituel de supprimer le . dans la définition du style d’une classe, qui perd ainsi tout son sens.