Nieuwsbrief opmaak. Probleem met html.

[Anoniem: 149953]

Hallo allen,

Ik heb wat problemen met de html van een nieuwsbrief. Jammer genoeg zijn email clients niet erg w3c complient en is er dus een hoop ouderwetse html en een hoop tabbellen nodig om de nieuwsbrief in de diverse email clients correct te laten functioneren.

Ik loop nu tegen een probleem aan dat ik niet opgelost krijg.

Zoals je hier kan zien:
http://home.tiscali.nl/gggev/template.html
Ik krijg de tabelcellen met de afbeeldingen van de rodige afgeronde hoeken rondom de gehele nieuwsbrief en de grijze afgeronde hoeken om de inhoud van de nieuwsbrief niet op de juiste hoogte en breedte die ze moeten zijn (dezelfde hoogte en breedte als de afbeeldingen van de afgeronde hoeken).

Kan iemand mij hier helpen?

Groetend,

Martin

[NMe]

Het ziet ernaar uit dat je de margins paddings niet goed hebt staan. Zal voor e-mails ongetwijfeld met cellspacing en cellpadding gefixt moeten worden.

[Janoz]

Ze worden hoger omdat er tekst in staat (ja, een non breaking space is natuurlijk ook tekst). Anders past de tekst er immers niet in.

[RaZ]

Begin eens met een doctype, nu moeten de render-engine maar wat gaan gokken.

Daarnaast is het niet zo boeiend hoe die pagina er in je browser uitziet, maar juist in de email client.

Maar deze opmaak gebruikt dus plaatjes van een server, en niet in de mail zelf begrijp ik, waarbij de meeste email-clients dus nooit je images (rounded corners) laat zien.

Ik denk dat je het niet zo fancy moet maken (richting de huidige normen/w3c), maar gewoon wat jaren terug moet in de tijd. Je geeft zelf al aan dat je juist met tabellen moet werken vanwege de slechte rendering van email-clients.

[Bosmonster]

Doctype is redelijk zinloos bij een nieuwsbrief. Ontwerp in quirksmode met antieke html. Hou het simpel, geen achtergrond-afbeeldingen, alleen spaarzaam inline css.

Plaatjes op de server is redelijk standaard in nieuwsbrieven.

De ronde hoekjes gewoon ditchen.

[ Voor 80% gewijzigd door Bosmonster op 07-09-2010 16:54 ]

[Anoniem: 149953]

Ik heb de non breaking spaces weggehaald en dat scheelt al enorm. De rodige hoeken bovenaan lijnen perfect uit de grijze hoeken lijnen ook heel aardig uit (de grijze hoeken aan de rechterkant moeten nog iets getweaked worden maar dat komt wel).

Er blijft echter een probleem over.

De cellen met de rode hoeken helemaal onderaan vertikken het om mee te werken:-(.

De afgeronde hoeken moeten wel in het ontwerp verwerkt worden. Daar valt helaas niet aan te ontkomen:-(. Dus ik kan ze niet 'ditchen'

[RaZ]

Maar je bent je er wel van bewust dat 95% van de email-client geen plaatjes van servers afhalen? Als je ze dus niet mee stuurt in de mail, je geen enkel plaatjes ziet, en dus ook die ronded corners niet.

Dit wordt standaard geblokkeerd, omdat spammers die het mail-adres in de links naar de plaatjes hebben staan, zo nooit kunnen verifieren of het adres bestaat of niet.

[Anoniem: 149953]

Het is reeds opgelost!

Ik hoefde alleen nog de twee br tags onderaan te verwijderen en ook de ronde hoeken onderaan en de cellen werkten keurig mee .

Ik wil jullie alleemaal hartelijk danken voor het meedenken en het aandragen van oplossingen!

Dat waardeer ik ten zeerste!

Groetend,

Martin

[ Voor 80% gewijzigd door Anoniem: 149953 op 07-09-2010 17:26 ]

[MueR]

Anoniem: 149953 schreef op dinsdag 07 september 2010 @ 17:19:
Ik heb voortgeborduurd op een reeds bestaande template die werkte op praktisch alle mail clients en waarin reeds plaatjes zaten verwerkt (waarom het wiel opnieuw uitvinden). Dus daar maak ik me niet zo'n zorgen over.

Je weet dat de template er dan ongeveer uit gaat zien zoals hieronder in de meeste clients, tot de gebruiker toestemming geeft om die images te downloaden?

Ik heb voortgeborduurd op een reeds bestaande template
[...]
Ik maak me meer 'zorgen' over die lastige cellen onderaan met die rode hoeken .

Vraag het dan eens aan de maker van de template? We zijn hier geen supportdesk voor al je kant en klare templates.

[Anoniem: 149953]

Nee het was ook geen kant en klare template het was een basis waarop ik voortgeborduurd heb. De basis bevatte reeds wat afbeeldingen om een beeld te geven. Dat heb ik allemaal verwijdered maar de basis heb ik gehouden. Scheelde weer een zootje typen zeg maar.

[Anoniem: 98590]

Ik zou om te beginnen de twee overbodige <br>-elementen uit de cel helemaal rechtsonder weghalen.

Hoekjes bovenaan het witte vak zijn iets lastiger, ik zie zo niet in hoe je die netjes er in kunt verwerken zonder de hele grijze border te vervangen door een background image (met alle nadelen van dien in e-mail clients)...

[Anoniem: 149953]

Ik zit te denken om de vier cellen een eigen inline style border te geven en de inline style border die nu om de gehele tabel zit te verwijderen. Dat lijkt mij de enige oplossing die enigzins logisch is. Want met een background image kom je inderdaad in de problemen.

De br tags had ik reeds verwijderd .

[Croga]

Anoniem: 149953 schreef op dinsdag 07 september 2010 @ 16:33:
Jammer genoeg zijn email clients niet erg w3c complient

Dat heeft er vooral mee te maken dat Email nooit bedoelt is om HTML te gebruiken.

Je zult ook merken dat EMail met veel HTML een hogere "SPAM" rank krijgt, zeker als er ook externe plaatjes bij gebruikt worden.

Daarnaast moet je er rekening mee houden dat EMail clients heel verschillend met HTML om gaan. Zeker nu dat mobiele EMail meer gemeengoed is heb je dus rekening te houden met hele stapels verschillende EMail clients. Veel van die mobiele clients hebben helemaal geen HTML ondersteuning.

Alles bij elkaar raad ik iedereen sterk af HTML te gebruiken in EMail. In veel gevallen zal de EMail helemaal niet leesbaar zijn, in nog een aantal gevallen zal de EMail automatisch in de SPAM bak terecht komen. Al met al kost de opmaak je vele malen meer dan dat ie oplevert.

[Bosmonster]

Een nieuwsbrief is redelijk zinloos zonder HTML, dat haalt je hele communicatie onderuit.

Daarnaast kun je gewoon een multipart message versturen met een extra tekst-variant.

Basic HTML kunnen bijna alle clients wel aan vandaag de dag.

[ Voor 9% gewijzigd door Bosmonster op 07-09-2010 18:27 ]

[geert1]

De discussie of HTML thuishoort in e-mails is redelijk zinloos. Alle grote bedrijven die nieuwsbrieven verzenden met iets van een huisstijl of ontwerp, zijn er simpelweg op aangewezen. Dus beweren dat het niet mag of niet hoort heeft in de praktijk geen zin. Daarnaast kunnen alle e-mailclients met een gebruik boven de 1% ook omgaan met HTML en CSS. De mate waarin echter, daar begint het interessant (of irritant) te worden.

Afbeeldingen van een server zijn ook in principe geen probleem (zoals iemand hierboven beweert), maar ze kunnen wel geblockt worden totdat een lezer de afbeeldingen bewust goedkeurt. Maar dat is ook weer een bekend proces voor ontvangers, dus niet het einde van de wereld.

Het probleem van de topicstarter is in principe al opgelost, maar voor wie het interessant vindt, hieronder enkele tips uit mijn persoonlijke ervaring:

- De ondergrens voor HTML/CSS ondersteuning op dit moment wordt gevormd door Outlook 2007. Deze client heeft een flinke stap terug genomen in HTML ondersteuning. En omdat deze client nogal wijdverspreid is, is alles wat deze client niet kan weergeven ook gelijk uit den boze in e-mail html. Hieronder vallen css-eigenschappen als float en position, wat zo ongeveer de kernwaarden zijn van css-based lay-outs. Conclusie: tabellen gebruiken. En altijd testen in ten minste Outlook 2007 (liever meerdere clients, ook web-based).

- Simpele CSS wordt aardig ondersteund, maar zorg dat je deze altijd inline zet. Dus op het element zelf met het style-attribuut. Dit heeft tot gevolg dat als je elke titel in de mail groen wilt kleuren, je dat op elke titel opnieuw zult moeten aangeven. Dit geeft de grootste compatibility met uiteenlopende clients.

- Zorg dat je zoveel mogelijk harde breedtes en hoogtes zet op cellen en afbeeldingen, mits deze bekend zijn.

- CSS padding kan worden gebruikt in cellen, maar zorg dat de padding top/bottom overal gelijk is in de hele rij, en dat de padding left/right overal gelijk is in de hele kolom. Hetzelfde geldt voor borders: als je een border-top toepast op één cel in een rij, doe het dan op alle cellen in die rij. Dit wederom met name voor Outlook en andere brakke renderaars.

- Elke table-tag moet opnieuw de font-family en font-size als css-eigenschappen krijgen, omdat deze niet goed geërfd worden. Ook als je een table in een table nest (wat nogal eens nodig kan zijn), zullen de font-eigenschappen opnieuw moeten worden opgegeven. Verder is het meestal slim om de cellpadding, cellspacing en border op nul te zetten en eventuele padding met CSS te regelen omdat je dat per cel en zelfs per zijde in kunt stellen.

- Geef elke cel die tekst bevat expliciet een align="left". Bepaalde clients renderen de tekst anders gecentreerd.

- Achtergrond-afbeeldingen worden niet ondersteund door Outlook 2007. Achtergrond-kleuren wel, en verder ben je aangewezen op afbeeldingen (img-tags).

- CSS margin wordt mondjesmaat ondersteund op blok-elementen als div en h1, maar niet op een img bijvoorbeeld (Outlook 2007 wederom). Div-jes gebruik je dus in principe toch niet voor de lay-out, maar het is wel bruikbaar voor bijvoorbeeld een titel die een eigen stijl moet krijgen binnen een cel.

- Om een blokelement (of de hele nieuwsbrief) te centreren gebruik ik align="center" op een td, met daarin het te centreren element die dan een vaste breedte krijgt.

- Cellen altijd een inhoud geven is zeer aan te raden. Ik gebruik altijd een nbsp, tenzij de cel kleiner is dan pakweg 10x20px. Dan gebruik ik een lege div met width=1px en height=1px. Werkt heel aardig in heel veel clients. Vroeger werd vaak een transparante gif-afbeelding gebruikt van 1x1 pixel, maar een leeg divje werkt dus net zo goed, maar zonder afbeelding.

[ Voor 5% gewijzigd door geert1 op 07-09-2010 19:50 ]

[Cartman!]

Croga schreef op dinsdag 07 september 2010 @ 17:50:
[...]
blaatverhaal over het niet gebruiken van html in email

Jij werkt zeker nog in HTML1.0 ook? Ga mee met je tijd, zal je goed doen. Hopelijk is er niemand die zijn 'advies' aanneemt, het is simpelweg niet waar. Als jij netjes een html opmaak kan maken voor je nieuwsbrief is er niks aan t handje. Wil je client plaintext? Dan kan ie dat krijgen mits je het meestuurt (zie Bosmonster).

[Anoniem: 149953]

Bedankt Geert voor de vele informatie!

[ Voor 74% gewijzigd door Anoniem: 149953 op 07-09-2010 22:27 ]