HTeuMeuLeu

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…

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.

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.

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 w spécifié et des tailles de rendus spécifiées dans l’attribut sizes. 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.

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.