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 :

1. 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.
2. 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.
3. 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é.
4. 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).

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}

L’équipe de Inbox (le nouveau client mail de Gmail) participe à un AMA sur Reddit. À la question « Prévoyez-vous de supporter des e-mails responsive ? », Jason Cornwell (Lead Designer) répond :

Nous sommes intéressé pour supporter les media queries mais nous devons être sûrs de faire les choses correctement. Nos changements l’an dernier pour afficher les images par défaut dans Gmail étaient similaires : il y avait une tonne de travail compliqué lié à la sécurité qui devait se faire en coulisse avant que nous puissions rendre cette fonctionnalité en apparence simple sûre pour tout le monde. Vous pouvez en lire plus sur ce lancement ici : http://goo.gl/pJavzw

Après la récente regression de l’application Gmail sur Android 5, voici enfin un signe d’espoir de changement positif.

Comme je le craignais le mois dernier, la mise à jour d’Android 5.0 (Lollipop) force tous les utilisateurs de l’application E-mail à utiliser Gmail. L’icône de l’application E-mail est toujours présente dans le système, mais l’application n’affiche plus qu’un message invitant à basculer sur Gmail (merci à @YannDecoopman pour la capture d’écran). Cette modification ne concerne pas les précédentes versions d’Android (vous pouvez donc continuer à utiliser Gmail 5 et l’application E-mail sur Android 4.4).

Comme évoqué précédemment : c’est une très mauvaise nouvelle. Pour s’en convaincre, il suffit de comparer le support de CSS entre Android 4 et Gmail dans le gros tableau récapitulatif de CampaignMonitor. Pas de <style> dans le <head>, donc pas de media queries, et pas non plus de propriétés display et position. Ça signifie aussi que si vous vous basiez sur des bibliothèques toutes faites, comme Ink (de Zurb), vos e-mails s’afficheront comme ça pour tout le monde sur Android 5.

Le seul point positif, c’est que l’adoption des nouvelles versions d’Android est habituellement très très lente. Au 3 novembre 2014, seuls 30,2 % des utilisateurs de Google Play sont sur Android 4.4 (KitKat), sorti le 4 novembre 2013.

Dans la série « tout peut changer du jour au lendemain », cette semaine Yahoo.com a décidé d’arrêter de supporter la propriété display:none lorsqu’elle est appliquée directement en ligne via l’attribut style d’une balise HTML. C’est Mark Robbins qui l’a remonté sur les forums de Litmus. La propriété n’est cependant pas filtrée si elle est utilisée dans une balise <style> dans le <head>, ou si elle a comme valeur block. Ce changement ne concerne que le webmail desktop de Yahoo, et pas par exemple l’application mobile sur iOS.

Cette semaine, Google a fait deux annonces importantes en rapport à ses clients mail.

La première, c’est que Gmail 5.0 supportera n’importe quel compte POP, IMAP ou Exchange. L’application sera disponible sur Android 5.0 à partir du 3 novembre prochain sur certains appareils. Il semblerait que Google en profite pour pousser les utilisateurs de l’application Mail native d’Android à migrer vers l’application Gmail (en témoigne cette capture d’écran issue de ce fil de discussion chez Litmus). Si c’est le cas, c’est une très mauvaise nouvelle, car l’application Mail d’Android propose un excellent support de CSS (styles dans le <head>, media queries, …), alors que Gmail est exactement l’inverse.

L’autre nouveauté de la semaine, c’est Google Inbox, une « nouvelle boîte de réception » réservée aux comptes Google, avec un client webmail, une application iOS, une application Android et un plugin Chrome. Malheureusement, le support de CSS est exactement celui de Gmail (et donc, pas terrible, si vous avez bien lu le paragraphe précédent).

Si l’optimisation de vos e-mails pour mobile repose uniquement sur des media queries, je ne saurais que trop vous conseiller de changer ça rapidement.

Cette semaine j’ai eu la chance de donner à Paris Web une conférence sur l’intégration d’e-mails intitulée « Comment sortir l’intégration d’e-mails de la préhistoire ». La vidéo est disponible en ligne, et j’ai publié mes slides annotés.

Voici en complément plein de liens et ressources sur les différents sujets abordés (dans l’ordre abordé lors de ma conférence).

Lire la suite