Stuart Homfray The Weblog

Broken Styles in HTML Email

Personally, I’m not a fan of HTML email (plain text seems so much cleaner and more efficient), but anyway, here’s a quick note for anyone having problems with their CSS-styled HTML email within Mozilla’s Thunderbird client.

Last month, the Lockergnome HTML newsletters were looking a little strange; capitalised words throughout and partially rendered styles - Big Chief Chris Pirillo was clearly a little peeved by Mozilla’s baby! After taking a quick look around, it turned out that the problem was down to a line break within a couple of the font values. Here’s an example of one of the CSS rules within the problematical email:

body { color: #000; margin: 10px; padding: 0; background: #fff;
font: 9pt "Lucida Sans Unicode", "Lucida Sans", "Trebuchet
MS", verdana, sans-serif;}

Note the line break between ‘Trebuchet‘ and ‘MS‘ - remove this and everything works as expected!

What’s happening here? Well, if you attempt to validate this rule, you get the slightly cryptic message ‘Invalid number : font Parse Error - “Trebuchet MS”, verdana, sans-serif‘. It’s not overly clear what that means, is it? Time to dig a little deeper.

You may not have realised this, but a line break within a style value is invalid (’smacked wrists’ for me there too for not reading ‘Rules for handling parsing errors‘ thoroughly enough, particularly the ‘Unexpected end of string’ section!) I must admit that I’ve not come across this before, though: perhaps it’s down to the fact that I tend to write my stylesheets by hand - I would never deliberately stick a line-break in there!

There was no problem with the newsletter layout in anything using the Trident rendering engine (IE6 and Outlook/Outlook Express), but as anyone that creates CSS knows, Trident IV and earlier can be rather forgiving when it comes to style rules. The Gecko rendering engine, however, conforms to the CSS 2.1 specification in it’s behaviour. The fact that the layout looked correct within Trident and wrong in Gecko usually suggests (around 99.5% of the time anyway) that the problem lies within the CSS rather than Thunderbird/Firefox.

I’ve also tested this in Safari 2.0.4 (WebCore layout engine) and Opera 9 (Presto engine) too. Anyone using Mail within OSX or the Opera email client M2 would have seen the same problems as those exhibited by Gecko.

After I sent a message about this to Chris (and I must admit that I did not, at that point, state that the problem was invalid CSS) he pointed out that he was having a bit of trouble preventing his mailer system from wrapping lines. He’s obviously won the battle now, though, as everything looks hunky-dory!

So what’s the lesson here? The same as always - if at first you don’t succeed, make sure that

1. the software’s not playing up, and
2. the damn CSS validates! :)