Devenez un geek en email HTML avec ces vidéos de Rémi Parmentier

Créer un courriel au format HTML peut sembler être un retour en arrière de quelques années en tant que développeur Web. Toutes nos nouvelles fonctionnalités de mise en page ne sont pas disponibles pour nous & mdasj; Les clients de messagerie affichent la même présentation de manière complètement différente. Juste au moment où nous pensons avoir réglé le problème, un autre client de messagerie électronique présente une nouvelle série de bogues.

Il n'y a pas si longtemps, Rémi Parmentier, développeur de courriers électroniques HTML, a animé une session avec des techniques pratiques pour la construction moderne. , courriels inter-clients. Quelques semaines plus tard, à SmashingConf Freiburg, il a donné une conférence magnifique qui a mis en lumière certaines des luttes communes et a présenté des stratégies utiles pour éviter les problèmes de développement du courrier électronique .

Ces sessions contenaient tellement d'informations utiles que nous voulions les diffuser plus largement, y compris la transcription du webinaire et des références aux diapositives et aux ressources. Si vous avez déjà eu du mal avec le développement du courrier électronique, cela vous donnera un excellent point de départ pour comprendre pourquoi un courrier électronique n'est pas restitué correctement, et comment supprimer rapidement ces vilains bugs.

Si vous aimez apprendre à partir de ces vidéos, allez voir: Smashing Membership. À partir de ce mois-ci, nous montrerons certaines des sessions en direct que nous organisons tous les mois à un public plus large – absolument gratuites à voir. Toutefois, si vous souhaitez participer à la discussion en direct et éventuellement faire réviser votre travail par un expert, rejoignez Smashing Membership . Pour le prix d'un café par mois, vous pouvez contribuer à la création de contenus tels que celui-ci.

Préparez-vous à tout apprendre sur le courrier électronique HTML

Webinar: Courriel HTML avec Rémi Parmentier

Ressources et transcription

Rémi Parmentier: Merci à tous d’avoir assisté à ma présentation. Je m'appelle Rémi Parmentier. Certains d’entre vous me connaissent peut-être sur Twitter ou sur mon blog sous le pseudo hteumeuleu. Je fais des courriels au format HTML depuis aussi longtemps que je travaille dans ce secteur. Depuis quelques années, j'ai commencé à dispenser une formation aux courriers électroniques HTML. Je passe beaucoup de temps en ligne sur Slack, sur Twitter, sur des forums pour aider les gens à trouver des solutions à leurs problèmes de messagerie. Cela m'a donné une bonne idée de la plupart des problèmes de codage rencontrés par les utilisateurs et de la manière de les résoudre. J'ai commencé à travailler sur ce projet de directives de codage du courrier électronique cette année. Cela a été grandement inspiré par le travail effectué sur le Web à propos de je pense il y a dix ans.

Rémi Parmentier: Il y a environ une décennie, de nombreuses tendances concernant les lignes directrices relatives au Web étaient partagées. par des personnes de nombreuses entreprises différentes. Le premier était le plus célèbre était ce guide de code de Mark Otto, qui travaillait alors pour Twitter. L'objectif du document était de partager de nombreuses directives sur la manière dont le code HTML et CSS devrait être codé au sein de l'entreprise. Ce document contenait beaucoup de bonnes pratiques, telles que le type de document que vous devriez utiliser ou pour fermer votre tag, etc. Je pense que c'est très intéressant à avoir.

Rémi Parmentier: Dans le monde du courrier électronique, Ted Goas de Stack Overflow a en fait créé un document très similaire, avec beaucoup de contenu, sur la manière dont ils sont construits. les emails à Stack Overflow. Cela m'a vraiment donné l'envie de créer un document similaire que tout le monde pourrait partager au sein de leur entreprise ou qui pourrait choisir les bonnes pratiques pour créer des emails HTML. Nous allons voir quelques-unes de ces meilleures pratiques et vous pourrez voir le document ensuite en ligne.

Rémi Parmentier: La première chose que je partage habituellement est d’utiliser le doctype HTML5. Chaque fois que j'aide des utilisateurs d'e-mail HTML ouvert en ligne, je suis triste de constater que de nombreuses personnes utilisent encore le doctype HTML4 ou XHTML 1. La première raison d'utiliser le doctype HTML5 est que c'est vraiment agréable. En fait, c’est très court. Vous pouvez le saisir à la main, vous en souvenir, et c'est déjà une bonne raison de l'utiliser.

Rémi Parmentier: La raison la plus importante d'utiliser le doctype HTML5 est que lorsqu'un e-mail est affiché dans le webmail, notre doctype est généralement supprimé et nous héritons du doctype du webmail. La plupart des webmails utilisent le doctype HTML5, donc même si vous souhaitez utiliser HTML1 ou HTML4, cela ne fonctionnera pas car les webmails l'élimineront.

Rémi Parmentier: J'ai créé cette petite illustration de la façon dont cela fonctionne réellement. Sur la gauche, vous pouvez voir une adresse email codée. Il porte une étiquette de style, une div et un H1 à l’intérieur. Que se passe-t-il lorsqu'un courriel Web comme Gmail, par exemple, veut afficher ce contenu, il choisira les balises de style et le contenu dans le corps, et préfixera les styles, il supprimera tous les styles qu'il ne prend pas en charge , et ensuite cela sera inclus dans le code HTML du webmail réel, car les webmails ne sont en fait que HTML et CSS. Cela signifie que même si j'utilise un doctype HTML4, étant donné que Gmail utilise un doctype HTML5, mon code sera aléatoire grâce à ce doctype. C’est une bonne chose à garder à l’esprit.

Rémi Parmentier: Je vous ai parlé de ce type de doctype à utiliser dans les courriels HTML, il ya déjà trois ans environ, mais ce que j’ai vu à l’époque était que la plupart des clients de messagerie utilisaient déjà un type de document HTML5. Quelques-uns d'entre eux n'avaient pas du tout de doctype, comme sur les applications mobiles parfois, mais beaucoup étaient sur HTML5.

Rémi Parmentier: Il est important de savoir que vous pouvez vous retrouver sur différents doctypes car il peut y avoir des différences. La première est que HTML5 comporte des espaces entre les images. Si vous coupez une grande image dans votre email, vous verrez quelque chose comme ceci si vous l'essayez avec un doctype HTML5.

Rémi Parmentier: Permettez-moi de vous montrer cela avec une petite démo. Ici, j’ai ça… Oups, c’est le mauvais. Ici, j'ai cette petite démo d'un T-Rex. C’est en fait trois images. Ici, avec un doctype HTML1, tout fonctionne bien, mais si j'utilise un doctype HTML5, boom, des lignes blanches apparaissent entre chaque image.

Rémi Parmentier: Maintenant, je ne suis pas exactement Bien sûr, pourquoi cela se produit, mais je pense que c'est parce que, lors de la mise à niveau de HTML5, ils ne peuvent pas changer la façon dont les images sont censées se comporter conformément à la spécification; il ressemble donc davantage à un paragraphe avec du texte; il y a donc des lignes entre les images. .

Rémi Parmentier: Email Les Geeks ont trouvé de très bonnes solutions pour le service. L'une des solutions consiste à ajouter un style de bloc d'affichage à chaque image. Une fois que vous faites cela, cela supprimera les lignes blanches entre les images. Si vous ne pouvez pas utiliser le bloc d’affichage, une autre solution consiste à ajouter un style d’alignement vertical moyen, puis à supprimer ces lignes blanches.

Rémi Parmentier: Il s’agit là d’une première bizarrerie. vous pouvez rencontrer un doctype HTML5, mais il existe un autre cas intéressant: vous ne pouvez pas afficher le blocage d'une cellule de tableau dans WebKit sans un doctype. Celui-ci est également très intéressant. J’ai aussi une table pour cela, qui serait ici même.

Rémi Parmentier: Ici, j’ai une table avec trois petits dinosaures côte à côte. Habituellement, lorsque nous avons des tableaux comme celui-ci et que nous voulons optimiser nos e-mails pour les téléphones portables, nous pouvons appliquer le bloc d'affichage à nos TD, puis les empiler les uns sur les autres comme ceci.

Rémi Parmentier: Comme nous pouvons le voir ici, nous avons un doctype HTML5. Cela fonctionne bien, mais si je me retrouvais un jour dans un client image qui supprimerait le type de document, cela ne fonctionnerait plus dans WebKit. Comme vous pouvez le constater, nous revenons à l'affichage des modèles habituels.

Rémi Parmentier: Je pense que cela concerne les sites Web hérités, les modes bizarres et toutes ces choses, mais une solution n'a été trouvée. par la communauté de messagerie est d'utiliser réellement les balises TH au lieu de TD. Si j’enlève chaque TD par TH, vous pouvez voir que, même sans doctype, cela fonctionne à nouveau. C’est une sorte de bizarreries que vous devez traiter dans les courriels HTML en raison non seulement du comportement des clients de messagerie, mais également du rendu de moteurs tels que WebKit.

Rémi Parmentier: La deuxième meilleure pratique que je voudrais vouloir partager avec vous aujourd'hui, c'est utiliser les attributs lang. L'attribut lang en HTML permet de définir la langue de votre document. Ceci est très important pour l'accessibilité, principalement parce que les outils d'accessibilité tels que les lecteurs d'écran pourront choisir la voix qui convient.

Rémi Parmentier: Encore une fois, laissez-moi vous montrer une démo de ce live, et j'espère qu'il ne tombera pas en panne. Ici, j'ai ce très gentil email de Mailchimp. Comme il a été dit auparavant, je suis français, mon ordinateur est donc en français. Mon lecteur d’écran est également en français, donc chaque fois que nous verrons du nouveau contenu, il essaiera de le lire en français. Je vais arrêter mon lecteur d'écran maintenant. Vous essayez de voir quand nous allons arriver à ce paragraphe et voir comment il le lira.

Rémi Parmentier: Je sais que je n'ai pas vraiment un bon accent anglais, mais c'est même pire que le mien. Si vous ne définissez pas les attributs lang, votre contenu sera lu dans la langue par défaut de vos utilisateurs. La phase rapide consiste ici à ajouter les attributs lang, puis à redémarrer mon lecteur d'écran.

Lecteur d'écran: : Mailchimp Presents propose une nouvelle collection de contenu original conçue pour les entrepreneurs. Ces derniers mois, nous avons déployé des documentaires, des séries abrégées et des podcasts diffusés uniquement sur Mailchimp. Aujourd'hui, nous lançons officiellement une plateforme.

Rémi Parmentier: Comme vous pouvez l'entendre, même pour mon lecteur d'écran, mon système est toujours défini en français, une fois que le lecteur d'écran est en réalité au format HTML, elle utilisera une autre voix, une voix anglaise, pour lire le contenu, ce qui rend l'expérience beaucoup plus agréable ici.

Rémi Parmentier: Une petite différence entre les courriers électroniques HTML et l'attribut lang. Est-ce que, tout comme pour le doctype, le doctype ne peut pas être capté par les webmails, parce que les webmails prendront seulement les styles et le contenu du corps. Il est généralement recommandé d’ajouter l’attribut lang sur l’emballage que vous avez sur votre contenu dans votre corps, afin de vous assurer que cet élément sera également sélectionné par les Webmails.

Rémi Parmentier: Une troisième pratique exemplaire que j'aime bien consiste à utiliser des styles plutôt que des attributs HTML. C’est vraiment quelque chose que les gens détestent à propos des emails HTML car ils estiment qu’ils doivent utiliser tous les attributs HTML, ils doivent utiliser tout le code, ce qui rend les emails très différents du Web, mais il n’ya vraiment aucune raison pour cela. tous sauf si vous avez besoin de prendre en charge de très anciens clients de messagerie tels que Lotus Notes 6 ou similaire.

Rémi Parmentier: Dans cet exemple, dans le premier exemple, vous pouvez voir que j'ai utilisé valign, align et Attributs bgcolor en HTML, mais tous peuvent être facilement et robustement remplacés par les styles correspondants. Ici, je n'ai qu'un seul attribut de style et à l'intérieur, j'ai la propriété CSS align align vertical, aligner le texte et la couleur d'arrière-plan.

Rémi Parmentier: L'une des raisons pour laquelle j'aime faire cela est que cela rend plus propre et plus lisible. Toutes vos propriétés de présentation sont regroupées dans un seul attribut de style au lieu d'être omniprésentes avec valign, align et tout le reste. Cela rend, à mon avis, très, très préférable de lire et de maintenir.

Rémi Parmentier: J'aime également utiliser des styles par rapport à des attributs pour aider les clients de messagerie modes. Par exemple, sur le webmail français d’Orange, l’interface utilisateur du webmail contient en fait un CSS qui a une règle qui définit chaque TD en alignement vertical. À cause de cette règle, si vous n'utilisiez que des attributs HTML tels que valign = middle, le rôle CSS du Webmail serait remplacé par les attributs HTML, car c'est ainsi que fonctionne la cascade en HTML et CSS.

Rémi Parmentier : Au lieu de cela, si nous utilisons un style en ligne avec une propriété d'alignement vertical sur le TD ici, eh bien, ce style reprendra le style de la messagerie Web car les styles en ligne sont plus importants que les feuilles de style externes. Utiliser des styles plutôt que des attributs est également un bon moyen de lutter contre les styles par défaut des autres clients de messagerie et webmails.

Rémi Parmentier: Il existe quelques exceptions aux attributs que j’utilise encore. La première exception est de centrer un tableau dans Outlook 2007 à 2019 sur Windows, car, comme le disait Scott dans l'introduction, Outlook utilise Word comme moteur de rendu dans ces versions et qu'il n'est pas très bon pour comprendre le CSS, du moins pour certaines propriétés. 19659005] Rémi Parmentier: Par exemple, ici, il comprendrait les propriétés de la marge pour les valeurs de pixel, mais pas la valeur automatique de la marge zéro pour centrer un tableau. Nous avons toujours besoin de l'attribut align = center pour centrer les éléments et les données, en particulier dans Outlook, mais nous n'avons plus besoin d'utiliser quels attributs comme dans le premier exemple ici. Cela peut être remplacé par le style width à la place.

Rémi Parmentier: Désormais, une autre exception dans Outlook concerne également la définition d'une largeur d'image fluide. Dans le premier exemple, j'utilise un attribut width avec une valeur de 100%. Le problème est qu'Outlook ne traite pas le pourcentage de largeur des images de la même manière que dans CSS.

Rémi Parmentier: Le pourcentage dans Outlook correspond en fait à la taille de l'image physique et non la taille du parent dans le HTML. Si vous avez une image de 600 pixels de large et que vous utilisez une largeur = 50%, votre image fera en réalité 300 pixels, quelle que soit la taille de votre parent en HTML.

Rémi Parmentier: Généralement, pour éviter toute bizarrerie avec cela, je définis toujours une largeur fixe en pixels pour Outlook à l'aide de l'attribut width en HTML, puis à l'aide d'un style, j'utilise une largeur de 100%. Outlook ne sélectionnera ici que la valeur de l'attribut et non la valeur du style.

Rémi Parmentier: Ensuite, une autre exception que j'ai lorsque j'utilise des styles sur des attributs consiste à réinitialiser les styles par défaut du tableau. Par défaut, les tables HTML ont des bordures et des marges intérieures et des cellules, etc. La bonne façon de faire cela en CSS est de définir border zéro, un espacement de bordure zéro, notre remplissage est égal à zéro, notre bordure est égale à zéro, les premiers sur la table et d'élargir votre bordure pour chaque cellule de votre tableau.

Rémi Parmentier: C'est à peu près pourquoi je n'aime pas le faire en CSS, car vous devez répéter le remplissage et la bordure pour chaque TD de votre table, alors que si vous utilisez les attributs, Il suffit de les utiliser sur la table et vous êtes prêt pour n'importe quelle… peu importe les cellules que vous avez à l'intérieur de votre table. J'espère que c'est quelque chose que je changerai peut-être dans quelques années, mais pour l'instant, je suis toujours utilisé et je préfère utiliser l'attribut pour réinitialiser les styles par défaut sur les tableaux.

Rémi Parmentier: Une autre pratique exemplaire que j'aimerais partager est la suivante: ne divisez pas les éléments visuels. C'était en fait une pratique très courante il y a peut-être une décennie. Lorsque nous avions de grandes images, c'était toujours mieux, au moins, il était toujours partagé que vous deviez la scinder pour rendre le téléchargement plus rapide, etc., mais ce n'est pas le cas aujourd'hui.

Rémi Parmentier: Ne pas scinder le visuel présente en réalité beaucoup d'avantages. La première est qu’il est plus facile à maintenir. Si vous avez un gros visuel dans votre courrier électronique et que c'est vendredi soir, votre chef de projet vous demande de le changer à la dernière minute. Vous n'avez donc pas besoin d'ouvrir Photoshop pour découper vos images à nouveau et à l'endroit où vous le souhaitez. J'ai tout. Vous pouvez simplement remplacer cette image et vous avez terminé.

Rémi Parmentier: C’est aussi meilleur pour l’accessibilité, car vous n’avez qu’une seule image, vous avez un seul attribut alt. C'est plus simple et meilleur pour l'accessibilité. Les performances Web sont également plus avantageuses, car télécharger une image de 100 Ko est théoriquement plus rapide que de télécharger cinq images de 20 Ko.

Rémi Parmentier: En effet, pour chaque image de 20 Ko, la demande au serveur doit être faite et nous devons attendre la réponse cinq fois. Même pour les très petites micro-transactions entre le client et le serveur, ceci ajoute au plus d'image que vous avez, et cela peut ralentir le téléchargement de votre image de courrier électronique, c'est donc quelque chose à éviter.

Rémi Parmentier: Ensuite, sur le WebKit, il y a aussi un comportement très étrange. Lorsque vous utilisez une transformation CSS sur des images découpées en tranches, WebKit aura des lignes très fines entre les images divisées. Je voudrais juste vous montrer une démo de cela aussi. Revenons à ma première image T-Rex ici, si j'ajoute une petite transformation qui redimensionnera l'image, vous pouvez voir ici qu'à ce rapport, de très petites lignes apparaissent dans chaque tranche de mon image.

[1965] Rémi Parmentier: En effet, WebKit ne gère pas correctement la manière dont il devrait redimensionner des images comme celle-ci. Il y a peut-être une taille de nœud quelque part qui ne calcule pas correctement. Vous vous retrouvez donc avec de petites lignes de poils comme celle-ci. Oui, la meilleure pratique consiste à éviter de scinder vos visuels.

Rémi Parmentier: En réalité, cela se produira dans les clients de messagerie, car dans Outlook.com, par exemple, si votre courrier est plus gros. que la vue réelle des e-mails dans les clients, votre e-mail sera redimensionné à l'aide d'une transformation CSS pour alimenter le port d'affichage du client de messagerie. Il faut se méfier de cela.

Rémi Parmentier: Enfin, en ce qui concerne la séparation visuelle, j’essaie toujours de ne pas le faire parce que ce genre de choses se produit. C'est quelque chose qui a été partagé sur Reddit il y a presque 10 ans. Ceci est un courriel de LinkedIn et le visage de cette jeune femme a été coupé en deux, peut-être parce que le texte était plus long que prévu ou peut-être parce que ici l'utilisateur a choisi de configurer son client de messagerie avec une police plus grande que prévue, Ce genre de choses peut arriver dans les clients de messagerie, tout comme sur le Web. Si vous voulez éviter ce genre de situations étranges, ne divisez pas les éléments visuels.

Rémi Parmentier: Ensuite, c’est un problème important. Ceci est des tableaux pour les mises en page. C’est sûrement la chose la plus courante à laquelle les gens pensent quand ils pensent aux courriels HTML. Cela nous agace toujours car nous n'avons généralement pas besoin de tables pour les mises en page, à l'exception d'un client de messagerie électronique, à savoir Outlook sur Windows de 2007 à la dernière version 2019.

Rémi Parmentier: La raison comme nous l’avons déjà dit, c’est parce que toutes ces versions d’Outlook utilisent Word comme moteur de rendu. Word n'interprète pas très bien HTML et CSS. Il y a en ligne cette documentation sur ce dont il devrait être capable, mais c'est assez difficile à lire et à comprendre, alors j'essaie de faire en sorte que ce diagramme le comprenne réellement.

Rémi Parmentier: Il ressort de cette documentation que la prise en charge de CSS par Outlook varie en fonction des éléments sur lesquels vous utilisez CSS. Le corps et l'étendue seront différents de ceux div et p, puis de toutes les autres balises HTML prises en charge.

Rémi Parmentier: Tout d'abord, si vous avez un corps et une étendue, vous ne pouvez utiliser que ce que Microsoft appelle les propriétés CSS de base. C’est la propriété couleur, la propriété police, alignement du texte et couleur d’arrière-plan. Sur l'élément body et l'élément span, vous ne pouvez utiliser que ces quatre propriétés CSS.

Rémi Parmentier: Ensuite, dans les divs et les paragraphes, vous pouvez utiliser ces quatre propriétés à partir du niveau de base, mais vous pouvez également utiliser deux nouvelles propriétés à partir de ce que Microsoft appelle le niveau Coreextended. Dans ce niveau, vous avez deux nouvelles propriétés, les propriétés de retrait de texte et de marge.

Rémi Parmentier: Ensuite, pour toutes les autres balises, vous pouvez utiliser les propriétés des deux niveaux précédents. Ce que Microsoft appelle le support Full CSS avec beaucoup plus de propriétés CSS, mais je pense que les plus intéressants sont la largeur, la hauteur, le remplissage, la bordure et ce type de propriétés permettant de définir des éléments.

Rémi Parmentier: Cela signifie ici que si vous souhaitez utiliser les propriétés width et height et le faire fonctionner dans Outlook, vous ne pourrez pas le faire sur une div, car celle-ci ne prend en charge que les propriétés Coreextended et Core CSS. Vous devrez utiliser des tableaux pour ces propriétés CSS et la même chose pour le remplissage et la bordure.

Rémi Parmentier: Je le résume généralement aux quelques instructions suivantes pour utiliser des tableaux. J'essaie d'utiliser uniquement une table lorsque je veux définir une largeur fixe sur un élément. Si j'ai besoin qu'un élément ait une certaine largeur, je vais utiliser un tableau et définir la largeur à partir de ce tableau.

Rémi Parmentier: De plus, si je souhaite définir deux éléments de bloc côte à côte Même Outlook ne prend pas en charge les propriétés de mise en forme CSS avancées. Même si float n’est pas vraiment pris en charge, si vous devez avoir deux éléments côte à côte, créez un tableau avec deux cellules et ces deux éléments. les éléments seront alors côte à côte. J'utilise ensuite des tableaux chaque fois que j'ai besoin de définir un remplissage, une couleur d'arrière-plan ou un style de bordure. Cela rend très dépendante, très robuste d'utiliser un tableau pour ces styles uniquement.

Rémi Parmentier: Maintenant, un problème avec les tableaux est quelque chose que nous avons appris il y a longtemps que les tableaux ne sont pas faits pour la présentation. Ils sont faits pour les tables de données réelles. Cela peut être très problématique pour les lecteurs d'écran en particulier. Afin d’améliorer l’accessibilité ici, nous utiliserons l’attribut role = presentation chaque fois que nous créerons un tableau de présentation.

Rémi Parmentier: Permettez-moi de vous montrer rapidement comment cela changera la le courrier électronique est interprété par un lecteur d'écran. Je vais prendre une nouvelle démo ici. J’ai reçu ce courrier électronique de Jacadi, une marque française de vêtements pour enfants. Ils ont cette table ici avec différentes tailles de produits. C'est en fait une table à l'intérieur du code. J'ai pré-enregistré une vidéo ici pour vous montrer comment elle est lue par un lecteur d'écran.

Lecteur d'écran: Comptage des paires, contenu Web. Vide, vide, vide. Colonne du tableau 1. Neuf rangées. Vide. Colonne 1 de 1. Ligne 2. Neuf tableaux de niveau 2, sept colonnes. Une rangée, colonne 1 sur 1. Blanc. Colonne 3 sur 7. Blanc. Colonne 4 sur 7. Blanc. Colonne 5 sur 7. Blanc. Colonne 7 sur 7. Fin du tableau. Rangée 3 sur 9, en blanc. Colonne 1 sur 1. Ligne 4 sur 9, ligne 2, tableau, sept colonnes, une vierge. Colonne 1 sur 7. Blanc. Vide. Fin de table. Rangée 5 sur 9, en blanc. Rangée 6 sur 9, vierge. Colonne, vide, vide, fin de colonne du tableau. Rangée 7 de 9, vierge. Rangée 8 de la rangée 2, tableau 2, en blanc. Colonne 1, vierge. Fin de colonne du tableau. Rangée 9 de 9 en blanc. Fin de colonne du tableau.

Rémi Parmentier: C'est terrible. C'est tellement énervant. Voyons maintenant comment nous pouvons réparer ces cellules. Nous pouvons y remédier en ajoutant les attributs role = presentation. Ce n’est pas quelque chose qui se lit d’une table à l’autre, nous devons donc ajouter cet attribut chaque fois que nous aurons une nouvelle table. Nous avons quelques tables imbriquées ici, donc nous en ajouterons quelques-unes. Voici comment sonnent les résultats.

Lecteur d’écran: Blank. Vide. Voix off.

Rémi Parmentier: C'est tellement mieux. C'est tellement plus doux et cela rend l'expérience beaucoup plus agréable. J'espère que cela vous a convaincu que vous devriez toujours utiliser autant de tables que possible, mais si vous le faites, utilisez les attributs role = presentation sur ces tables.

Rémi Parmentier: Maintenant, une étape possible Encore plus loin, puisque les tables sont principalement destinées à Outlook, nous pouvons utiliser des commentaires conditionnels pour rendre ces tables uniquement visibles dans Outlook. Les commentaires conditionnels sont en fait quelque chose qui était disponible dans Internet Explorer également jusqu'à ce que je pense I9. Avec ceux-ci, si les MSO sont en texte, nous pouvons dire aux frontières que tout le contenu suivant dans ce commentaire conditionnel sera disponible uniquement pour les clients MSO, il s'agit donc principalement d'Outlook.

Rémi Parmentier: Ensuite, entre les commentaires des tables d'ouverture et de fermeture, nous pouvons avoir une division avec un rôle ou des éléments similaires à ceux d'une bordure Web classique, même si les courriers Web choisiront la division et Outlook, la table. Voici comment j'ai reçu la plupart de mes courriels vidéo.

Rémi Parmentier: Une autre bonne pratique consiste à utiliser une marge ou un rembourrage pour l'espacement. Cela vise principalement à éviter les conteneurs vides, les cellules vides comme celle-ci, où nous avons un rôle à jouer dans une cellule d'une hauteur de 20, puis nous avons des TD avec une largeur de 20 pour créer une marge avec ce contenu. Je vois encore que cela se fait beaucoup et que cela rend votre code très lourd. C'est moins lisible et c'est vraiment mauvais à mon avis.

Rémi Parmentier: La bonne façon de faire quelque chose comme ça serait d'utiliser une table si vous le souhaitez et d'avoir le style de rembourrage le premier. TD, puis à l’intérieur de la marge d’utilisation, pour espacer les balises les unes des autres. Cela fonctionne encore très bien dans chaque client d'image populaire et dans Outlook également.

Rémi Parmentier: Maintenant, le petit problème qui peut se produire dans Outlook et Windows est la couleur d'arrière-plan. Si vous utilisez la couleur d'arrière-plan sur l'un de ces éléments avec une marge, elle saigne réellement à travers la marge. Voici un exemple où je devrais avoir une marge entre le fond rouge et le fond bleu, mais dans Outlook, la marge est en fait de la même couleur que le fond de cet élément. Dans ces cas, la solution consiste peut-être à utiliser une autre table et à imbriquer votre contenu de cette manière dans des éléments d'espacement, mais si vous n'utilisez pas d'arrière-plan, alors la marge est vraiment sûre, même dans Outlook.

Rémi Parmentier: Enfin, c'est peut-être ma recommandation préférée. C’est pour le faire fonctionner sans balises de style. Il ne s’agit pas nécessairement d’avoir ce rendu HTML brut, mais de penser à des améliorations progressives et à une dégradation progressive et à la façon dont vos e-mails vont ressembler sans cette directive. C'est quelque chose d'assez inhabituel dans la coopération Web car cela ne se produit pas sur le Web, mais le fait de ne pas avoir de balise style a souvent beaucoup d'incidence sur les clients de messagerie.

Rémi Parmentier: Tout d'abord, ce n'est pas tout. Les clients de messagerie prennent en charge les balises de style. L’un des exemples les plus courants que je vois est peut-être que Gmail sur ses applications mobiles sous iOS et Android vous permet de configurer une adresse électronique tierce. Vous pouvez utiliser votre adresse Yahoo ou Outlook.com dans l'application Gmail. Si vous le faites, tous les courriels que vous avez cochés ne prendront pas en charge les balises de style. C'est ce que Email Geeks a surnommé GANGA pour les applications Gmail avec des comptes autres que Gmail. C'est un cas très courant que vous pouvez avoir.

Rémi Parmentier: Vous avez alors beaucoup de cas pour des clients de messagerie plus petits ou locaux ou internationaux comme SFR en France ou Yandex et Mail.ru en Russie , etc. Même à ce jour, de nombreux clients de messagerie n'acceptent pas les balises de style, donc si vous voulez rendre votre code plus robuste, assurez-vous qu'il peut fonctionner sans balise de style.

Rémi Parmentier: Parfois, c'est aussi temporaire. Par exemple, au cours de la dernière année environ, Gmail a eu deux jours où les balises de style ont été complètement supprimées de chaque courrier électronique de chacun de ses clients de messagerie. Nous ne savons pas pourquoi cela est arrivé. Il n'y a eu aucune communication à ce sujet, mais il y a de bonnes chances qu'ils aient détecté une sorte d'attaque utilisant certains styles. Ils devaient donc le supprimer très rapidement et sécuriser leurs utilisateurs. Ils ont donc supprimé le support des balises de style pendant quelques heures. ou presque une journée. Si vous deviez envoyer une campagne ce jour-là, vous auriez perdu de la chance si vos courriels nécessitaient des balises de style pour fonctionner.

Rémi Parmentier: Parfois, cela est également contextuel. Par exemple, dans Gmail, lorsque vous transférez un e-mail à une personne, vous n’avez plus de balises de style, ou lorsqu’un e-mail est affiché dans sa version malpropre, vous savez que vous avez une vue de l’ensemble de la messagerie au bas de votre écran. email parce que c'était trop long, si vous affichez votre email dans cette fenêtre, vous ne pourrez pas avoir de balise de style.

Rémi Parmentier: Enfin, parfois, c'est un buggy. Par exemple, dans Yahoo Android de l'application, la tête est supprimée. Ainsi, toutes les balises de style qu'elle contient sont également supprimées, mais seulement la première tête. Nous ne pensons généralement pas que les documents HTML ont plusieurs têtes, mais vous pouvez le faire totalement.

Rémi Parmentier: C’est une pratique courante depuis quelques années maintenant. avec ce bug dans Yahoo. Si vous avez une deuxième tête avec votre style, elle fonctionnera parfaitement dans Yahoo Android et dans la plupart des clients de messagerie. Nous avons juste cette tête vide en premier pour que Yahoo la dépouille, et cela fonctionnera.

Rémi Parmentier: Maintenant, ce que je veux dire en faisant un email fonctionne, c'est que l'email doit ajuster sa couche à n'importe quelle largeur sans défilement horizontal et le courrier électronique doit refléter la marque de l'expéditeur. Cela peut être des couleurs souvent, des polices ou autre, mais assurez-vous que cela fonctionne sans styles.

Rémi Parmentier: Pour ce faire, nous pouvons utiliser des styles en ligne. C'est pourquoi la plupart des e-mails utilisent encore le style en ligne, et je le recommande vivement à la plupart de vos styles. Assurez-vous que la marque, les couleurs et tout ce qui est produit peut avoir un style juste en ligne.

Rémi Parmentier: Ensuite, abordez le courrier électronique mobile pour vous assurer que vos courriels fonctionnent correctement, du bureau au mobile, nous avons différentes solutions. La première consiste à rendre votre courrier électronique fluide. I’ve got a little demo here as well, which I will show you right now.

Rémi Parmentier: This is an email that I’ve worked on almost four years ago for a French magazine, GEO. It’s got a lot of interesting things here. The first one is this grid here. If I try to resize it to make it responsive, you can see that it’s 100% fluid and it will scale accordingly to whatever the width for the image client is.

Rémi Parmentier: This works absolutely well without even a single style tag. This is just two tables on top, one for each lines, and we’ve got image inside it and the image are set with a fluid width, and so this works well enough even without style tags. This is good to have elements like this that can scale accordingly.

Rémi Parmentier: Now, this might not be the most optimal for every email, so another technique is to make your content hybrid. “Hee-breed,” or “hi-breed,” I’m not sure how you pronounce it, sorry for that, hybrid comes from the fact that you can still use media queries, but only as progressive enhancements, and then you need to make sure that your layout can fall back gracefully even without styles.

Rémi Parmentier: I would go back to this exact same email that I just showed you. A little bit lower here, we’ve got this gallery of user portraits. We can scale it as well. We have three columns here and then it will get on to two columns, and then only to one column.

Rémi Parmentier: The way this works here is using div width display in my block. We’ve got actually three divs like this next to each others and they all have a width of 33%. They will set so three can sit next to each others. They all have a minimum width of 140 pixels, so if there is no longer enough room to fit all those three elements because they’re in display inline block, they will naturally match even CSS flow down next to each others. This is a pretty good way to make it work like this.

Rémi Parmentier: I also use CSS and media queries here to make it a little bit more graceful when you have content here. If I disable the styles here, if I remove all of this, you can see that the layout has changed a little bit. We still have two columns, but they’re more stuck together. The layout still works appropriately where we can go from three to two to one layouts even without any styles, just with both div display and line blocks.

Rémi Parmentier: Then, perhaps the final, most popular way to make your emails work on mobiles is to make them mobile-first, to code them mobile-first. I will once again go back to that exact same email. You can see here that … Oops, it’s not fitting. I’ve got these two email columns next to each others. If I resize my window a little bit smaller, they will stack on each others.

Rémi Parmentier: Now because this is coded mobile-first, it means that this is actually the default layout for this zoom. On them, I use a min-width media query to change the layouts on desktop, on larger window sizes to make this work. If I remove all the styles here, just like I did before, you can see that now, our images are stacked on each others just like on mobile. This is what you’ll get when you code mobile-first. You get mostly your mobile view, but larger on desktop. This is really a lot of considerations to have when you’re coding emails for mobiles and for every email clients.

Rémi Parmentier: That’s pretty much it for me. All those recommendations, all those guidelines, you can find them online on GitHub, where I have these documents available. I really strongly encourage you really to share it within your colleagues and also to contribute to it.

Rémi Parmentier: If you think you have good recommendations that could apply to every emails you will code, feel free to share with me, feel free to contribute to this document as well. Hopefully you will have some questions. You can find me on Twitter or on my blog or you can send me an email as well if you have any questions after this session. Thank you.

Scott: Thank you very much, Rémi. “Re-my.” That was really very good. I’ve had a lot of questions about … Oh, hey, Vitaly.

Vitaly: Hello. Hello, Rémi. I’m so sorry about being late. Hello, everybody, dear Smashing members. I had a train delay and all. Scott, you wanted to say something? Sorry I interrupted you.

Scott: No. There was just two questions I was going to get out of the way. One was from Pawan, who’s a very, very active member of the Smashing membership. He is asking us, any thoughts on applying fonts consistently through HTML email?

Rémi Parmentier: Sorry, can you repeat?

Scott: Do you have any thoughts about applying fonts consistently through HTML email?

Rémi Parmentier: Yes. Well, for fonts, I usually encourage my clients to use web fonts in emails because it’s always better when you can have your own brand fonts. Now the thing to have in mind is that it won’t work everywhere. When using web fonts, especially, it almost works nowhere. It works in Apple Mail and in Thunderbird and maybe a few local email clients, but that’s really it. It doesn’t work in Gmail, it doesn’t work in Yahoo. If you can adapt to that, if that’s good for you, then go ahead and do it.

Rémi Parmentier: Now, the problem that you can have with web fonts like this is that if you try to use really funky fonts like Lobster or Pacifico on Google fonts, if it falls back to something like Arial or Helvetica, your email will definitely look very, very different. If you can use Montserrat and it falls back to Helvetica, that’s less a problem in my opinion. It really depends on the fonts you want to use and how much you are ready to not have this font in the cases where it won’t work.

Scott: That’s a really good point. There’s Zach Leatherman, who’s a very active member with Smashing and a presenter at SmashingConf, he’s done a lot of presentations about the fallback on fonts, so that’s interesting to make that correlation between email and web-based fonts.

Scott: Before I hand it over to Vitaly, my other question is, a lot of people are talking about interactive emails. There was actually, not this past SmashingConf, I believe the SmashingConf before, there was a presentation about interactive emails where you can actually complete an action just with one click of a button in an email, and mostly it’s based on AMP email. I was just curious, what do you know, what is AMP email and what’s the support for it currently?

Rémi Parmentier: AMP for Email is still something relatively new. It was announced by Google about a year ago, but it was only made available in Gmail desktop webmail about a few months ago, I think, in maybe April or something. AMP for Email is basically bringing the AMP Javascript framework to HTML email so that now inside Gmail, you can use interactive components like carousels or accordions, and you’ve got also, more interestingly, in my opinion, have live data.

Rémi Parmentier: If you’re selling clothes, for example, you can make sure that the clothes you’re presenting in your email are available in stock and are the ones in the best interest for your customer that’s viewing this email. This brings a lot of new customizations and possibilities for emails like that.

Rémi Parmentier: The thing is that it’s very still in its infancy and it mostly only works on Gmail desktops so far. It should come in on Gmail mobiles in the coming months, but then, there is also Yahoo and Outlook.com I think who said they were interested in implementing it.

Rémi Parmentier: Maybe this is something that will actually grab attention and go in the future. Yes, this is something I’m looking into and I’m really interested in. It’s still very hard to say if it will work and be successful, but there are a lot of interesting things in it.

Scott: Definitely. That falls back on what I was asking at the beginning before you started the presentation is, is there going to be some sort of standard that comes across for email clients? That’s my dream is that that will happen. On that note, Vitaly, I’m going to hand over to you for some questions.

Vitaly: Excellent. Thank you so much, Scott. Actually, Rémi, that was a brilliant presentation. Thank you so much. I learned-

Rémi Parmentier: Oh, thank you.

Vitaly: … a lot. I was a little bit not shocked, but in a way, I felt like it’s just wrong that we’re preaching these best practices for email which are not necessarily best practices full stop in 2019. It’s really about time that web standards have evolved.

Vitaly: We do have an open question from Pawan. Just before we do that, I have a couple, but one thing I wanted to know from somebody who’s so deeply motivated by the beauty and horror of email, I do have to find out, do you sleep well at night?

Rémi Parmentier: Oh, yes.

Vitaly: Excellent.

Rémi Parmentier: It depends because I have two small children, so not every night, but it’s not because of email.

Vitaly: Okay. The thing is, if you look back, let’s say, over the last, I don’t know, how many years have you been now in this madness?

Rémi Parmentier: Almost 15 years, but I really started digging into emails maybe five years ago, or maybe a little bit more, but yeah, about five years.

Vitaly: I’m curious, then, do you see that there has been a lot of progress in terms of email client supporting new features, broadening CSS support, Gmail, support of media queries and all? Do you see that the differences have been remarkable over the last five years or is it a very slow progress? Just so we can set expectations of what we should be expecting coming up next on the platform.

Rémi Parmentier: I would say both. It’s been both slow, but there has been progress. If you look back five years ago, five years ago, Gmail didn’t support media queries, and neither did Yahoo, I think, and neither did Outlook.com. Media queries are a huge tool to make email works well on mobile. The simple fact that those emails were able to adapt and add this to their list of CSS properties and features supported is actually a very good thing.

Rémi Parmentier: Now, it’s always a bit frustrating because it definitely doesn’t move as fast as the web is moving nowadays where you can see new features added in Chrome or Firefox every week and new articles about it. Things are moving slowly for really unknown reasons. That’s perhaps the biggest problem of emails is that everything is really opaque.

Rémi Parmentier: We don’t know how things work within Gmail or within Outlook and we have a lot of advantages for the web, people from the Chrome team, from the Firefox team sharing all the new advances in their browsers, but this is not the case in email clients, and this is really perhaps the most frustrating thing is that if you see a bug, if you have a problem, you pretty much have no one to talk to.

Vitaly: It’s a little bit loud here. I’m just in a park, I promise. Pawan is wondering, do you have any thoughts on embedding HTML forms in emails? Is it a good idea or not?

Rémi Parmentier: It can work. This is actually something that’s done a lot by us in the presentation you mentioned. Mark Robbins was the godfather of interactive emails. A lot of people actually use form in emails. Just like everything, you just need to realize that this won’t work everywhere. You need to think about, what happens if my form doesn’t work? Do I show something different? Do I have a link that sets to a form on my website? This is perhaps the hardest part, when you try to think of advances in emails like that. Every time, you need to think about what happens if this doesn’t work and what will I show to the people when it won’t work.

Vitaly: That makes sense. Well, I have so many questions. If you do have a few minutes, I just wanted-

Rémi Parmentier: Yeah, sure.

Vitaly: Because just today, I had to send out a wonderful email to our wonderful Smashing subscribers. One thing that stuck with me, and I wasn’t really sure how to deal with it. Not every client who understand media queries. Gmail does. You will have the media rule and then it will be all fine, but then, for some reason, when we’re sending out with Mailchimp and we do inline styles, actually inline styles in the attributes, what happens is you have the inline styles say font size 21 pixel, let’s say, on H2. Then you have a media that overrides it with font size 28 or something else.

Vitaly: Am I correct to assume that it’s probably a good idea to avoid bang importance one way or the other, because it will override whatever you have in the inline styles? If you have a media rule, and then that media rule, you actually have font size 30 pixels importance, will it override inline styles or not in most-

Rémi Parmentier: Yeah, definitely importance will override inline style.

Vitaly: But then it’s included in the media rule, right? If a client doesn’t understand media, they wouldn’t know-

Rémi Parmentier: Yes, exactly. Yes, which is why you once again need to think what happens if media is not supported. There, your inline style will be picked up. Maybe you will need to have the mobile-first approach and have the smaller font size inline and then use a min-width media query to have the different font size on desktop.

Vitaly: Makes sense. When you start building, do you actually build mobile-first or do you build desktop-first?

Rémi Parmentier: Well, it really depends. As I just show in my last three examples between-

Vitaly: Oh, sorry, I must have missed a few things.

Rémi Parmentier: Yeah. Between the three examples or if we do mobile-first, these are different approaches that you can have and that makes sense, depending on the contents you have. Most of the time, I usually go mobile-first, but it really depends on how you want your fallback to display. Sometimes it makes sense to have more desktop layouts and sometimes it makes more sense to have more mobile layouts.

Vitaly: For testing, we’re using Mailchimp just to see how it looks in different clients, but Doug Working is asking, do you have any recommendations for tools to test email code to see how it looks in different email clients?

Rémi Parmentier: Yes. There are two very good and very popular email tools that will allow you to take screenshots of how your email render across many, many email clients. Those are Litmus and Email on Acid. They work really similarly for email testing.

Rémi Parmentier: You just import your code and you will get screenshots very fast of how your email looks. This is really how I recommend to test emails because, of course, you need to do some ports manually as well, but it’s so much faster when you have a tool like this that it’s really more professional and you will win a lot of time by working with tools like this.

Vitaly: But then, it basically takes screenshots that you have to analyze. If you discover something like a major bug, how do you debug? Any tools for remote debugging, so to say?

Rémi Parmentier: Yeah. Debugging is the hardest part. In webmails, actually, it’s pretty easy because since the webmail is just a webpage, you can fire up your browser inspector tools and inspect the webmail’s code. This is really something interesting to do. I encourage everyone to do it at least once in a while because you will see how the webmail transforms your code in ways that you maybe have never imagined, like prefixing and renaming the classes you can have in your code.

Rémi Parmentier: This is a good way to see if maybe an image client has removed some of your styles or maybe if you did a mistake somewhere. For webmail, this is the best way to debug. For other email clients like Outlook, this is really a try-and-retry approach where you just send a code, change something, resend the email-

Vitaly: It sounds like fun.

Rémi Parmentier: Yeah, this can be a bit irritating. With the experience, you do less and less of this, but yes, unfortunately, there are no developer to see in Outlook.

Vitaly: That makes sense. One more thing that actually came up as well, is it safe to use SVG in emails? Or if you’re having the same image, would you prefer to use SVG or would you recommend to stay away from SVG and use PNG or JPEG instead, or God forbid GIF?

Rémi Parmentier: GIFs are actually still very popular in email-

Vitaly: I know. I noticed.

Rémi Parmentier: … but there are actually no reason because PNG is just as well-supported as GIFs for that matter. Regarding SVGs, just as my previous answers, I will say do it if you can manage to make it fall back to something I think for other email clients.

Rémi Parmentier: I think SVG works very well in Apple Mail, in Mac OS and iOS. It might work in a few more email clients, but I don’t think it works well in webmails. If you can have a distant SVGs that you call maybe in … For example, if you use a picture tag, you can have a source with your SVG, so this will be picked up by Apple Mail. Inside this picture, you can have an image tag as a fallback with a regular PNG or JPEG. This will work in other email clients.

Rémi Parmentier: There are different ways to tackle this kind of things, but SVG is definitely not the first format for images that you were shown when you built emails, but this is definitely something you can use, even though it won’t work everywhere. If you can have the proper fallback, then go ahead and use it.

Vitaly: Willow Cheng is asking, would you have recommendation on design tools which could let you design and export email in HTML?

Rémi Parmentier: No. Unfortunately, nothing that I can think of right now. Because most of the time, tools that will offer you to generate your HTML from design tool will be really rubbish because it will be either completely outdated and not work well in most modern versions of email clients, so I would actually recommend to stay away from those tools. From design point of view, I’m not sure there are any tools that will let you export clean, proper HTML for emails.

Vitaly: That’s actually an answer I was expecting, to be honest. Maybe just one final question. I’m sure I’ll have more later, but I know you do also have family and all and it’s quite late as well, and I get to meet you in Freiburg, so this is just a couple of weeks from now, so at SmashingConf Freiburg. This is going to be exciting.

Vitaly: I do have a question, though, still. I remember for a while, maybe a year ago, maybe two years ago, I found these two resources which were great. One of them was responsiveemailpatterns.com. The other is responsiveemailresources, or something like that, .com. One of them has gone away. It’s just down I think at this point, but I will also post the link later. Can you recommend some websites, resources where you can get copy-pastes almost email codes, snippets or something that you can reuse on a daily basis? I have heard that you might be working on something. Was I wrong?

Rémi Parmentier: I’m not sure, but I won’t talk about this for now, but it’s always [inaudible 01:04:56] snippets of codes that you can share because there are a lot of factors inside an email that can make your code behave differently. Every time there’s a tool that says it makes bulletproof backgrounds or bulletproof buttons, for example, you can always very easily, very shortly find email clients in which this doesn’t work properly. This is always a problem.

Rémi Parmentier: I remember the websites we were talking about, about responsive patterns, but I actually don’t know who were maintaining those. I don’t think they are ever really updated. As for websites, I can’t think of any right now. Maybe it will come later, that’s too bad, but the two things I will recommend is, if you’re into Twitter, follow the Email Geeks hashtag. That’s #emailgeeks, G-E-E-K-S. There are always a lot of people sharing good resources and the latest good articles that are always interesting.

Rémi Parmentier: The other thing I recommend is to join the Email Geeks at Slack channel. This is a really good community that’s growing a lot. There are all sorts of channels for marketing or for design or for code. People are really, really nice there and really always trying to help and almost available at any hours of the day, so this is incredible. If you look up for Email Geeks Slack on Google, you will see a subscription page that you can join. I hope you can join and just say “Hi” if you come.

Vitaly: Just one final, just the really, really last one, and then I’ll let you go. Sorry, excuse me if you mentioned it already in the session, but I’m wondering, as of today, as of 2019, looking at the best practices and the email clients, what are the baseline where you would say, let’s support this kind of client?

Vitaly: Because at this point, when we think about a 8, sometimes you obviously want to search something accessible to a 8, but you’re not going to optimize for a 8. We’re getting to the point where some companies can actually start dropping a 9 in the same way, but again, we’re quite far away yet.

Vitaly: When it comes to email clients, is Outlook 2013 still a thing? I remember the big update that Outlook brought in 2013 changed a lot of things in email, if I remember correctly. As of today, when we look into the landscape of email clients, what is the baseline we absolutely have to support at least?

Rémi Parmentier: I think the-

Vitaly: To support.

Rémi Parmentier: The others’ basis is Outlook 2007, because this is something actually pretty annoying is that this is used in a lot of big companies, and those big companies don’t pays new license for new versions of Outlook every year and they pay for a decade or so. There are still quite a lot of people I think using those older versions. This is still something that we have to account for.

Rémi Parmentier: Now, it’s not really that much a problem because between Outlook 2007 and Outlook 2019, unfortunately there weren’t that much of progress made because it’s still Word as a rendering engine. I think this is maybe the worst case we have to support mainly because, yes, we are not getting rid of those versions of Outlook anytime soon, I think.

Vitaly: That’s very optimistic, a bright outlook in life. I like that. I respect that. Thank you so much, Rémi, for being with us today and sharing all the wonderful insights.

Rémi Parmentier: Thank you for having me.

Vitaly: Of course. Will you be kind enough to share the slides of your presentation as well?

Rémi Parmentier: Yes, absolutely.

Vitaly: If you have any other resources that come to your mind, please send them over to us and we’ll publish them, too.

Rémi Parmentier: Sure.

Vitaly: All right? That’s been very exciting. It wasn’t actually as dirty as I thought it would be. Just humble in a way, even. I didn’t see anything that would screech and make me feel uncomfortable at night when I want to sleep. Thank you so much for that, Rémi.

Rémi Parmentier: Thank you.

Vitaly: On that note, Scott, any other updates we should keep in mind or anything we need to mention?

Scott: I was going to ask you, Vitaly. Tomorrow, we have another Smashing TV.

Vitaly: Yes. Friends, we’re trying something else and something new every time. Apparently, well, finally, today we got … I hope we received, because I didn’t get the confirmation yet, but we’re supposed to receive the first copies of the Smashing Print or our new printed magazine dedicated to topics that are often not covered well enough on the web, or maybe that just got lost in the myriad of workflows.

Vitaly: The first issue is dedicated to ethics and privacy. As a dedication to that, we’re going to have a live session, a live stream on Smashing TV tomorrow with five panelists, all contributors to this first issue of Smashing Print. It’s going to be broadcasted on YouTube. If you go on Smashing.TV, you’ll find the links, but we also will be publishing an article tomorrow featuring the links and everything.

Vitaly: The printed magazine, that by the way, Smashers, the ones with $9 plan are getting it for free, and the members with $5 plan are getting the ebook and the heavy discount on the ebook as well. Rémi is getting a printed magazine as well just because he’s so awesome.

Rémi Parmentier: Thank you.

Scott: Thanks, Rémi.

Vitaly: Beyond that, we also have a few more things coming up, I think.

Scott: On the 13th, Mr. Paul Boag, who has been a very prominent mentor in the Smashing community, many Smashing Conferences, many webinars, August 13th, Paul Boag is doing the customer journey mapping where UX and marketing meet.

Vitaly: Then we have Cassie Evans on August 20th exploring the interactive web animation with SVG. This is going to be fun as well. If you actually ever wanted to do a bit more or try to figure out a better workflow for SVG animation, that’s definitely a session not to miss, so looking forward to that.

Vitaly: All right, I think we’re good here. Any more announcements, major announcements, Scott, that we need to share with the world around us?

Scott: You’re making me feel like I’m forgetting something, but … SmashingConf Freiburg?

Vitaly: Yes, we do have a SmashingConf Freiburg, where Rémi is going to speak as well, but we also have the videos of Toronto conference which will be released today, or maybe tomorrow. Maybe they already released. See how well-prepared I am. Watch out for that and you’ll get them, you’ll find them also in your dashboard, so keep that in mind. D'accord. I think we’re good!

Scott: Okay. Thank you everybody for attending. Thank you-

Vitaly: Thanks, everyone, for attending.

Rémi Parmentier: Bye! Thank you and bye.

Vitaly: Thank you and see you next time. Thank you, Rémi. Bye-bye.

Rémi Parmentier: Thanks. Bye.

Vitaly: See you next time.

SmashingConf Freiburg Presentation “Think Like An Email Geek”

At the end of the Webinar, Vitaly mentions that Remi will be speaking at Freiburg. You don’t have to wait for that as we also have that video to share with you, along with the slides and resources.

We hope you enjoyed this look into HTML email. If you would like to enjoy more of this kind of content, plus the chance to interact with the presenters and other members while helping to support the creation of independent content for web designers and developers join us here.

(ra, vf, il)