Les articles de la catégorie « Observations »

mercredi 4 mars 2015

Yahoo supporte les media queries

C’est la nouvelle de la semaine rapportée par FreshInbox : Yahoo supporte désormais officiellement les media queries. Précédemment, Yahoo filtrait les media queries, et les filtrait mal. Ainsi le code suivant…

@media only screen and (max-width:600px) {
	.box { width:auto; } 
	.box-title { font-size:1.25em; }
}

… était transformé en :

_filtered #yiv6851014585 {
}
	#yiv6851014585 .yiv6851014585box-title { font-size:1.25em; }
}

Yahoo prenait le contenu entre la première accolade ouvrante d’une media query et la première accolade fermante (correspondant à la première règle), et filtrait le tout. Les autres règles contenues dans la media query se trouvait alors appliquée quelque soit le medium. On utilisait alors des sélecteurs d’attributs dans les media queries pour éviter que les règles ne s’appliquent. Tout ça, c’est désormais terminé.

Et cette correction ne vient pas de nulle part. Il y a tout juste un mois, Justin Khoo a remonté le bug sur la plate-forme dédiée de Yahoo. Et en un mois seulement, Yahoo a fait la correction. C’est très encourageant de voir que Yahoo est prêt à faire ce genre de corrections.

L’autre bonne nouvelle, c’est que cette modification s’applique pour toutes les versions de Yahoo, soit le webmail desktop, mais aussi les applications iOS ou Android.

Tout n’est cependant pas tout rose. Yahoo ne supporte que les media queries basées sur min-width, max-width, min-height ou max-height. Les media queries basées sur min-device-width, min-device-height, max-device-width, max-device-height, -webkit-min-device-pixel-ratio ou même print seront filtrées.

Ainsi le code suivant…

@media only screen and (max-device-width:600px) {
	.box { width:auto; } 
}

… est transformé en :

@media screen and ( _filtered_a ) {
	#yiv6851014585 .yiv6851014585box { width:auto; } 
}

Un autre bug survient dès que l’on imbrique des media queries les unes dans les autres. Ainsi le code suivant…

@media only screen and (min-width:320px) {
	@media only screen and (max-width:480px) {
		.box { background:#001F3F; }
	}

	.box { background:#FF851B; }
}

… est transformé en :

@media screen and (min-width:320px) {
	@media screen and (max-width:480px)
	#yiv6851014585 .yiv6851014585box { background:#001F3F; }
}

#yiv6851014585 .yiv6851014585box { background:#FF851B; }
#yiv6851014585

Alors très clairement, je n’écris jamais de media queries comme cela (et j’ai du mal à imaginer des cas où ce serait indispensable de l’écrire comme ça). Mais cela pourrait devenir courant avec l’arrivée future de la spécification des Media Queries niveau 4.

Bravo quand même à Yahoo d’avancer dans la bonne direction. J’espère que ceci est le premier pas d’une longue marche.

lundi 2 mars 2015

Le webmail mobile de La Poste et le mot « body »

En refaisant des tests sur le webmail mobile de La Poste, je suis tombé par hasard sur un nouveau bug. Par défaut, le webmail mobile de La Poste remplace la balise <body> d’un e-mail par un <div class="tag_body">. C’est une pratique plutôt courante chez les webmails. Jusqu’ici tout va bien.

Afin d’ajuster les styles appliqués sur la balise <body>, le webmail de La Poste remplace aussi les sélecteurs body { } par div.tag_body { }. Jusqu’ici tout va bien.

Mais si la moindre de vos classes a le malheur de contenir le mot body isolé, alors elle sera également affectée par ce remplacement dans les styles. Ainsi un sélecteur .media-body sera transformé en .media-div.tag_body. Curieusement, cette transformation ne s’applique pas si le terme body est inclus dans un mot.

Ainsi le code suivant…

.body {  }
.media-body {  }
.everybody {  }

… est transformé en :

.wrapper_h8uftw div.tag_body {  }
.wrapper_h8uftw .media-div.tag_body {  }
.wrapper_h8uftw .everybody {  }

Afin d’éviter ce problème, je n’ai pas trouvé d’autre solution que d’éviter d’utiliser toute classe contenant le mot body.

dimanche 1 mars 2015

Le webmail mobile de La Poste et les liens Youtube et Dailymotion

Cette semaine je suis tombé sur une fonctionnalité bien particulière du webmail mobile de La Poste. Quasiment chaque lien vers Youtube ou Dailymotion est complété par l’ajout d’un lecteur intégré. Dans l’exemple suivant, j’ai mis un lien vers une vidéo Youtube, et un lien vers une recherche Youtube.

Ainsi, le code suivant…

<a href="http://www.youtube.com/watch?v=i6ft4GcaNPE">Un Zombie Dingo</a> sur <a href="http://www.youtube.com/user/WaltDisneyStudiosFR/search?query=Mickey+Mouse+Episode+int%C3%A9gral">Youtube</a>

… est transformé en :

<object width="250" height="200">
	<param name="movie" value="http://www.youtube.com/v/www.youtube.com&hl=fr&fs=1&rel=0">
	<param name="allowFullScreen" value="true">
	<param name="allowscriptaccess" value="always">
	<param name="wmode" value="transparent">
	<embed src="http://www.youtube.com/v/i6ft4GcaNPE&hl=fr&fs=1&rel=0" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" wmode="transparent" width="250" height="200">
</object>
<br>
<a href="http://www.youtube.com/watch?v=i6ft4GcaNPE" target="_blank" class="ui-link">Un Zombie Dingo</a> sur 
<object width="250" height="200">
	<param name="movie" value="http://www.youtube.com/v/www.youtube.com&hl=fr&fs=1&rel=0">
	<param name="allowFullScreen" value="true">
	<param name="allowscriptaccess" value="always">
	<param name="wmode" value="transparent">
	<embed src="http://www.youtube.com/v/user/WaltDisneyStudiosFR/search?query=Mickey+Mouse+Episode+int%C3%A9gral&hl=fr&fs=1&rel=0" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" wmode="transparent" width="250" height="200">
</object>
<br>
<a href="http://www.youtube.com/user/WaltDisneyStudiosFR/search?query=Mickey+Mouse+Episode+int%C3%A9gral" target="_blank" class="ui-link">Youtube</a>

Cette fonctionnalité part d’un bon sentiment. Mais dans la pratique, son implémentation est une véritable catastrophe. Et ça pose un certain nombre de problèmes :

Chaque balise <a> est directement précédée par l’insertion d’une balise <object> et d’un <br>. La mise en page de votre e-mail risque d’être déformée à cause de ça, que ce soit parce que vous avez mis un lien sur du texte ou autour d’une image.
Un lecteur est intégré même pour les liens qui ne correspondent pas à des vidéos (par exemple une page d’utilisateur, une page de recherche, ou n’importe quelle page statique de Youtube ou Dailymotion). Dans ce cas, rien ne fonctionne, et on se retrouve avec une zone vide à l’écran.
Le lecteur intégré utilise Flash. Pour un webmail sur mobile. J’aimerais bien rencontrer celui qui a eu cette idée de génie. Youtube parvient à renvoyer une version HTML5 de la vidéo à travers la balise <embed>. Mais pour Dailymotion, rien ne fonctionne si vous n’avez pas Flash Player installé.
Si vous avez Flash Player installé, le lecteur Youtube ne fonctionnera pas car l’URL en valeur du paramètre movie est erronée. (On a alors une balise <param name="movie" value="http://www.youtube.com/v/www.youtube.com">).

Je suis vraiment émerveillé par autant d’erreurs qui montrent que tout ceci n’a jamais du être testé une seule fois par la moindre personne chez La Poste.

Heureusement, je me suis rendu compte qu’on pouvait facilement éviter l’ajout du lecteur intégré. Pour cela, il suffit de préciser tous les liens vers Youtube et Dailymotion avec un protocole https, et non en http.

Je suppose que les développeurs du webmail n’ont même pas pris la peine d’écrire une regex permettant de gérer les deux cas. Et c’est tant mieux. Paradoxalement, leur incompétence (pour créer un tel filtre) nous sauve de leur incompétence (pour intégrer un lecteur vidéo).

dimanche 25 janvier 2015

Utiliser CSS dans Gmail

En août dernier, j’expliquais comment Gmail supporte bien la balise <style> et les media queries. Pas grand chose n’a changé du côté de Gmail depuis. Mais il s’avère que la compréhension collective des filtres opérés par Gmail a, elle, plutôt bien évolué. Quelques jours après la publication de mon précédent article, l’excellent FreshInbox a publié deux articles qui ont complètement changé ma compréhension de Gmail.

Dans le premier article, « Gmail supporte la balise <style>… en quelque sorte », Justin Khoo explique que simplement en ajoutant un sélecteur universel * devant une règle CSS, celle-ci ne sera pas supprimé. Dans mon précédent article, j’écrivais :

Malheureusement, Gmail supprime toute règle CSS contenant des pseudo-sélecteurs comme :first-child ou :nth-child().

C’est totalement faux ! Grâce à cette bidouille de sélecteur universel, on peut tout à fait utiliser des pseudo-classes. Si on prend par exemple le code suivant :

* div:first-child { background:red; }
* div:nth-child(2) { background:blue; }

Il sera transformé par Gmail ainsi :

div.m1479b618d2293d85 * div:first-child { background:red; }
div.m1479b618d2293d85 * div:nth-child(2) { background:blue; }

C’est déjà un grand pas en avant ! Mais ça signifie aussi qu’on peut aussi utiliser un sélecteur d’attributs. Et c’est là où les choses deviennent vraiment intéressantes.

Dans un article publié quelques jours après, Justin Khoo explique comment rendre un e-mail interactif dans Gmail en utilisant le sélecteur d’attributs. Grâce à la présence du sélecteur *, il utilise une règle avec la pseudo-classe :hover.

* [lang~="x-divbox"]:hover{
	background-color: green !important;
	color: white;
}

Comme Gmail supprime toute classe du code HTML, il détourne malicieusement l’attribut lang (qui lui n’est pas supprimé) pour cibler un élément en CSS. Est-ce que c’est sale ? Oui. Est-ce que ça fonctionne ? Oui.

Et c’est là où j’ai compris un truc. Le problème de Gmail, ce n’est pas son support de CSS, mais son support de HTML. En supprimant des attributs HTML de notre code, Gmail complique l’utilisation de CSS.

J’ai alors fait quelques tests afin de déterminer si d’autres attributs que lang ne pouvaient être utilisés, l’objectif étant de trouver un attribut qui puisse être utilisé à des fins de styles, mais sans incidence sur le rendu utilisateur. Malheureusement, Gmail supprime les attributs id, class ou data-*. Par contre, Gmail conserve les attributs title, alt, lang, mais aussi les attributs ARIA comme aria-labelledby.

J’ai rapidement écartés les attributs title et alt qui se retrouvent visibles facilement dans un navigateur. Et je reste alors partagé entre les attributs lang et aria-labelledby. D’après mes tests, une utilisation détournée de l’un ou de l’autre n’a pas d’incidence avec VoiceOver sous OS X. Cependant, un récent article d’Adrian Roselli met en garde contre l’utilisation détournée de l’attribut lang.

J’ai alors une préférence pour l’utilisation de aria-labelledby. Je suppose que si un lecteur d’écran ne trouve pas d’élément avec l’identifiant correspondant, il ignorera purement et simplement l’attribut (c’est bien ce qui se passe dans VoiceOver).

Voici un exemple de code fonctionnel dans Gmail avec cet attribut.

<div class="toto" aria-labelledby="toto">
	Ceci est un test.
</div>

.toto, * [aria-labelledby="toto"] { background:red; }

Ce code sera transformé comme ci-dessous par Gmail.

div.m1479b618d2293d85 .toto,div.m1479b618d2293d85 * [aria-labelledby="toto"]{background:red}

vendredi 22 août 2014

Outlook.com supporte bien les propriétés CSS Float et Margin

En janvier 2013, le monde entier découvrait avec effroi que le webmail Outlook.com (dans sa version desktop et mobile) supprimait systématiquement les propriétés CSS float et margin (et ses dérivées margin-top, margin-left, etc.). C’est fortement dommage, parce que des flottants et des marges, ça peut éventuellement servir en intégration (doux euphémisme).

Mais tout récemment, un tweet de Mark Robbins m’a mis la puce à l’oreille sur une faille insoupçonnée de ce filtrage d’Outlook.com. En fait, Outlook.com supprime simplement toute les propriétés float et margin. Mais pas Float et Margin. Ni floaT et margiN. Ni FlOaT et MaRgIn. Ou FLOAT et MARGIN. Vous avez compris l’idée : simplement en changeant la casse de la propriété, on arrive à passer au travers du filtrage d’Outlook.com. La syntaxe des propriétés CSS n’étant pas sensible à la casse, cela ne pose pas de problème de compatibilité ailleurs.

mardi 5 août 2014

Gmail supporte bien la balise <style> et les media queries

Une croyance courante dans l’intégration d’e-mails est de dire que Gmail ne supporte pas les styles ou le responsive design. En réalité, c’est un peu plus fin que ça. En avril dernier, EmailOnAcid rappelait que Gmail supporte bien la balise <style>.

Intrigué, j’ai fait mes petits tests, et je confirme : la version desktop du webmail Gmail conserve bien une balise <style> incluse dans le <head> d’un e-mail. Toutes les règles sont bien conservées, mais préfixées par une classe propre à Gmail. Ainsi le code suivant…

.toto { background:red; }

@media only screen and (max-width:600px) { 
	.toto { background:white; }
}

… sera transformé en :

div.m1479b618d2293d85 .toto { background:red; }

@media only screen and (max-width:600px) { 
	div.m1479b618d2293d85 .toto { background:white; }
}

Le hic (parce que forcément il y a un hic), c’est que Gmail supprime toutes les classes et identifiants au sein du code HTML de l’e-mail. Du coup, même si ces styles sont bien conservés, aucun n’est appliqué puisque plus aucune classe ou identifiant ne sont présents.

Mais du coup, ça signifie qu’on peut jouer sur des styles ciblant des balises. Par exemple, le code suivant transformé par Gmail sera bien appliqué dans votre e-mail :

div.m1479b618d2293d85 table td { background:red; }

On pourrait alors imaginer styler des éléments non plus par classe mais par leur position dans le code HTML. Malheureusement, Gmail supprime toute règle CSS contenant des pseudo-sélecteurs comme :first-child ou :nth-child().

Par contre, Gmail conserve bien les règles utilisant des sélecteurs d’éléments enfants ou adjacents, comme >, + ou ~. On peut alors jouer sur des combinaisons de balise pour cibler un élément en particulier. Par exemple, pour cibler le troisième tableau d’un e-mail, on pourrait créer la déclaration suivante :

table + table + table { background:red; }

Toutefois, cette règle s’appliquera aussi pour tout autre tableau précédé de deux tableaux (donc aussi le quatrième, le cinquième, etc.).

Mais surtout, ces bidouilles ne concernent que la version desktop du webmail Gmail. La version mobile de Gmail, ainsi que les applications iOS ou Android, continuent de supprimer toute balise <style>.

samedi 10 mai 2014

Les media queries sur le webmail mobile de La Poste, deuxième

Il y a du nouveau sur le webmail mobile de La Poste et son interprétation des media queries depuis mon précédent article. Mais ce n’est pas mieux pour autant.

Précédemment, je remarquais que le webmail mobile de La Poste supprimait systématiquement la première media query au sein d’une balise <style>, mais tout en conservant quand même les règles à l’intérieur de cette media query. J’ai remarqué cette semaine que ce problème avait été corrigé. La première media query n’est donc plus supprimée.

Mais, parce que forcément il y a un mais, celle-ci est désormais préfixée par le préfixe ajouté automatiquement par La Poste. Ainsi le code suivant…

.toto { background:red; }
.tutu { background:blue; }

@media only screen and (max-width:600px) {
	.toto { background:white; }
	.tutu { background:black; }
}

@media only screen and (min-width:320px) {
	.toto { color:white; }
	.tutu { color:black; }
}

… sera transformé par le webmail mobile de La Poste en :

.wrapper_h8ufTw .toto { background:red; }
.wrapper_h8ufTw .tutu { background:blue; }

.wrapper_h8ufTw @media only screen and (max-width:600px) {
	.toto { background:white; }
	.wrapper_h8ufTw .tutu { background:black; }
.wrapper_h8ufTw }

@media only screen and (min-width:320px) {
	.toto { color:white; }
	.wrapper_h8ufTw .tutu { color:black; }

Autrement dit, les règles contenues dans la première media query ne fonctionneront pas sur le webmail mobile de La Poste. Pour palier à ça, ma recommandation du précédent article fonctionne toujours : ajoutez systématiquement une media query avec une règle factice avant vos vraies déclarations :

@media only screen and (max-width:0) { 
	body { margin:0; } 
}

Au passage, j’ai remarqué deux autres points sur l’interprétation des styles par le webmail mobile de La Poste :

Si un bloc de styles se termine par une media query, l’accolade fermante de celle-ci sera supprimée (cf exemple ci-dessus).
La première règle suivant une media query ne sera pas préfixée.

mercredi 16 avril 2014

L’application E-mail affiche la balise <title> dans les notifications d’Android 4.4

Jolie trouvaille vue cette semaine sur Twitter : l’application E-mail par défaut d’Android (aussi connue sous le nom de « pas Gmail, l’autre ») affiche le contenu de la balise <title> dans les notifications du système.

J’ai réussi à reproduire ce problème facilement sur une Nexus 7 sous Android 4.4.2. Cela ne concerne que cette application, et que l’affichage en notification. Ce texte n’est retrouvable nulle part ailleurs une fois dans l’application.

Veillez à avoir un contenu de <title> pertinent pour éviter d’afficher un « Document sans titre » ou « Responsive template ».

mardi 8 avril 2014

Le préfixage des règles CSS par la version mobile d’Outlook.com

Contrairement à d’autres webmails, la version classique d’Outlook.com ne se débrouille pas trop mal quand il s’agit de préfixer les règles CSS contenues dans un e-mail. Par défaut, toutes les règles CSS seront préfixées d’une classe .ExternalClass, et tous les noms de classes ou d’identifiants seront préfixés par ecx. Ainsi le code suivant :

.toto { background:red; }
.tutu { background:blue; }

@media only screen and (max-width:600px) {
	table[class="toto"] { background:white; }
	table[class="tutu"] { background:black; }
}

… sera transformé en…

.ExternalClass .ecxtoto { background:red; }
.ExternalClass .ecxtutu { background:blue; }

@media only screen and (max-width:600px) {
	.ExternalClass table[class="ecxtoto"] { background:white; }
	.ExternalClass table[class="ecxtutu"] { background:black; }
}

La classe .ExternalClass est alors judicieusement apposée sur une <div> contenant l’e-mail, et tout fonctionne comme si rien ne s’était passé. Jusqu’ici tout va bien, et on a presque envie de remercier les développeurs de chez Microsoft d’avoir fait correctement leur travail. Là où ça se gâte, c’est dans la version web mobile d’Outlook.com.

La version web mobile d’Outlook.com procède exactement au même renommage et préfixage des règles CSS que la version classique du webmail. Sauf que les développeurs ont oublié d’ajouter la classe .ExternalClass quelque part dans l’interface. Cela signifie que plus aucune de vos règles CSS n’est applicable. Si vous souhaitez optimiser des e-mails pour mobile pour Outlook.com, il est donc impératif de jouer uniquement avec des styles en ligne.

D’un coup, comme ça, on n’a plus tout à fait la même sympathie pour les développeurs de chez Microsoft.

vendredi 21 mars 2014

Les media queries sur le webmail mobile de La Poste

Sur la version mobile du webmail de La Poste, il y a un bug important dans leur analyse des styles, et plus particulièrement des media queries. Peu importe le contenu de votre balise <style>, la première media query sera toujours supprimée. Et pire, les règles à l’intérieur de cette media query seront conservées, sauf la première qui elle sera totalement ignorée.

Concrètement, cela signifie que le code suivant…

.toto { background:red; }
.tutu { background:blue; }

@media only screen and (max-width:600px) {
	.toto { background:white; }
	.tutu { background:black; }
}

@media only screen and (min-width:320px) {
	.toto { color:white; }
	.tutu { color:black; }
}

… sera transformé par le webmail mobile de La Poste en :

.wrapper_h8ufTw .toto { background:red; }
.wrapper_h8ufTw .tutu { background:blue; }
.wrapper_h8ufTw .tutu { background:black; }
.wrapper_h8ufTw }

@media only screen and (min-width:320px) {
	.toto { color:white; }
	.wrapper_h8ufTw .tutu { color:black; }
.wrapper_h8ufTw }

Cela peut s’avérer très problématique, car on se retrouve avec des règles appliquées par défaut alors qu’elles devaient l’être uniquement dans une media query. (Vous apprécierez au passage le préfixage buggé évoqué précédemment.)

Pour éviter cela, on peut insérer une première media query, en prenant le soin d’ajouter quand même à l’intérieur une règle (sinon la media query sera ignorée, et le bug quand même présent). Attention, comme ce bug est bien spécifique au webmail de La Poste, cela signifie que cette media query sera interprétée par d’autres applications ou webmails. Il est donc impératif d’ajouter un code bidon qui n’aura pas d’impact sur les autres. On peut par exemple cibler un max-width:0.

En reprenant le code de l’exemple initial, on obtient alors le code suivant :

.toto { background:red; }
.tutu { background:blue; }

@media only screen and (max-width:0) { 
	body { margin:0; } 
} 

@media only screen and (max-width:600px) {
	.toto { background:white; }
	.tutu { background:black; }
}

@media only screen and (min-width:320px) {
	.toto { color:white; }
	.tutu { color:black; }
}

Le code final transformé par La Poste sera alors :

.wrapper_h8ufTw .toto { background:red; }
.wrapper_h8ufTw .tutu { background:blue; }

@media only screen and (max-width:600px) {
	.toto { background:white; }
	.wrapper_h8ufTw .tutu { background:black; }
.wrapper_h8ufTw }

@media only screen and (min-width:320px) {
	.toto { color:white; }
	.wrapper_h8ufTw .tutu { color:black; }
.wrapper_h8ufTw }