Lors de la création d'e-mails HTML, devons-nous utiliser des balises html, head, body?


113

Dans mes vues d'e-mails, je fais généralement quelque chose comme ...

<dl>
   <dt>Name</dt>
   <dd>Value</dd>
</dl>

Dois-je le faire comme ça?

<html>
  <head></head>
  <body>
    <dl>
       <dt>Name</dt>
       <dd>Value</dd>
    </dl>
  </body>
</html>

En d'autres termes, comme si je marquais un document autonome?

Je suppose que je peux supposer en toute sécurité que n'importe quel client de messagerie Web le supprimera?

Quelle est la bonne façon?


Pour ce que ça vaut, Thunderbird sort les html, headet les bodybalises dans ses messages.
palswim

Réponses:


44

La bonne façon est de suivre la norme HTML . Vous pouvez valider votre page HTML ici .

Votre client de messagerie doit le suivre et doit rejeter ce qui n'est pas pris en charge ou ce qui n'est pas sécurisé, comme javascript.

MISE À JOUR: après plusieurs votes négatifs de personnes qui se mettent en colère lorsque vous leur dites de suivre les normes, je vais exposer quelques raisons pour lesquelles les normes suivantes pourraient être bénéfiques ici:

  1. un webmail disposé à afficher votre e-mail en pleine page, pourrait conserver votre format.
  2. un webmail supprimera simplement les balises et les attributs dont il ne veut pas. Mais vous ne pouvez jamais savoir lesquels.
  3. Il est plus facile de trouver des composants (côté serveur) qui respectent les normes de format, et donc moins sujets aux erreurs. Les analyseurs ne respectant pas les normes pourraient éventuellement ne pas fonctionner, ce qui empêcherait l'affichage de votre courrier électronique.

54
-1 La bonne manière est de le tester chez les clients concernés. Si les clients de messagerie doivent suivre les normes, pratiquement aucun d'entre eux ne le fait.
Dan Blows

27
mschonaker est correct. Si tout le monde commence à suivre les normes, alors l'utilisation sera ... enfin ... standardisée. Sinon, tous les développeurs doivent implémenter des hacks pour la saveur du jour (en pensant à vous, IE6!). La BONNE manière est de suivre les normes.
cjcela

4
Il n'y a pas de norme pour les "emails html". Vous pointez vers la norme pour le HTML.
rds

2
Je suis d'accord avec cette réponse, alors que de nombreux clients rendent le html invalide de toute façon, le format le plus fiable qui sera rendu sur la plupart des clients est d'avoir du html valide!
markmnl

3
C'est la bonne réponse. Le type mime de la partie ou du corps sera text / html. Quel que soit le contexte, ce type doit être respecté par les normes, qu'il s'agisse d'un navigateur Web ou d'un client de messagerie. @cjcela a la bonne idée, si nous continuions tous à soutenir IE8, le Web n'évoluerait pas. Si nous ne respectons pas les normes, comment le rendu du HTML dans le courrier électronique évolue-t-il? Ce que vous devez faire est de vous en tenir aux normes, mais sachez que des éléments tels que les feuilles de style dans heads peuvent être ignorés et avoir une solution de rechange gracieuse.
Brett Ryan

33

Que vous incluiez ou non les balises html / head / body n'a aucune importance - elles sont toujours facultatives et n'affecteront en rien le rendu du document.

Ce qui compte le plus est de savoir si le mode bizarreries est activé ou non. Malheureusement, vous ne pouvez pas contrôler cela dans un paramètre de messagerie Web. Les tableaux et les styles en ligne sont vos amis. Le mieux est de tester autant de clients de messagerie Web et de bureau que possible.



4
"ils sont toujours facultatifs et n'affecteront pas le rendu du document" ce qui n'est tout simplement pas vrai, de nombreux rendus sont moins tolérants aux pannes et peuvent à juste titre choisir de ne pas rendre le code HTML invalide.
markmnl

Que se passe-t-il lorsque le client de messagerie a un lien "Afficher cet e-mail dans le navigateur"? Ce sera au navigateur par défaut de rendre le HTML invalide.
Sergey

13

De nombreux articles sur ce fil sont plutôt anciens et, par conséquent, ils ne sont plus exacts.

De nos jours, les e-mails HTML devraient inclure une déclaration doctype, html et body si vous avez l'intention de faire quelque chose d'extraordinaire.

Il existe une multitude de guides sur ce sujet qui peuvent vous aider à apprendre à coder correctement un e-mail HTML, mais la plupart d'entre eux ne tiennent pas compte des spécificités d'un doctype, c'est ainsi que je suis tombé sur votre question.

Je vous suggère de lire les 2 articles suivants qui proviennent d'équipes réputées familières avec les différents problèmes:

prise du moniteur de campagne

email sur la prise d'acide


Drôle ... vous dites que les articles ici sont anciens et vous mettez un lien dans votre réponse vers un article de blog qui a 7 ans!
Alexis Wilke

2
Je l'ai fait, mais les articles de blog qui ont été sélectionnés ont été soigneusement choisis en raison de leur nature faisant autorité, et ils étaient plutôt tournés vers l'avenir à l'époque. Les opinions qu'ils ont exprimées étaient assez rares à l'époque, en particulier lorsque vous comparez les affirmations datées qui sont partagées par les autres réponses ici.
kamelkev

@AlexisWilke et l'un des liens ont même été mentionnés ici 3 ans auparavant! Mais au moins, c'est dans une réponse maintenant pour que je puisse essayer de la remonter dans la liste avec un vote favorable
Hashbrown

11

Dépend entièrement du client de messagerie qui le reçoit. D'après mon expérience, la plupart des clients de messagerie qui interpréteront le HTML ne se soucient pas de savoir si vous avez des balises full body / head / html, etc. En fait, vous n'avez même pas besoin de ces balises pour la plupart des navigateurs. Vous devez avoir les balises head pour inclure le style / titre, etc. Sinon, elles ne sont pas vraiment nécessaires en soi. Je ne les ai jamais vus nécessaires.


3
Les balises html / head / body sont toujours facultatives.
Josh Lee

10

Il y a une chose que je sais être vraie: l'utilisation de balises d'ouverture et de fermeture HTML aidera à la notation générale des spams, car de nombreux filtres et pare-feu logiciels basés sur des appareils ajouteront un point ou plus à un e-mail qui utilise html mais ne l'utilise pas. les balises d'ouverture et de fermeture.


11
Avez-vous des preuves à l'appui de cette affirmation?
alex

10
J'ai observé ce comportement ces derniers jours simplement en "visualisant l'original" dans Gmail. Là, je pouvais voir un score de spam pour un e-mail sans balises de fermeture d'ouverture: par exemple, X-Spam-Level: * | X-Spam-Report: score = 1,6 tests = HTML_MESSAGE, HTML_MIME_NO_HTML_TAG, MIME_HTML_ONLY | X-Spam-Score: 1 - par exemple, voir wiki.apache.org/spamassassin/Rules/HTML_MIME_NO_HTML_TAG
Richard Hollis

1
J'ai également vu cela, et certaines entreprises ont leur seuil de mise en quarantaine du spam si bas que le manque de balises HTML peut suffire à empêcher votre courrier électronique de passer. Cette page ne répertorie pas les paramètres exacts disponibles mais j'ai vu le logiciel laisser un message concernant la règle "HTML_MIME_NO_HTML_TAG", avec la description "Message HTML uniquement, mais il n'y a pas de balise HTML". techlib.barracuda.com/BSF/SpamScoring
JHS

3

Je ne pense pas qu'il existe un bon moyen, mais essayer de rendre l'e-mail visible dans autant de lecteurs d'e-mail que possible.

Je vérifie généralement les e-mails dans Thunderbird, car Outlook pardonne plus.

Dans Thunderbird, c'est le code HTML d'un e-mail (j'ai une extension qui affiche le html)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
        This is the body text<br>
<div class="moz-signature"><i><br>
<br>
Regards<br>
Alex<br>
</i></div>
</body>
</html>

BTW, j'utilise le courrier électronique en texte brut pour tous mes formulaires Web chaque fois que je le peux. J'ai eu de nombreux problèmes avec les e-mails BlackBerry en utilisant des e-mails html + texte brut.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.