5568 sujets

Sémantique web et HTML

Pages :
Camarades, bien le bonjour à tous !

Voilà, ça fait un moment que je me demande comment on fait.
Comment on fait pour mettre en oeuvre et coder une newsletter au format HTML qui soit codée dans les règles de l'art et des standards et potentiellement compatible avec toutes les plateformes de lecture d'e-mail et les logiciels clients de messagerie. Parce que les standards du web, l'accessibilité, la sémantique, tout ça, c'est génial, mais y a pas que des pages web sur Internet. Y a par exemple les newsletters et tous les divers e-mailings.

Du coup, 2 questions :

1. D'abord, sur le plan de la méthode et du code : Quelle méthodologie pour la conception et la réalisation de newsletter au format HTML ? En sachant que les contraintes et les problèmes sont les suivants : prévoir une version texte brute, prévoir une version HTML en double à une adresse web à laquelle on peut renvoyer l'abonné via un petit lien "si vous n'arrivez pas à lire cet e-mail, cliquez ici...". Mais aussi et surtout comment organiser le code HTML/CSS pour que tout cela reste standard et compatible ? Bin oui, c'est là le coeur du problème. On peut pas séparer, à ma connaissance, les feuilles de style dans un fichier CSS séparé lorsqu'il s'agit d'une newsletter. Et puis, on va pas mettre de <head> dans le fichier HTML, il me semble aussi. Bref, quelles sont les règles ? Je trouve rien là-dessus, y compris dans l'excellent livre de Raphaël Goetter sur CSS 2. Smiley cligne Une idée de nouveau chapitre pour une prochaine réédition ?

2. Ensuite, sur le plan des outils dynamiques : j'en ai essayé plusieurs et, pour l'instant, je n'ai pas encore trouvé la perle rare. Connaissez-vous un outil libre, simple, efficace, stable pour gérer les abonnements, désabonnements, envois et suivi de newsletter ? un outil qui marche du premier coup sans bug et qui permette de générer dynamiquement à partir d'un gabarit HTML/CSS le contenu de la newsletter, puis de l'envoyer, de l'archiver, etc. ? tout cela gérable et administrable par le gestionnaire du site, qui n'est pas toujours un informaticien ?
Modifié par piffeo (20 Jun 2008 - 16:19)
piffeo a écrit :
Camarades, bien le bonjour à tous !

Voilà, ça fait un moment que je me demande comment on fait.
Comment on fait pour mettre en oeuvre et coder une newsletter au format HTML qui soit codée dans les règles de l'art et des standards et potentiellement compatible avec toutes les plateformes de lecture d'e-mail et les logiciels clients de messagerie. Parce que les standards du web, l'accessibilité, la sémantique, tout ça, c'est génial, mais y a pas que des pages web sur Internet. Y a par exemple les newsletters et tous les divers e-mailings.


Bonjour,

Des ressources en anglais (pour la plupart) sont disponibles dans ce billet du blog: E-mail et CSS : du nouveau
piffeo a écrit :
Connaissez-vous un outil libre, simple, efficace, stable pour gérer les abonnements, désabonnements, envois et suivi de newsletter ? un outil qui marche du premier coup sans bug et qui permette de générer dynamiquement à partir d'un gabarit HTML/CSS le contenu de la newsletter, puis de l'envoyer, de l'archiver, etc. ? tout cela gérable et administrable par le gestionnaire du site, qui n'est pas toujours un informaticien ?

C'est une lettre au Père Noël cette demande, ou une vraie question? Smiley lol
a écrit :
C'est une lettre au Père Noël cette demande, ou une vraie question? Smiley lol

Smiley lol

Pour cela le service de Campaignmonitor à l'air vraiment pas mal.
Igor a écrit :
Des ressources en anglais (pour la plupart) sont disponibles dans ce billet du blog: E-mail et CSS : du nouveau

En effet. Merci bien. Les liens proposés dans le billet sont vraiment intéressants, même si je constate -- avec regret -- qu'il y a encore pas mal de désordre dans le domaine de l'email et des standards. Il semble que la mise en page par tableaux soit la solution la plus interopérable...
a écrit :
Il semble que la mise en page par tableaux soit la solution la plus interopérable...


Après avoir fais pas mal de test je confirme.

C'est également mieux d'utiliser les styles en ligne.
Modifié par matmat (21 Jun 2008 - 02:34)
matmat a écrit :
C'est également mieux d'utiliser les styles en ligne.

Pour être sûr de bien comprendre, ce qu'on entend par "styles en ligne", ce sont des feuilles de styles intégrées dans les balises HTML comme <div style="background:#fff;"> ? Cela veut dire qu'il faut éviter de déclarer un fichier .css externe ?
Modifié par piffeo (21 Jun 2008 - 11:00)
piffeo a écrit :
ce sont des feuilles de styles intégrées dans les balises HTML comme <div style="background:#fff;"> ?

NON, ce sont des déclarations CSS placées comme valeur d'attributs style. (Donc ce que tu as en tête, mais en évitant d'employer les mauvais termes. Smiley cligne )

piffeo a écrit :
Cela veut dire qu'il faut éviter de déclarer un fichier .css externe ?

Oui. Lire la documentation indiquée dans le billet du blog, elle est suffisamment claire.
Modifié par Florent V. (21 Jun 2008 - 12:34)
Florent V. a écrit :

NON, ce sont des déclarations CSS placées comme valeur d'attributs style. (Donc ce que tu as en tête, mais en évitant d'employer les mauvais termes. Smiley cligne )


Je dirais même plus, ce sont des déclarations CSS utilisées comme valeur d'un attribut style dans une balise ouvrante (X)HTML. Quitte à chipoter, autant être exhaustif. Smiley cligne

Tiens, tant qu'on y est, mettons-nous au clair : qu'entend-on, précisément, par l'expression "feuille de style" au singulier ? Une feuille de style, est-ce une règle CSS ou bien une suite de plusieurs règles CSS ? et si c'est une suite, est-ce une suite de plusieurs règles CSS incorporées dans le <head> d'un document HTML ou bien une suite de plusieurs règles CSS placées dans un fichier externe et lié à un document HTML grâce à une déclaration dans son <head> ? Hum ? Qu'est-ce qu'une feuille de style CSS ?
Modifié par piffeo (21 Jun 2008 - 12:58)
piffeo a écrit :
Une feuille de style, est-ce une règle CSS ou bien une suite de plusieurs règles CSS ?

Une suite de.
En général une feuille de styles comporte plusieurs sélecteurs, chaque sélecteur étant associé à une ou plusieurs déclarations CSS.

piffeo a écrit :
et si c'est une suite, est-ce une suite de plusieurs règles CSS incorporées dans le <head> d'un document HTML ou bien une suite de plusieurs règles CSS placées dans un fichier externe et lié à un document HTML grâce à une déclaration dans son <head> ?

Comme contenu d'un élément STYLE (à ne pas confondre avec l'attribut du même nom): feuille de styles interne.
Dans un fichier séparé appelé via un élément LINK, une règle @import dans un élément STYLE, ou une règle @import dans un autre fichier CSS: feuille de styles externe.
Salut à tout le monde !

Mon premier post sur le forum d'Alsa !!

Alors pour réagir a ce qui a déjà était dis, il faut d'abord savoir que beaucoup de client de messagerie ne prennent pas bien en compte les newsletter envoyé ...

La meilleur architecture a entreprendre, c'est évidement les tableaux. Pourquoi ? Car les clients de messagerie et même les clients de messagerie web tel que Outlook ou Yahoo mail, ne prennent pas en charge les propriétés CSS... et donc les positionnements.

Campaing monitor a d'ailleurs réaliser un superbe révérenciel pour une multitude de client mail ... a consulter absolument !

A voir ici !

Si vous voulez ajouter du css avec votre newsletter, il faudra obligatoirement passer par un code en ligne du style :


<font style="color:#FFF;">blabla</font>


A vos risques et périls, l'utilisateur ne saura peut être pas lire directement votre mail tel que vous voudriez qu'il le voit !

Ensuite, les code omnitures pour le routage et le tracking mail, doit se faire avec des outils développer a cet effet ...

Difficile de respecter les standards dans l'Emailing, car il existe bien plus de client de messagerie que de navigateurs ^^
Hello Thibow et bienvenue sur le forum, Smiley smile

merci pour ton message mais ce que tu dis est déjà indiqué dans le lien donné par Igor. Smiley langue
Thibow a écrit :

La meilleur architecture a entreprendre, c'est évidement les tableaux.

Ben non. À part dans certains cas où le multicolonnage passe mal, peut-être, mais on peut déjà faire pas mal de choses en css. Smiley cligne


Thibow a écrit :

Si vous voulez ajouter du css avec votre newsletter, il faudra obligatoirement passer par un code en ligne du style :

<font style="color:#FFF;">blabla</font>



Beurk. Et pourquoi ne pas utiliser un span?

En fait, le contenu de la newsletter doit être toujours accessible que les images soient absentes, que les css soient inactives, quitte à se retrouver avec une mise en page html (sémantiquement correcte) nue.

Les bonnes pratiques conseillent également d'envoyer les mails en multipart avec une version texte pour les clients mails ne comprenant pas le html.
Modifié par Patidou (19 Jan 2009 - 13:13)
En effet, après tout dépend le type de la newsletter et son contenu ...
Mais dans la plupart des cas, un tableaux sera véritablement le meilleur moyen de parvenir a une bonne intégrations (attention tout de même au collspan et rowspan qui ne passe pas a tout les coup sur les client de messagerie).

En tout cas, un post vraiment intéressant car il n'y a pas beaucoup de post sur le sujet !
Ce site est vraiment intéréssant pour connaître les compatibilités entre les différents clients mails : http://www.email-standards.org/

Par expérience, je peux confirmer que les tableaux sont conseillés dès lors où l'on modifie le positionnement naturel d'une balise ("multicolonnage" par exemple). Beaucoup de webmails ou de clients mails supportent très mal les CSS voire même l'XHTML. Je pense notamment à Outlook 2007, dont le moteur d'interprétation se rapproche d'HTML4.

Si je peux résumer en quelques lignes les pratiques à eviter :

- Ne pas utiliser de background-image (gmail n'aime pas de mémoire)
- float (pas interpreté par Outlook 2007 notamment)
- les appels à des feuilles de styles ou des déclarations en tête de fichier (je crois c'est le webmail de noos et/ou de free qui remplace <style... par <!style rendant les déclarations non interprétées)

Le plus simple reste quand même de faire une image entiere pour une newsletter (même si ca reste assez lourd) et là plus de problème d'interpretation Smiley murf
Alex N. a écrit :
Ce site est vraiment intéréssant pour connaître les compatibilités entre les différents clients mails : http://www.email-standards.org/


Moi j'aime bien les tutos de pompage.net... Smiley murf

Alex N. a écrit :
Le plus simple reste quand même de faire une image entiere pour une newsletter (même si ca reste assez lourd) et là plus de problème d'interpretation Smiley murf


Ahaha Smiley lol Avec un attribut alt de 100 lignes? Smiley lol
Alex N. a écrit :
Le plus simple reste quand même de faire une image entiere pour une newsletter (même si ca reste assez lourd) et là plus de problème d'interpretation Smiley murf

Oui, comme ça la majorité des destinataires ne verront absolument rien, car leur client mail bloque les images par défaut, et qu'en présence d'un email absolument vide il est probable qu'ils ne cherchent pas à activer les images pour cet email ou cet expéditeur.

Le moins simple mais le plus efficace est de bien designer ses newsletters, berdel de morde. Voilà.
(J'en glisse un mot ici: Deux exemples de newsletters efficaces.)
Modifié par Florent V. (20 Jan 2009 - 21:28)
Bonjour a tous,

J'y vais de mon astuce, il faut dire que du mailing je m'en suis bouffe avec tout le tas de contraintes (technique, design, ethique) qu'on peut trouver.

- Je decoupe mon design de facon intelligente : c'est-a-dire, decouper les images qui contiennent du texte de facon a pouvoir leur mettre un contenu alternatif.

- Je monte mon tableau de facon intelligente : c'est-a- dire qu'en accord avec mon decoupage, si je ne suis amenee qu'a avoir acces au contenu alternatif je respecte le sens de la lecture et je comprend le contenu de la newsletter.

- Je monte en HTML 4 et privilegie les balises et attributs HTML 4 donc (du font, du bgcolor etc...). Je n'utilise finalement l'attribut style dans les elements HTML que pour forcer la couleur sur une balise A et forcer la taille en pixel de la typo (parce que font size c'est pas l'optimal) tout en verifiant que la desactivation des css ne defonce pas trop (voire pas du tout) le design.

- J'encourage mon designer a utiliser des typos web pour le texte avec un fond uni (surtout si le mail est un gabarit et que la hauteur du contenu peut varier).

- Je me bat contre mon chef de projet qui veut rendre tout le mail cliquable pour gonfler les stats a l'insu de l'utilisateur alors qu'une zone de clic est visuellement bien identifiable.

- Je rappelle qu'il ne faut pas oublier de laisser la possibilite a l'utilisateur de se desinscrire (je recois encore trop de mail ou ce n'est pas le cas).

- Je prie que les mentalites changent et que les commanditaires cessent de confondre mail et grosse image cliquable, mais pour cela il faudrait que le contenu prime avant le design et ca mon bon monsieur, on y est pas encore.

- J'invite chacun a lire :
http://www.sitepoint.com/article/principles-beautiful-html-email/
http://www.sitepoint.com/article/designers-guide-html-email/
http://nettuts.com/misc/6-easy-ways-to-improve-your-html-emails/
et a trouver des idees d'ergonomie :
http://www.campaignmonitor.com/templates/

Bref, si vous etes dans une situation ou vous devez monter un mailing en un temps record en etant sur que ca passera partout, cette methode est infaillible.

Je ne dit pas que c'est la meilleure cependant.
ps : Je precise dans ce cas je ne suis qu'integrateur. Je dois faire avec ce qu'on me donne. Mais comme le dit Florent plus haut le mieux est encore de bien designer son mail en pensant en amont aux contraintes qui seront rencontrees en aval.
Je cite un des articles que je donne "An Email is Not a Web Page".

Enfin y'a pas de secret pour bien faire quelque chose, faut deja comprendre ce qu'on fait Smiley smile
Pages :