Sad fact: Not going to happen anytime soon. Definitely not for Outlook 2010.
They turned to Word for HTML editing/rendering in Outlook 2007 because there was no Internet Explorer team during development. IE7 was released in 2007, but Office 2007 was in development since at least 2003. No IE team means there was no one to send design change requests to. Office doesn't like being at the mercy of other teams, so they break dependencies whenever possible. The lack of an IE team was a perfect example of why this is a successful practice for them.
Word offers a significantly better editing experience and most email clients only render a small subset of standard HTML anyway. Gmail, for example, throws away all headers including CSS. It was a perfectly reasonable cost/benefit trade off for the Outlook team to switch to an editor and renderer they could directly change or influence. There wasn't a big loss of compatability, but there was some. Most HTML email in actual usage renders the same between Outlook 2003 and Outlook 2007 because they would have to be written to the lowest common denominator in order to render correctly in most other mail clients as well.
Outlook 2007 added DRM to emails which, besides being the most annoying thing ever, was a feature highly demanded by customers. This feature is based on Word's DRM.
So, putting on my Microsoft PM hat... let's do a cost benefit analysis of switching Outlook to use the IE8 rendering engine:
Benefits:
1) HTML email authors (who don't pay us anything, by the way) will have a slightly easier time now.
2) HTML email authors will have a significantly easier time in the distant future.
Costs:
1) Second release to break HTML mail compatability in a row.
2) Will need to re-implement DRM. This includes a full battery of security reviews.
3) Will need to re-implement all recent editing improvements.
4) Once again at the mercy of the IE8 team, who already have a huge backlog of work and probably don't care about our DCRs.
shrug Not going to happen in 2010. Probably won't happen in the next release either. When some version of IE supports 100% of all standards and is as fast as a hypothetical future Chrome, such that they have time to deal with the Outlook team, then maaaybe, just maybe they can tackle this... two releases of Office later.... If you're lucky.
Will need to re-implement all recent editing improvements
This is something that blows my mind. How can we have WYSIWYG editing functionality since the 70's, and when "the web" comes along, we decide to build everything on top of HTML/CSS, which is insanely hard to implement WYSIWYG on top of? Ditto for drag/drop and right click for God's sake.
What is the reason it is so difficult to implement WYSIWYG not top of HTML/CSS (i kind of feal it thinking at latex,but can't put a reason other than "organisation of the source")? on top of which kind of serialisable representation would it be easier, is there any..?
Yes, it does. Microsoft call it IRM (Information Rights Management) and you need to install/enable it on your domain and Office 2007 hooks into it.
You can then put limits on who can copy, print, fax the email, who can cut/paste from it, to whom you can forward it and force expiry of it.
It includes fun bits such as "The first time that you try to open an e-mail message that uses restricted permission, you must connect to a licensing server to verify your credentials and to download a use license".
This is basically the attitude of the kmail developers - html email is bad.
Who could possibly ever want to send a link or photo to someone in an email. Everyone should be forced to have green console text on a black background.
Images can be attached to an email without HTML and URLs that appear in text/plain emails are "linkified" by most readers.
The original MIME specification included an "enriched text" subtype which was essentially an HTML subset that was easy to implement safely and served most purposes for person-to-person communication.
MIME allows absolutely anything to be embedded in an email, but the standard explicitly discourages the use of HTML as the message body. The argument for standard compliant HTML support in all email clients is fairly weak considering it shouldn't be there at all.
How do I send email in 24 different colors with pictures of my puppy, then?
A more serious restatement of the joke: Other than HTML email, there is no functional way for the average computer user to send personal information with the following properties:
1. Rich text with embedded images (you know... HTML)
2. available at work without running into firewall or security restrictions (Websense)
3. Easy enough to compete with email.
4. Cheap enough to the end user to compete with email.
5. Secure enough to allay concerns about personal information making it out into the wild. (Never mind that email is easily interceptable: there is a perception versus reality problem here.)
A web application isn't going to do it. It's just too painful to attach more than two photos. A separate application isn't going to do it -- what corporate IT department is going to install it?
Livejournal comes close for tech-savvy people, but it's not in the average user's current skill level.
It's a fundamenally hard problem for social rather than technical reasons, and that is why people use HTML in email, and that is why vendors support it. Reducing it to a technical problem doesn't help.
Some protocols cannot do certain things. This is an unfortunate fact of life. If you find an ad-hoc workaround, don't be surprised if you have to jump through hoops to make it work and don't blame someone for breaking it when it was never supposed to work in the first place.
But the situation is more like me using a hammer to knock screws in and then screw makers changing the screws design so that it's harder to knock them in with a hammer because "they were never designed for that".
The problem isn't that some protocols can't do these things. The problem is that email is the only protocol that fills this need, so it's time to stop complaining about how people choose to use it.
They don't work for me either, but we're in a minority. The non-techies seem to love HTML email. My boss, even, receives all sorts of crappy offers and adverts and forwards them on to me to "check out the bargain!"
We have clients that pay thousands of pounds a month for HTML newsletter services (not to us, at the moment). I like to assume they wouldn't be doing this if they didn't work.
(Don't 'they' say that only one person has to click a spam mail for it to be worth sending - is this not more or less the same thing?)
Let's face it, email is on the way out anyway. Its future demographic consists entirely of nostalgic hackers, antiquated corporate IT regimes and orphaned spambots.
That twitter wall definitely is cool, but the pop-in moves the text and makes it hard to read. It would be better if the new tweet tiles slid in, animated. The speech bubbles should also stay fixed, but their tails should move along with the animation.
Are you kidding? Proper HTML rendering is the least of Outlook's problems.
I blame Outlook for the mess that E-mail became. Top-posting, citing entire E-mails, people being unable to distinguish cited text from new text, unbroken long line, unreadable and unformatted E-mails.
To be fair, the people who do that would do it with any email client. Remember, your typical corporate email user was never on Usenet, has never been on a mailing list, genuinely doesn't know the difference between "reply" and "reply all", etc. It just so happens that these people get given Outlook and they use it. Or not, even, loads of senior managers, even at tech companies, have their secretaries send email for them and would consider reading 10 messages a day themselves "too much".
No, no, no. I use outlook at work, gmail for general email and also thunderbird for one other email address. And I really didn't come across a problem that email being coded in html tables.
My thoughts exactly. I never had a problem with email being in html format, nor with being coded by using tables. CSS purists don't like tables, but other than that, this topic is a non-issue.
Surely Microsoft can fix this problem by adding more toolbars and icons to the GUI or by further degrading Outlook's ability to search large mailboxes. At that point no one will even remember Word HTML rendering was an issue in the first place.
Good news - Microsoft fixed that search problem over two years ago by handling it on the server in Exchange 2007, so you can search quickly from Outlook / Outlook Web Access / your ActiveSync mobile (Windows Mobile / iPhone).
Choice of Outlook's builtin search (Outlook 2007 with up to date service packs and patches is better than Outlook 2007 as new, and better than Outlook 2003).
Or, if you're pragmatic rather than MS locked, and want really fast search, Google Desktop Search.
Or, if you're quite particular and want really really fast search, you can with a bit of fiddling get Lookout to work in Outlook 2007.
But the benefit of using the Outlook builtin search is that it's the same UI all the time. If you're connected to the server it searches on the server, if not it doesn't.
NB: You can be out of the office and connected to the server if you use Outlook/HTTPS as your connection type.
Heh Outlook's functionality has never been my problem (though Xobni makes it better and Gmail handles conversations better). Instead, Outlook's performance is the big issue.
They turned to Word for HTML editing/rendering in Outlook 2007 because there was no Internet Explorer team during development. IE7 was released in 2007, but Office 2007 was in development since at least 2003. No IE team means there was no one to send design change requests to. Office doesn't like being at the mercy of other teams, so they break dependencies whenever possible. The lack of an IE team was a perfect example of why this is a successful practice for them.
Word offers a significantly better editing experience and most email clients only render a small subset of standard HTML anyway. Gmail, for example, throws away all headers including CSS. It was a perfectly reasonable cost/benefit trade off for the Outlook team to switch to an editor and renderer they could directly change or influence. There wasn't a big loss of compatability, but there was some. Most HTML email in actual usage renders the same between Outlook 2003 and Outlook 2007 because they would have to be written to the lowest common denominator in order to render correctly in most other mail clients as well.
Outlook 2007 added DRM to emails which, besides being the most annoying thing ever, was a feature highly demanded by customers. This feature is based on Word's DRM.
So, putting on my Microsoft PM hat... let's do a cost benefit analysis of switching Outlook to use the IE8 rendering engine:
Benefits:
1) HTML email authors (who don't pay us anything, by the way) will have a slightly easier time now.
2) HTML email authors will have a significantly easier time in the distant future.
Costs:
1) Second release to break HTML mail compatability in a row.
2) Will need to re-implement DRM. This includes a full battery of security reviews.
3) Will need to re-implement all recent editing improvements.
4) Once again at the mercy of the IE8 team, who already have a huge backlog of work and probably don't care about our DCRs.
shrug Not going to happen in 2010. Probably won't happen in the next release either. When some version of IE supports 100% of all standards and is as fast as a hypothetical future Chrome, such that they have time to deal with the Outlook team, then maaaybe, just maybe they can tackle this... two releases of Office later.... If you're lucky.