New Outlook Won't Use IE To Render HTML
loconet writes to tell us about a little surprise coming in Outlook 2007: it will render HTML email using the MS Word engine, dropping the use of IE for this purpose. This represents a body-check to the movement towards Web standards. Whatever you think about HTML email, lots of it gets generated, and those generating it won't be able to use CSS any more, and may stop pushing for more widespread standards support. The announcement was made on MSDN. From the Campaign Monitor post: "Imagine for a second that the new version of IE7 killed off the majority of CSS support and only allowed table based layouts. The web design world would be up in arms! Well, that's exactly what the new version of Outlook does to email designers."
The place I work for started releasing HTML emails highlighting deals for products, new features, and what not a few months ago, and the response has been nothing but positive. People like the pretty design and they reacted well to it. Not everyone is a minimalist who just wants just plain text, a lot of people want a whole dolled-up presentation.
Slashdot is proof that Sturgeon's Law applies to mankind.
I know this is slashdot, and nobody really like Microsoft or read the story, but the summery is wrong.
. aspx is a list of supported css and html in Outlook.
Here http://msdn2.microsoft.com/en-us/library/aa338201
The things missing are tags such as form and object, and some javascript support, but nobody is going to blame microsoft for not supporting onClick in emails. And yes tables are supported.
I attach them to e-mails.
I work for communication agencies. Here is how it works usually:
They tell me that they need to send an e-mailing for X (products, event, whatever). here is the content and the lay-out (a mockup). It should be sent before XX/XX/20XX at X O'clock (if it is a local business, at 9 in the morning because people are reading their emails).
So we make the lay-out, we place the content. We test it ith a series of webmails, Thunderbird, Lotus Notes (yes we still do...), Apple Mail, Outlook and so on. We send a test email to the communication agency.
They tell me to increasse the font size, align paragraph X with the picture...That's all.
But attached images or links is purely technical business. If it is linked it will appear as broken link for the communication agency (images are usually blocked by software because fake pictures can help spammers to know that an email account is active or not): They don't understand it.
Some of them who understands a bit of technique force us to send a pure HTML email (no multipart plain text) because some software are configured to render the plain text first.
All they want me to do is an email that works and an email that respects laws (link to unsubscription, etc.) and of course some stats such as the number of clicks on a link inside the HTML email (can be easily calcultated with a redirect script).
I have rarely use CSS anyway. Such a technique is already incompatible with a variety of applications (broken links to the CSS file or styles overriden by webmails for example).
For those who say that plain text email works better than HTML email: it depends of your target. I will certainly advice plain text for a geek mailing list but for lambda users they prefer shiny lay-out (stats prooves it).
For those who said that they can't read the email with Pine or with their telnet account. Nobody care about martians.
But why should the job title "e-mail designer" even exist?
Because it sounds better than "spammer".
Proud member of the Weirdo-American community.
The kicker comes when you modify one of the instances. Word takes that to mean that you're modifying not just that instance, but the definition of the Style. So every other instance changes too.
The solution is to explicitly create a Style for each layout you want to use, and invoke it explicitly. Microsoft REALLY wants you to use Styles. After all, it's more efficient to format with Styles. And that makes it a best practice. And everyone knows Microsoft is all about best practices.