I cannot believe that Microsoft Outlook, in 2019, is still using the broken word-based HTML rendering which is an insult to the whole industry and a pain for anybody in email business.
Is there a strategy behind this? Is Outlook on maintenance mode with no developers? Or is it on their best interest to keep it broken?
Since office 2007 they use word to render HTML mail. Probably mostly because of security reasons because at the time their other option was IE which lead to many previous security flaws.
Word isn't much safer but at least it is under the Office team's control plus it's less widely deployed than IE was at the time. It also has way fewer features with regards to HTML rendering which helps reducing the attack surface.
On the other hand, as it's neither browser nor HTML editor, its HTML rendering capabilities are never improved because it's no priority.
And thus HTML mail is stuck at tables, font tags and spacer gifs for the rest of eternity. Thank you Microsoft.
(OTOH, whatever helps discourage HTML mails and encourage plain text is a good thing in my book. And now, get off my lawn)
I dunno about Microsoft's intentions, but it's in our (worldwide internet users) best interest for Outlook to keep the 'broken' renderer.
HTML email has some use-cases as long as the HTML used is very limited, and that's exactly what Outlook provides. There's however no justification to turn email into a full on web page like Google wants. The longer Outlook's renderer is 'broken', the less likely we are to get abominations like Google's AMP email.
Ultimately, email really is a document and should remain that way. This is compatible with HTML, but completely incompatible with Javascript.
Oh come on, don't you wish you could send a game using WebGL via E-Mail? Think about the possibilities!
(To some degree I'm unsure if I'm really joking - I can image practical use, but I love plain text mail, which I can easily search, filter and render as I need it)
Ah, wonderful. We'll have animated, autoplaying 419 scams. We'll need Turing-complete spam filters, which will be exploited themselves. Just what we needed.
Edit: Wait a minute. Wouldn't these WebGL games need microtransaction ability? That's a must for any game company. Obviously we must be allowed to use the payment API in emails! So now the scams would be able to bill the user directly.
As long as they can mine Bitcoin there's no need for micro transactions. Just make sure that there is no save button and warn the user that closing the mail will lose their game state.
A more serious use case might be the architect sending models of the new building or the doctor sending MRIs. While those cases have practical issues like the recepient not being able to respond to it easily (move that wall!) and privacy, they also have interesting benefits like no need to login to some cloud and retention period controlled by the recepient. Sending as attachment of course works, but needs container formats to collect assets together and sandboxing in browsers for local files. As well as this being a media break, where I have to switch to a different tool to look at it then where the context is.
Your suggestion is pure genius. We'll just call it a roguelike and that would explain the 'no save button'. I'll be sure to recommend you at the next 'dark pattern' meeting! /j
As for the latter, if we're going in that direction, we might as well go all the way and implement some COM-like thingy for the web, so users can attach multiple whatevers and work on them in the email. This seems more efficient than turning each email to a unique embedded app which can embed only one type + maybe attachments.
Despite all this being possible in Outlook-land, everyone I'm familiar with prefers opening the attachment and working in a separate window, but I guess some people would rather work inline?
I meant that in Windows there is an alternative to attachments to an extent. COM allows an application to embed in another application. i.e. I can paste some Excel into Outlook and it will keep the table formatting and I can manipulate it in Outlook as if it were Excel. It's not the best implementation though (pretty bad on the other side), and there probably is a much nicer way to do it.
You could be right, with a better implementation there would be more that choose to work that way. I still think the risk outweighs the possible limited benefit though.
> Or is it on their best interest to keep it broken?
I get the impression that most mail is currently sent using Outlook and read using Gmail, so there is kind of a detente where everything is just frozen.
So Outlook users send more email than Gmail users?
How does this work? I mean it implies in some way a difference in the amount of reading Gmail users do and a difference in the amount of sending Outlook users do. That sounds weird.
Do businesses really use outlook though, to send to their customers? The place I'm at right now automates sending out lots of customer emails, but they don't use outlook to do it they use some automated tool, however the HTML provided is outlook compliant HTML because you have to have something that can also be read in Outlook.
> Do businesses really use outlook though, to send to their customers?
Yes. This might be hard to grasp from an SV web dev perspective, but not all industries are just about shoving ads at people. The company I work for does not do mass mailing. We use email to actually communicate with actual people who wish to exchange actual money for our product. This often involves months of back and forth discussion, because our product is highly customized.
the company I'm referring to is one of the biggest banks in northern Europe and they do automated mails to people who want those mails because they've paid a lot of money for the service.
The company I worked at before that also did automated mailing was only doing it because lots lawyers and numerous members of some other professions that required alerts regarding the laws affecting their jobs had paid lots of money to receive that email (well lots of money for a service that included alerting by email among many other things), and that email was setup to handle Outlook requirements because most people who received it were doing so on their outlook mails, ditto the current banking solution - for us webmail must remain a secondary consideration.
Anyway, given your condescending response I must say you made a nice choice for a user name.
But I'd guess that since individual emails to customers are more common with B2B than B2C (due to higher transaction volumes), those emails are often Outlook to Outlook, not Outlook to Gmail.
Outlook as referred to here is the rich client program, not outlook.com.
You can send/receive gmail using Outlook - in fact it's much nicer to read compared to Google's confusing Web UI, with the ... and things along those lines.
I see no scenario where this idea could succeed. Most businesses put their mails through sandboxes and whatnot. and a mail that looked like a chicken once, will look like a pile of bones at the time it reaches the receiver.
Well, we had mails that contained VBScript. Outlook users can actually execute these. I think Microsoft changed policies to default disallow for a lot of VB components about a year ago.
It's 2019, and Office for Windows still uses Internet Explorer to render add-ins built with OfficeJS.
This is slated to be switched to Edge (regular edge, not the Chromium-based build) with Windows 1903 and a newer Office version, but damnit if my life isn't going to be hell debugging IE for a couple months.
After working on crafting such emails for a while for my previous employer, I was seriously considering starting a SaaS to do exactly what you just described. (I didn't start.) Best of luck!
> Or is it on their best interest to keep it broken?
It seems similar to a strategy they use more often, famously known as embrace, extend, and extinguish [1]:
1. Use some standard/specification
2. Accumulate lots of users with questionable strategies
3. Extend/break/deviate from the specification
4. Devs update software to cope with the undocumented Microsoft(c) behavior
5. There is no point in following the specification or standard anymore, since it won't work in practice anyway. Microsoft effectively dictates what devs do.
Your comment made me check whether it was MS that started HTML e-mails. Well, this doesn't seem to be the case, unless I'm missing something.
According to wiki, only Outlook 98 added support for HTML emails[0]. It's not difficult to find Outlook 97 users asking how to support HTML[1], so the wiki changelog doesn't seem to be wrong. Outlook 98 was released in June 1998. Outlook Express doesn't change this picture - version 4 didn't have HTML email support[2], and version 5 was only released in 1999. MS support date appears to be June 1998.
Meanwhile, Eudora 4.0 release announcement[3] at December 97 already mentions HTML support. So at the very least, Eudora had it first.
Rich HTML Messages - Users have the ability to view and compose rich HTML messages, using graphics and stylized text. Emails containing HTML look as if they would on a web browser and include graphics such as embedded images, tables and java applets.
When I clicked the link I thought it would be about something that confused me for a while: What do people mean when they write a capital J in their emails? I eventually figured out that it's because Outlook automatically converts a smiley emoticon into a WingDings (an old Microsoft icon font from before that term became popularized on the web) version, which happens to have J as the character for a smiling face. View that on a machine that doesn't have the WingDings font installed, and you just get a capital J. Raymond Chen blogged about it too: https://devblogs.microsoft.com/oldnewthing/20060523-10/?p=31...
Yup, Microsoft jumped at just the wrong moment on this stuff.
Today you just go "Eh, text is Unicode" and any weird corner cases go in the Private Use Area bucket never to be seen again.
And in the 1980s you'd go "Eh, text is ASCII" and just tell office workers that too bad they can't have an emoticon in their email, try writing :) instead.
But just at that moment where Windows exploded and everybody was getting a PC with a graphical user interface there was that awkward moment where it seemed reasonable to act as though text was arbitrary indexes into a font and doesn't actually _mean_ anything except that a lot of the fonts map to ASCII. So now you can write [HN removes actually Emoji] but it doesn't mean [HN removed the same emoji here] it just looks that way on PCs with the exact same font.
And that mistake infected Microsoft Office and all of Windows. I wrote a presentation on a work PC in about 1995 and then my boss printed it from her work Mac, and on every single sheet of the presentation the trademark symbol was replaced by some other symbol Macs had because of this useless ambiguity.
There are so many things Microsoft was ahead of the times. For example, they had what are now 'Electron apps' in the 1990's (hta files). And how I wheep when I look back at the power of COM, how I complained about it back when I didn't understand it, and what could have if we'd had proper object technology today.
> power of COM [...], and what could have if we'd had proper object technology today.
Editors which can always crash, because they are as stable as the least stable plugin? Formulas you can no longer edit because you do not have that specific formula editor installed? Completely closed and proprietary binary storage formats? Security as weak as the weakest app installed on your machine?
Granted, in the 1990's, COM was probably a pretty good thing -- it was very fast and efficient, at the expense of stability. Today, I'd prefer different tradeoff -- stable, secure and open; and if I have to wait 5 seconds for my auto-rendered markdown to get updated, it's OK, I can do so.
Windows also had some chat application, hidden within the Windows folder, that allowed you to draw comic book style panels and converse using those over a network. I have never actually seen it used live, but it seemed like an interesting concept.
Under the hood Microsoft Comic Chat was a relatively generic IRC client. There's an interesting community of folks still randomly using it and you can find questionably legal, definitely unsupported downloads in places.
Unicode has a couple of inter-related symbols blocks that preserve (almost) everything in Wingdings and Webdings, as it should. I'm surprised there aren't more "converter tools" between the original font encodings and Unicode preserving random usages of those *dings fonts. Exchange could have done that for particular Outlook clients. Word could prompt an option to optionally convert scattered usages in old DOCs.
(Office has at least moved to full Unicode rather than random Wingdings/Webdings embeddings in the last few versions, but given the long tail of the Office install base it will probably still be something like a half-decade to a decade before we see the last of the random dings.)
I'd be down with them either vanishing, or at the very least being compliant with a standard html5 spec. The in between state they're in now is the worst of both worlds.
A proper browser can display all HTML documents crated like, ever, if you can live with some imperfections that are there to deal with improper browsers in the first place.
I mean, I get your point, and it makes sense, and for a similar reason we didn't get WebSQL. But I think HTML is special in this regard. Everyone just accepted the complexity of dealing with all sorts of documents.
I would be happy if there was a subset of HTML for email. Look at the HTML Gmail produces, which is essentially just <div> or <p> in the default mode and uses <span> for changes of formating and <blockquote> for replies. This would work for propably 90 to 99% of all hand written emails in Outlook or any other email client.
> Outlook does support @font-face declarations (but doesn’t load distant fonts). Because Outlook can’t display that font, it falls back to its expected mso-generic-font-family value. And because it’s not defined, it falls back to its auto value, matching the roman font family, thus falling back to Times New Roman.
It also seems that mso-font-alt can be used in a similar way:
Maybe I’m dense and I couldn’t draw this conclusion — were those properties always available but we’re never documented? If that’s true it seems crazy to me that Microsoft couldn’t just say, “Hey I know everyone is mad about font-face not being respected. Here’s this property you can set and all is well.”
If you had passed a supported font to the font-family tag it would have rendered it (it will not download a webfont). Since people really don't like seeing square boxes instead of characters windows tries very hard to find a font that will draw the character. Based on historic precedent Times New Roman is normally chosen.
You'll note the fallback-families he lists are exactly those supported by the GDI LOGFONT structure which dates to windows 3.0. This is old creaky stuff we're dealing with.
I concur it's crazy. Same thing happened with Internet Explorer. Back then, you could not have 5, 5.5, 6 together on one Win98. When installing later versions, they would replace earlier versions. But as a hobbyist I needed all to test my Web sites. The recommended work-around was VMWare. VMWare was not installable on Win98, so I tried Linux as host OS. That was the pivotal point that got me into my serious programming career.
Years later a hidden API was found out that made it possible to install the browsers in parallel. http://web.archive.org/web/2007/http://labs.insert-title.com... If Microsoft had documented that for the public, they would have saved Web developers thousands of man-years of work.
Basically... isn't this a way to bypass the default external resource loading block for mail clients other than Outlook, meaning that this could be (ab)used for stealth "read receipts"?
It's a feature. Outlook helpfully removes "extra" line breaks from plain text email, and there is no way for the sender to prevent this. One can only assume the developers never communicate source code snippets using their own software.
Dear Microsoft: line breaks in my preformatted text are not "extra". I intend every single one. You may believe you know better than me, but you do not. Stop trying to nanny, you are very bad at it.
Have you tried using <CR><LF>? Windows notepad was never able to display linefeeds with only <LF> (or only <CR>?) and needed the <CR><LF>. Maybe this would solve the problem.
Window's line separator is actually two charaters, CR LF ( 0x0d 0x0a).
This is a fundamental difference between Windows and other operating systems. There's unix tools available to convert between the two formats (dos2unix & unix2dos).
I could be missing the plot here, but I always got the impression that Outlook limits (sets) the fonts and colours in order to make the emails look like they "were sent by MS/Outlook". But again, this may be my idiosyncratic MS experience.
I wonder, does Outlook 2019 have the "system" font glitch from Win 3.xx? I think I'll be sending out all my HTML emails in either System or Courier from now on; just to pull peoples' legs.
>Dormant, that is, unless someone asked for it with CSS. Which we, inadvertently, did.
It boggles my mind that not once did someone load up the "Medium 2.0" redesign on a Windows computer before launching it. Or even render it out from browsershots. Is cross platform browser behavior consistent enough that people don't do this anymore? And IE/Edge testing was just not on the list?
For reference if anyone wants to use the OS's font like this, "-apple-system" now has an unprefixed implementation as "system-ui" avoid the Windows font collision. Chrome/Safari support it, Edge will once they're running the Chrome engine, but Firefox doesn't yet.
Is there a strategy behind this? Is Outlook on maintenance mode with no developers? Or is it on their best interest to keep it broken?