The situation is wild. In older Outlook versions they've used IE to render the received mails but used a custom engine when you were writing/editing an email. You could even use Word as an editor so you could generate the HTML using Word as your WYSIWYG IDE. I can understand why that needed some consolidation into one editor and one engine but re-using Word so they wouldn't have to create a new editor wasn't the best decision for the ecosystem.
WYSIWYG editors and rendering engines aren't things I know about so I wonder if there have been difficult engineering issues at that time or if they just went at it from a business standpoint of "people see mail like letters so they are documents for which we have word so let's use that".
//Edit: Looks like they were mainly interested in providing a great WYSIWYG experience using tools users are already familiar with: https://web.archive.org/web/20110311083708/http:/blogs.offic... great quote: "There is no widely-recognized consensus in the industry about what subset of HTML is appropriate for use in e-mail for interoperability. The “Email Standards Project” does not represent a sanctioned standard or an industry consensus in this area. Should such a consensus arise, we will of course work with other e-mail vendors to provide rich support in our products." - I guess their argument could be that there still is no "HTML standard for email" so they don't have to support anything they don't want to?
WYSIWYG editors and rendering engines aren't things I know about so I wonder if there have been difficult engineering issues at that time or if they just went at it from a business standpoint of "people see mail like letters so they are documents for which we have word so let's use that".
//Edit: Looks like they were mainly interested in providing a great WYSIWYG experience using tools users are already familiar with: https://web.archive.org/web/20110311083708/http:/blogs.offic... great quote: "There is no widely-recognized consensus in the industry about what subset of HTML is appropriate for use in e-mail for interoperability. The “Email Standards Project” does not represent a sanctioned standard or an industry consensus in this area. Should such a consensus arise, we will of course work with other e-mail vendors to provide rich support in our products." - I guess their argument could be that there still is no "HTML standard for email" so they don't have to support anything they don't want to?