Revisiting Style Resets in Email
Jason Rodriguez présente son reset de styles pour des e-mails. C’est plutôt complet et pertinent.
Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.
Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.
E-mails responsive et Android 5.0
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.
Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.
Yahoo ne supporte plus la propriété display:none en ligne
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.
Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.
« Regarde toutes les minorités »
Le mois dernier, je suis tombé via Twitter sur cette excellente conférence TED de Maysoon Zayid, une comédienne atteinte de paralysie cérébrale qui raconte son parcours face au ressenti de son handicap. C’est vraiment l’une des meilleures conférences TED que j’ai regardé ces dernières années. Voici quelques morceaux choisis :
S’il y avait des Jeux Olympiques de l’Oppression, je gagnerais la médaille d’or. Je suis Palestinienne, Musulmane, je suis une femme, je suis invalide, et je vis dans le New Jersey. […]
J’ai eu une bourse pour l’Université d’État d’Arizona, parce que je remplissais chacun des quotas. […]
Les gens avec des handicaps constituent la plus grande minorité au monde, et nous sommes les plus sous-représentés dans le spectacle. […]
En l’écoutant, ça m’a rappelé un sketch de Louis C.K. (qui avait fait le tour du web en image) :
J’ai lu quelque chose dans le journal qui m’a vraiment embrouillé l’autre jour. Ça disait que 80 % des habitants de New York sont des minorités…
Est-ce qu’on ne devrait pas arrêter de les appeler « minorités » quand elles représentent 80 % de la population ? C’est vraiment une attitude de blanc, vous voyez. Vous pourriez emmener un homme blanc en Afrique, et il vous dirait « Regarde toutes les minorités qu’ils ont ici ! ».
Cela m’amène à un projet qui m’occupe actuellement. J’ai commencé à travailler sur le lancement d’un nouveau site pour un client. J’ai regardé les statistiques d’un autre site du même client, et voici ce que j’ai vu :
| Position | Navigateurs | Pages vues |
|---|---|---|
| 1. | Microsoft Internet Explorer 11 | 12,8% |
| 2. | Mobile Safari 7.0 | 10,3% |
| 3. | Microsoft Internet Explorer 9 | 8,2% |
| 4. | Microsoft Internet Explorer 10 | 6,6% |
| 5. | Google Chrome 36.0 | 5,4% |
| 6. | Microsoft Internet Explorer 8 | 5,3% |
| 7. | None | 4,4% |
| 8. | Android Browser 4.0 | 3,7% |
| 9. | Google Chrome 37.0 | 3,3% |
| 10. | Mozilla Firefox 31.0 | 2,9% |
| 11. | Google Chrome 32.0 | 2,0% |
| 12. | Google Chrome 35.0 | 2,0% |
| 13. | Safari (unknown version) | 2,0% |
| 14. | Google Chrome 31.0 | 1,7% |
| 15. | Mozilla Firefox 30.0 | 1,6% |
| 16. | Google Chrome 33.0 | 1,5% |
| 17. | Mobile Safari 6.0 | 1,5% |
| 18. | Mozilla Firefox 26.0 | 1,4% |
| 19. | Mozilla Firefox 32.0 | 1,4% |
| 20. | Google Chrome 34.0 | 1,0% |
Regardez toutes ces minorités ! Aucune version de navigateur ne dépasse les 13 % d’utilisation. Même constat avec les différentes résolutions d’écran, où la plus courante (1024×768) ne représente que 14,3 % d’utilisation. Et tout ça, c’est sur près de deux millions de pages vues le mois dernier.
Je me suis toujours intéressé de près aux statistiques des navigateurs. Et ça me fascine toujours autant de voir à quel point, en à peine dix ans, nous sommes passés d’un marché monopolistique composé majoritairement d’utilisateurs d’Internet Explorer 6 sous Windows XP en 1024×768, à un marché composé d’un ensemble de minorités.
En juin dernier, Fiona Taylor Gorringe soulevait une question intéressante sur son blog : « 3 % des utilisateurs naviguent avec IE9 et 14 % des utilisateurs ont un handicap. Pourquoi on ne se préoccupe seulement que des premiers ? ». Je ne dirais pas qu’on se préoccupe « seulement » des vieux navigateurs et jamais des utilisateurs avec un handicap. Mais j’ai clairement bien plus de demande explicite pour ces premiers que ces derniers. C’est un peu une « attitude de blanc » appliquée au web. Mais les minorités sur le web ne sont plus forcément celles qu’on croit.
Gmail 5.0 et Google Inbox
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.
Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.
Retour sur ma conférence à Paris Web 2014
La semaine dernière se sont déroulées les conférences de Paris Web. Cet événement tient une place toute particulière dans mon coeur parce que c’est là-bas, il y a à peine deux ans, que j’ai donné mon tout premier lightning talk en public. Depuis, j’ai poursuivi mon petit bonhomme de chemin en tant qu’orateur, de la Kiwi Party l’an dernier à Sud Web en mai dernier. Cette année, j’ai eu l’immense honneur d’être retenu pour donner une conférence de cinquante minutes sur l’intégration d’e-mails à Paris Web. C’était à la fois la conférence la plus importante que j’ai pu donner, mais aussi celle qui m’a le plus déçu. Voici mon retour d’expérience sur ma conférence à Paris Web 2014.
On me traite souvent de masochiste parce que je parle d’intégration d’e-mails. J’ai même ouvert un blog sur le sujet. Mais l’intégration d’e-mails est au coeur de presque chaque projet web (de newsletters commerciales à un e-mail de mot de passe oublié pour l’admin d’un blog). Et pourtant, l’intégration d’e-mails est considérée comme un sujet anecdotique, presque tabou, et que personne ne prend réellement au sérieux. J’avais déjà proposé une conférence sur le sujet à Paris Web en 2013, en vain. N’ayant pas particulièrement d’autre sujet en tête ou me tenant à coeur cette année, j’ai re-proposé la même chose. Et j’ai été retenu.
J’étais alors particulièrement enthousiaste. « Ça y est », me suis-je dit, je vais enfin pouvoir mettre au grand jour tous les problèmes qui entourent l’intégration d’e-mails. Et avec un public comme celui de Paris Web, composé de représentants de tous horizons (W3C, fabricants de navigateurs, grosses boîtes en tout genre), c’est l’occasion idéale pour tenter de faire prendre conscience du problème, et quitte à rêver encore un peu plus, pour initialiser un changement. J’étais d’autant plus ravi quand lors de l’annonce du programme des conférences Paris Web, j’ai découvert que j’aurais l’honneur d’être dans la plus grande salle. C’est le coup de projecteur rêvé pour tenter de faire quelque chose.
J’ai donc commencé petit à petit en juin dernier à rassembler mes notes, mes idées, les horreurs que je peux rencontrer parfois en intégrant ou en recevant des e-mails. Et puis je me suis réellement lancé dans la préparation de ma présentation en septembre dernier. Et c’est à partir de là que ça s’est gâté. Fin septembre, j’ai reçu un e-mail d’un membre de l’équipe de Paris Web m’informant que l’oratrice prévue en même temps que moi ne pouvait plus venir. Ils ont réussi à trouver un remplaçant, mais comme il est anglophone, il faudra qu’il occupe la plus grande salle, qui est équipée pour une traduction audio simultanée. « Crotte », me suis-je dit. Et comme si ça ne suffisait pas, l’orateur en question n’est autre que Vitaly Friedman, le papa de Smashing Magazine, qui venait parler de bonnes pratiques du responsive. « Double crotte », me suis-je dit. Non seulement j’étais relégué dans la plus petite salle. Mais en plus j’allais avoir en face de moi une immense star internationale pour parler d’un sujet autrement plus attrayant que l’intégration d’e-mails.
J’ai poursuivi la préparation de ma présentation, en restant sur mon idée principale de faire une conférence pas trop technique, visant surtout à sensibiliser sur le sujet et toutes ses problématiques. J’ai aussi essayé de rendre ça un minimum divertissant, en y ajoutant des extraits d’un de mes films préférés (j’ai dépensé sans compter). Je me dit toujours que quitte à prendre cinquante minutes à des gens, autant essayer de leur faire passer un moment agréable. Au moins, même s’ils n’apprennent rien, ils ne trouveront pas ça complètement nul.
La première répétition devant mes collègues lundi dernier fut pénible. Je n’étais clairement pas prêt. Et surtout, je tenais tout juste une trentaine de minutes. J’ai passé les deux jours qu’il me restait à retravailler tout ça. Au total, j’ai dû passer l’équivalent de six jours (soit une bonne quarantaine d’heures) à préparer cette conférence.
Le jour J arriva. En parcourant mes slides tout seul dans ma chambre d’hôtel le matin même, je me suis senti prêt. Je tenais la conférence que j’avais envie de donner. J’étais planifié pour passer en deuxième l’après-midi. J’ai choisi d’assister à la conférence me précédant dans la même salle. Autant dire que je n’ai rien suivi. Je repassais mes slides en boucle dans ma tête. Et puis je commençais petit à petit à stresser. La plus petite salle dans laquelle je me trouvais n’était finalement pas si petite. En regardant le public autour de moi, ça faisait quand même beaucoup de monde. « Est-ce que ces gens resterons pour ma conférence ? », me demandais-je. J’ai rapidement eu la réponse. Une fois la conférence terminée, la salle s’est vidée. Je suis monté sur scène pour tout préparer et vérifier que tout fonctionne bien. Et je contemplais la salle désespérément vide. « On attends encore une minute et tu peux commencer », m’a lancé un membre de l’équipe de Paris Web. « Ah ? Mais on attends pas qu’il y ait plus de monde ? En une minute il n’y aura pas beaucoup plus de monde ! » ai-je pensé naïvement. J’ai compté, et on devait à peine être une soixantaine. Je m’attendais à ce que Paris Web soit l’événement où je parle devant le plus de spectateur. C’est en fait devenu l’événement où j’ai parlé avec le moins de spectateur. Je ne me suis pas laissé décourager pour autant, et j’ai lancé mon premier slide. (Non sans ironie, j’avais prévu de démarrer ma conférence en expliquant que l’intégration d’e-mails est un sujet qui fait fuir les intégrateurs.)
Finalement, tout s’est bien passé. J’ai avalé mes 188 slides les uns après les autres. J’ai entendu les gens rire. Je pense en avoir entendu d’autres pleurer en découvrant certaines horreurs. Je n’ai pas eu l’impression de trop bafouiller. Je n’ai pas eu de trou de mémoire. Tout s’est bien passé.
Et puis est arrivée l’obligatoire séance de questions-réponses. Et c’est là qu’est intervenu Daniel Glazman, co-président du groupe de travail sur CSS au W3C. Secrètement, j’espérais qu’il soit présent. À la fin de ma conférence, j’évoquais une réunion de travail du W3C sur l’intégration d’e-mails qu’il avait dirigé en 2007. J’espérais qu’il puisse partager son expérience, et pourquoi pas raviver la flamme pour tenter de relancer quelque chose sur le sujet. Sauf que le discours qu’il a tenu m’a littéralement refroidi. Il a expliqué que les équipes de Microsoft qui travaillent sur le moteur de rendu d’Outlook sont totalement distinctes de celles qui travaillent sur le moteur de rendu d’Internet Explorer. Et les équipes d’Outlook n’ont strictement rien à cirer de la qualité de leur moteur de rendu HTML. Et le W3C n’a aucune légitimité à débattre sur des spécifications liées aux e-mails. Aussi, je suis bien gentil avec ma conférence et mon petit blog sur l’intégration d’e-mails, mais si je veux que les choses changent, il faut absolument que j’écrive en anglais et que je participe au groupe communautaire du W3C. « Soit », ai-je pensé. Je ne suis pas convaincu que les équipes du webmail de La Poste lisent souvent ce genre de ressources… « Merci d’avoir passé six jours pour rien à préparer tout ça. Tu peux rentrer chez toi avec l’assurance que rien ne bougera dans les dix prochaines années » ai-je retranscrit dans ma tête.
Une salle presque vide. Une ambition réduite au néant. Voilà comment ça s’est terminé. Peut-être que je m’étais un peu trop monté la tête, peut-être que je m’étais mis trop de pression, en m’imaginant que j’arriverais faire à bouger les choses… Ou peut-être pas.
Les vidéos de toutes les conférences de Paris Web ont été rendues disponibles en ligne dès le jour même. (Au passage j’en profite pour féliciter toute l’équipe de Paris Web qui réalise un travail colossal et profondément utile, tout ça bénévolement.) À ma grande surprise, ma conférence est en train de vivre une deuxième vie sur le web. Sur le site de Livestream, elle affiche déjà 1891 vues (soit la troisième plus vue après les lightning talks et l’excellente conférence de Christophe Porteneuve sur JavaScript). Et puis surtout, sur Twitter ou ailleurs, j’ai reçu des commentaires très positifs. Et notamment des remarques inattendues comme celle de PinGoo sur mon blog dédié à l’intégration d’e-mails :
Pour info, [ta conférence] a fait pas mal réfléchir nos chefs de projets sur le temps que l’on passait à vouloir faire du pixel perfect sur nos newsletters. Merci !
Il ne m’était même pas venu à l’esprit que des chefs de projet puissent être intéressés par ma conférence (et aussi que des boîtes vendent encore du pixel perfect, mais ça c’est une autre histoire).
Et puis pas plus tard que ce matin, j’ai vu passé ce tweet de David Rousset, évangéliste HTML5 chez Microsoft :
Grâce à l’excellente conf à Paris Web de HTeuMeuLeu, nous allons peut-être enfin améliorer nos newsletters Microsoft !
Bon, à choisir, je préférerais que Microsoft améliore le moteur de rendu HTML d’Outlook. Mais c’est déjà un bon début. Et peut-être que finalement je n’aurais pas fait tout ça pour rien…
« Comment sortir l’intégration d’e-mails de la préhistoire » à Paris Web 2014
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 de « « Comment sortir l’intégration d’e-mails de la préhistoire » à Paris Web 2014 »
Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.
La version sans images d’EmailWeekly #13
La version sans images de la newsletter #emailweekly numéro 13 est vraiment super, super, super cool. J’adore la transition provoquée par le chargement progressif des images entre les deux logos. Et j’adore le texte alternatif « Ahoy Mat’ey » qui n’apparaît qu’une fraction de seconde.
Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.
Faire un lien sur toute une zone en CSS
On m’a récemment rappelé sur Twitter une pratique qui m’exaspère au plus haut point ces derniers temps. Sur certains sites, le clic secondaire sur des liens est rendu inutilisable. C’est le cas par exemple sur Factornews (j’aime beaucoup Factornews, notamment quand ils font des jeux de mots comme à la fin de cet article).
Dans la première zone d’actualités du site, chaque encart d’actualité est entièrement cliquable. Mais si j’utilise le clic de la molette de ma souris (pour ouvrir le lien dans un nouvel onglet), il ne se passe strictement rien. Si je maintiens appuyé la touche majuscule de mon clavier (pour ouvrir le lien dans une nouvelle fenêtre), mon raccourci sera ignoré et le lien sera ouvert dans la fenêtre courante.
Si le clic se comporte comme ça, c’est parce que ce n’est pas un vrai lien HTML. Ici, pour chaque actualité, seul le titre de l’actualité est dans une balise <a>. Le clic sur le reste de la zone est géré via JavaScript. La volonté de rendre toute la zone cliquable est fortement louable, mais l’annulation du comportement natif d’un navigateur engendrée nuit fortement à l’utilisabilité. Je rencontre ce genre de problèmes régulièrement sur d’autres sites comme Le Bon Coin ou LEGO Ideas.
Ce problème d’intégration est vieux comme le monde. Prenons par exemple le code HTML suivant.
<article class="item">
<h1><a href="/faire-un-lien-sur-toute-une-zone-en-css">Faire un lien sur toute une zone en CSS</a></h1>
<p>On m'a récemment rappelé sur Twitter une pratique qui m'exaspère au plus haut point ces derniers temps…</p>
</article>En XHTML ou en HTML4, une balise <a> ne pouvait contenir que des éléments inline. Du coup, l’utilisation de JavaScript (voire de jQuery) était fortement recommandée pour résoudre ce problème. Aujourd’hui, les quelques lignes suivantes suffiraient à rendre toute la zone cliquable pour tous les éléments .item sur notre page.
document.addEventListener('DOMContentLoaded', function() {
var items = document.querySelectorAll('.item');
for(var i=0; i < items.length; i++) {
var item = items[i];
item.addEventListener('click', function() {
var url = this.getElementsByTagName('a');
if(url.length > 0)
url = url[0];
window.location = url;
});
}
});Mais cette solution est à l’origine des problèmes d’utilisabilité qui m’exaspèrent tant.
La spécification HTML5 a changé la donne, et on peut désormais englober dans un <a> n’importe quel élément. On pourrait alors simplement englober tout notre .item d’une balise <a>. Mais ce n’est pas forcément une bonne idée, en particulier pour le référencement où il serait préférable de conserver un contenu texte court et pertinent.
Heureusement, une solution est possible en CSS. En utilisant un pseudo-élément ::before ou ::after, on peut le positionner en absolu par rapport au conteneur principal parent et faire en sorte qu’il occupe tout l’espace. Il faudra bien s’assurer que le conteneur parent en question (.item) ait lui aussi un positionnement non statique afin de restreindre le pseudo-élément du lien. Le code suivant fait alors l’affaire.
.item {
position:relative;
}
.item a:before {
content:'';
position:absolute;
left:0;
right:0;
top:0;
bottom:0;
background-color:rgba(0,0,0,0);
}Ça fonctionne bien dans Chrome, Firefox, Safari et Opera. Pour Internet Explorer (9 et plus), il est nécessaire d’ajouter un fond transparent afin que la zone soit cliquable même au-dessus des autres éléments.
L’inconvénient de cette solution est qu’elle ne s’applique pas sur IE8. Même si le pseudo-élément est bien créé, celui-ci restera non cliquable sous les autres éléments de la zone. Mais si vous pouvez vous permettre d’avoir un fonctionnement dégradé gracieusement sur IE8, cette solution me semble assez élégante.
Comment le poids d’un e-mail affecte la délivrabilité ?
EmailOnAcid a fait plein de tests pour comprendre comment le poids d’un e-mail affecte sa délivrabilité. En résumé : il est préférable de conserver le poids de son HTML sous la barre des 100 Ko, et le poids des images n’a pas d’importance.
Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.
Mario Kart 8 2.0 et le bouton « Course suivante »
La première mise à jour avec du contenu téléchargeable de Mario Kart 8 est sortie aujourd’hui. La meilleure partie de cette mise à jour pour moi est la suivante, annoncée en début de mois :
L’ordre du menu suivant chaque course sera modifié en « Course suivante, suivi par « Voir les temps forts ».
Non seulement ils ont corrigé ce problème, mais surtout ils choisissent de le mettre en avant comme l’une des « fonctionnalités conçues pour améliorer l’expérience de conduite des joueurs ».
Le bon design, c’est aussi apprendre et corriger ses erreurs.
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.
Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.
L’attribut srcset pour des images responsive
L’attribut srcset est un nouvel attribut pour les balises images décrit dans la spécification de HTML 5.1. Il permet de résoudre en partie l’une des plus grosses problématiques de l’intégration de sites responsive : les images.
Venant en complément de l’attribut src habituel d’une balise <img>, l’attribut srcset permet de spécifier une liste d’images à afficher selon des critères particuliers. L’immense avantage, c’est que c’est le navigateur qui décide quelle image afficher, et que seule cette image sera téléchargée.
Son implémentation a déjà commencé depuis février dernier dans la version 34 de Chrome, mais limitée à la sélection d’image selon la densité de pixels de l’écran d’un appareil. Ainsi dans le code suivant, je peux préciser le chemin d’une image optimisée pour des appareils avec une densité de pixels à l’écran d’au moins 2 (aussi vulgairement appelés « écrans rétina »).
<img src="default.jpg" srcset="hidpi.jpg 2x" />
C’est déjà un bon début. Mais ce qui est vraiment bien, c’est que les navigateurs commencent maintenant à implémenter la suite, à savoir la sélection d’images selon le viewport. C’est en cours d’implémentation dans Chrome, Opera, et dans Firefox derrière un flag. Et surtout, ce sera activé par défaut dans Safari 8 sur iOS 8 et OS X Yosemite. Cela signifie que d’ici la fin de l’année, la majorité des navigateurs supporteront srcset. (Pour Internet Explorer, c’est pour l’instant « en considération ».)(On me fait signe que la version beta actuelle de Safari 8 ne supporte que la première partie de la spécification, et pas la sélection d’images selon le viewport).
Il y a donc de quoi être tout excité par cette nouveauté. J’ai fait mumuse avec srcset ces derniers jours, et voici que j’ai appris et compris.
Tout d’abord, pour tester tout ça, il va falloir installer ou configurer les navigateurs compatibles. Pour avoir Safari 8 sur iOS, vous pouvez télécharger la beta de Xcode 6 dans laquelle vous aurez la dernière version du Simulateur iOS. Pour avoir Safari 8 sur OS X, vous pouvez télécharger la bêta publique de OS X Yosemite.
Pour Chrome, vous pouvez télécharger Chrome Canary (actuellement en version 38).
Pour Firefox, vous pouvez télécharger Firefox Nightly (actuellement en version 34). Puis il faudra activer le support de srcset à la main. Pour ça, il faut aller à l’adresse about:config, chercher les préférences dom.image.srcset.enabled et dom.image.picture.enabled, et les passer toutes les deux à la valeur true.
Nous sommes prêts pour tester. Pour commencer, nous allons préciser dans srcset une liste de quatre images : small.png (320×240), medium.png (640×480), large.png (1024×768) et xl.png (1920×1080). Si le navigateur ne supporte pas srcset, c’est l’attribut src qui prendra le relais avec l’image default.png (1024×768). Voici le résultat de ce premier exemple avec le code suivant :
<img src="default.png" srcset="small.png 320w, medium.png 640w, large.png 1024w, xl.png 1920w" alt="Test" />
Comme vous pouvez le constater, chaque image est accompagnée d’un « descripteur w » (dixit la spécification, en opposition au « descripteur x » utilisé lui pour la sélection selon la densité de pixels d’écran). J’ai eu beaucoup de mal à comprendre la signification de ce descripteur, notamment à cause d’article comme celui publié chez Alsacréations (désolé Geoffrey) qui confondent descripteur w et largeur de viewport. À ce stade, il faut bien comprendre qu’il n’y a aucun lien entre les deux. Le descripteur w est une indication laissée au navigateur sur la largeur en pixels de l’image correspondante.
Là où la spécification de srcset est surprenante, c’est dans la façon de décrire comment un navigateur va choisir l’image à afficher :
L’agent utilisateur va calculer la densité de pixel réelle de chaque image à partir du descripteur
wspécifié et des tailles de rendus spécifiées dans l’attributsizes. Il peut ensuite choisir n’importe quelle ressource en fonction de la densité de pixels de l’écran de l’utilisateur, de son niveau de zoom, ou peut-être d’autres facteurs comme les conditions de réseau de l’utilisateur.
En gros : le navigateur fait ce qu’il veut. Cela signifie que Chrome pourrait décider de choisir l’image la plus petite si la connexion est un peu lente, alors que Safari pourrait au contraire décider de systématiquement choisir l’image la plus grande. Bienvenue dans un futur nouvel enfer du responsive !
À noter qu’actuellement, Firefox ne va charger une image qu’au chargement initial de la page, mais ne rafraîchira pas son affichage au redimensionnement de la fenêtre. La dernière version de Chrome Canary gère très bien ça au redimensionnement (et au passage, la nouvelle vue device mode des outils de développement de Chrome est vraiment bien foutue).
Les choses sérieuses vont commencer en introduisant l’attribut sizes. Celui-ci permet de spécifier la largeur d’affichage de l’image selon des points de rupture. Dans l’exemple ci-dessus, les images vont toujours par défaut prendre 100% de la largeur du viewport. La spécification explique clairement que la valeur par défaut de l’attribut sizes est de 100vw et que dans ce cas, l’attribut peut-être omis. Malheureusement les développeurs de chez Mozilla ont du s’arrêter de lire la spécification juste avant ce paragraphe car dans l’implémentation actuelle, il faut impérativement préciser l’attribut sizes, même pour une valeur de 100vw. (J’ai remonté le problème, et il a déjà été affecté, donc on peut espérer une correction en moins de douze ans.)
Là où sizes est bien pratique, c’est qu’il va permettre de spécifier différentes largeurs d’affichage pour notre image selon le reste du gabarit de notre page. Si par exemple je suis sur un viewport de 800px de large, mais que j’affiche mon image à seulement 400px de large, je peux le préciser dans l’attribut sizes et le navigateur tentera de charger l’image qu’il juge la plus appropriée. En reprenant le premier exemple et en y appliquant cette condition, ça donnerait ce deuxième exemple et le code suivant :
<img src="default.png" srcset="small.png 320w, medium.png 640w, large.png 1024w, xl.png 1920w" sizes="(width:800px) 400px" alt="Test" />
Ici, l’image est toujours affichée à une largeur correspondant à 100% du viewport, sauf si celui-ci vaut exactement 800px, auquel cas l’image est fixée à une largeur de 400px. Cet exemple est totalement stupide dans la vraie vie. On pourra alors plutôt écrire ce genre de code un peu verbeux pour ce troisième exemple :
<img src="default.png" srcset="small.png 320w, medium.png 640w, large.png 1024w, xl.png 1920w" sizes="(min-width:20em) and (max-width:50em) 20em, (min-width:50em) and (max-width:80em) 40em, (min-width:40em) 10em" alt="Test" />
J’ai défini ici trois points de rupture précisant des tailles d’images respectivement de 20em, 40em et 10em. Si aucune des conditions des points de rupture n’est remplie, alors le navigateur appliquera à l’image sa valeur par défaut de 100vw.
Là où ça peut devenir un joyeux bazar, c’est qu’on peut combiner les descripteurs w et x. Et tout ça peut être combiné à la balise <picture> qui elle aussi commence à être supportée. Opera a récemment publié un article pour donner des cas pratiques d’utilisation d’images responsive. L’article d’Eric Portis sur « srcset et sizes » est magnifiquement illustré et très complet sur le sujet et m’a aidé à comprendre un tas de trucs.
Video in email
StyleCampaign fait le tour des solutions pour intégrer de la vidéo dans un e-mail (ou au moins faire semblant). Il n’y a pas de recette miracle, et le support des vidéos HTML5 dans les e-mails est encore anecdotique. Mais n’empêche que même avec un GIF (de 1,7 Mo, certes), certains font de chouettes e-mails.
Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.
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>.
Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.
L’écran de la Moto 360 n’est pas rond
J’avais lu cette information il y a déjà plus d’un mois, mais de nouvelles photos destinées à la presse sorties ce week-end en sont un malheureux rappel. L’écran de la Moto 360 n’est pas rond. Il y a une coupure droite en bas sur toute la longueur.
Depuis que je sais ça, je ne vois plus rien d’autre. D’après un responsable de Google répondant à The Verge, c’est une « inévitable étrangeté de conception ». Personne ne sait si Apple travaille sur un projet similaire, mais si c’est le cas, et si je devais répondre à ce tweet, je donnerais la réponse C.
Office 365 et ses nombreux caprices pour les designers d’e-mails
James White fait le tour des points vraiment pénibles de Office 365 (Outlook Web Access) pour l’intégration d’e-mails. Sa phrase d’introduction résume bien le sujet :
Après avoir creusé le sujet, j’en arrive à la conclusion que l’application Office 365 OWA est pire que Outlook 2007 ou 2013 en terme de support des standards.
Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.
Les statistiques des navigateurs de juillet 2014
J’ai toujours été fasciné par les statistiques globales de parts de marché ou d’utilisation des navigateurs, même si c’est toujours à prendre avec de grosses pincettes. En 2011, je suivais attentivement l’adoption d’IE9 et de Firefox 4. Je m’interrogeais même sur l’avenir que pourrait avoir le marché des navigateurs, en me disant que ce serait chouette d’arriver à un marché sain avec trois concurrents à parts égales.
Ce doux rêve ne dura pas longtemps. L’année dernière, je constatais le passage de la domination d’IE à la domination de Chrome. Ce constat m’a été rappelé cette semaine sur Reddit avec cette carte des navigateurs les plus utilisés par pays (d’après les données de StatCounter).
Ça en devient presque effrayant. Si on compare avec la même carte un an plus tôt, Chrome a réussi à devenir le principal dans de nombreux pays, ne laissant plus qu’à IE que le Japon et la Corée. Firefox s’est aussi bien fait devancer un peu partout dans le monde, et surtout en Afrique, par Opera. L’explosion du web mobile en Afrique que j’évoquais à la sortie de Firefox OS se fait sentir.
Si on regarde le chemin parcouru depuis juillet 2011 (d’après StatCounter), le constat n’en est que plus effrayant. 
En trois ans, en seulement trois petites années, on est passé d’une utilisation de Firefox de 28 % à seulement 17 %. En trois ans, on est passé d’une utilisation d’Internet Explorer de 42 % à 21 %. Et en trois ans, on est passé d’un Chrome à 22 % à 45 %.
Ce qui m’inquiète, c’est que sans bouleversement majeur du marché de l’informatique personnelle, la dégringolade d’IE et Firefox au profit de Chrome ne risque que de s’accentuer. En trois ans, on est passé d’un marché où Windows représentait 85 % des OS utilisés sur le web, à seulement 55 %, suivi par une forte croissance d’Android et d’iOS représentant à eux deux 28 % des OS utilisés sur le web. L’insignifiance de Firefox et Internet Explorer sur le marché mobile ne va certainement pas arranger ça.
En étant pessimiste, dans trois ans, Chrome sera peut-être utilisé par au moins 75 % des internautes. En étant optimiste, dans trois ans, Internet Explorer et Firefox seront peut-être encore là pour voir ça.
Créer un design responsive centré sans media queries
Campaign Monitor explique comment créer un e-mail responsive propre, sans media queries, en se basant sur la propriété CSS display:inline-block plutôt que sur des tableaux.
Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.
How to Build Kickass Emails
Kevin Mandeville, de chez Litmus, a mis en ligne les slides de sa conférence « How to Build Kickass Emails ». C’est monstrueux (dans le bon sens du terme), et c’est très très complet. C’est même un peu drôle. Et sa page dédiée diffusée juste après la conférence est elle aussi (en plus d’être une excellente idée) bourrée de liens utiles.