But fear not! Outlook still uses the HTML parsing engine from MS Word (!) to display your HTML emails, and it's not going anywhere.
https://www.windowscentral.com/project-monarch-outlook-web-u...
IM is one of the last places on the internet not filled with automated crap, advertisers and spam. And to be fair, some of that automated crap I actually want and browse through at a later time but IM explicitly separates real time messages and newsletters.
Email clients are a bit of an oligopoly, so execution would depend on which player(s) are involved. Most of these initiatives would need an "everyone but Outlook" coalition to succeed.
A few thoughts on implementation:
- Multipart MIME is still a big part of HTML mail, so it would make sense to piggypack on that support. Instead of adding a new MIME attachment for Markdown, it would make sense to extend the existing support for text/plain renditions and find some way to signal that it's Markdown. (e.g. text/plain; charset=UTF-8; variant=MarkdownMail)
- For mail clients that aren't Markdown-aware, it would be important to produce an HTML-rendered variant with a reasonable style sheet.
- A Markdown-first mail client would either need to limit formatting to Markdown or soft-block access to non-Markdown formatting. ("Custom text colors will not be visible on some devices and may be lost when replying. Continue?")
- When viewing a Markdown-enabled message, a Markdown-first mail client would render the text/plain variant in its preferred style sheet, not the HTML-rendered variant.
- When replying to a Markdown-enabled message, a Markdown-first mail client would use the text/plain variant as the source of truth for quoted replies, not the HTML-rendered variant.
A few tricky areas:
- Mail clients would need to agree on a Markdown dialect, especially for extensions like tables.
- Markdown isn't very incompatible with quoting. There would need to be a solution for inline quoting.
- For everyone's sanity, it would seem important to agree on a delimiter to separate prior messages and their headers.
- To not be worse than HTML mail, we'd really need a way to signal that a paragraph is part of a mail signature so that it can be rendered in a subtle way. As much as we might wish that mail signatures would just go away, they will continue to be used, and rendering them as standard paragraph text just makes them more distracting.
Theoretically email client vendor can host working group like WHATWG to define standard by picking subset from web HTML/CSS. I don't know why it's not happened.
* iframe content inside message is editable after message sent.
* Java Applet/ActiveX is almost dead, but still available. Should it be allowed on email? (for web mail on IE11/Trident)
* Sanitizing JavaScript from HTML by blacklisting isn't simple operation. Possibly attack vector. (for web mail)
You can already use url() to load background images - seems like this is a solved vector.
> * iframe content inside message is editable after message sent.
Does this really increase the attack surface area, since you can't execute javascript from the iframe?
* Java Applet/ActiveX is almost dead, but still available. Should it be allowed on email? (for web mail on IE11/Trident)
No, because that's not in the HTML/CSS spec and modern browsers don't support it.
* Sanitizing JavaScript from HTML by blacklisting isn't simple operation. Possibly attack vector. (for web mail)
Seems like a solved problem considering there's currently no way to execute arbitrary javascript in webmail.
Background image with url() is very easy to be whitelisted because it's very similar to <img> tag.
> Does this really increase the attack surface area, since you can't execute javascript from the iframe?
Sorry, this concern isn't about security for browsers, but for text editable email without indication. Maybe you can argue that it's not a problem because external image is already replaceable, but IMO it's more problematic.
> No, because that's not in the HTML/CSS spec and modern browsers don't support it.
Blacklist approach means that any tags just work unless explicitly specified on blacklist. "Not in spec" won't help.
> Seems like a solved problem considering there's currently no way to execute arbitrary javascript in webmail.
That's thanks to whitelist approach.
EPUB3 supports JS.
That's kinda funny given how my Calendar.app event notes are just full of unparsed HTML tags
Though I don't know which is worse, putting HTML in calendar invite descriptions, or refusing to render basic tags.
For a while, people would be sending both text/html and text/html-for-real, but eventually we’d maybe be able to switch to only sending text/html-for-real (while also continuing to send text/plain for fallback.)
text/email Mozilla/5.0 (KHTML, like Gecko)
Eventually, if everybody switched to sending text/html-for-real first, maybe the email clients could follow along and make text/html also mean "the newest and most featureful version of HTML5"; and then we could all revert to just calling it text/html.
Rather than a distinct MIME type, I believe it could also make sense to borrow the HTTP header X-Content-Type-Options: nosniff (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-...) into the MIME envelope of the text/html document, to signal that this envelope is "really" using HTML, no second-guessing. (This is how the header was used in IE8: to tell the renderer to explicitly not trigger IE historical-renderer compat mode.)
That might get into a situation where the message has two MIME bodies that are both text/html, though, and I'm not sure existing clients have been written to cope with that. A well-engineered solution would work with existing clients (by having them ignore the body of unknown-to-them media-type, and render the old fallback body of known media-type.)
For an application which has rendering HTML content (emails) as its primary function, being a PWA and using something like Electron actually sounds like a good choice.
Hehe, I also moved to an Outlook company a few years back. I’ve had to switch completely to the Outlook Web App (OWA), the native app gets too bogged down after a while, and it’s frustrating to deal with Outlook native across multiple machines. My Outlook experience was vastly improved when I stopped using the native client. And there are a lot of reasons I prefer Gmail as well, Outlook seems to lose threads easily, the spam filtering isn’t as good, and it has all kinds of unintuitive UI quirks and gaps.
Also, if it's going to be a packaged-up version of the Outlook webapp, I'm going to lose the global unread mail folder, which is going to kill me, given the way my inbox folders and rules are set up by customer.
- ed
for some reason I have it in mind as IE5.5 specifically that was The Great IE.
I won't argue that it wasn't decent at launch, but MS kept support for that browser around way too long and failed to actually roll out support for new features that customers desired. I believe it was the era of IE6 specifically that led to the proliferation of top-right-corner.jpg which was an absolute abomination.
But from my stand point then, It Just Worked.
I switched to IE until the Mozilla suit released and later on switched to Firefox 0.something - it was amazing how fast it was compared to both IE6 and Mozilla.
The issue was the length of time that it stuck around for.
I hated it but it made me a lot of money for many years, mostly thanks to governments requiring IE 6 support. LOL
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
I also vaguely remember jwz writing about the experience of developing it.
I don't broadly support Mozilla's aims (I also don't not - I'm an owner of a 1st-gen Firefox phone, for example), but we're just talking browsers here.
IE 5, 5.5 and 6.0 (this last one at least initially, but clearly it stayed around too long without development) were noticeably faster and more user-friendly in my experience.
Don't you dare include me in "our" 8)
My first browser was telnet (1992ish) From 1993 onwards it was all a bit weird in internets land.
For me the golden time for wwwbly_internets was around 2000-5 or so. /. was still (just) worth reading, FB was still a bulge in MZ's trousers. Google was cool, Amazon was clever, Apple was cool. The www was still interesting - US frontier like.
I am of course joking. Today's www is not the same as that in say 2000. Google is not cool, Apple is not cool, Facebook is unpleasant, Amazon is not cool and quite odd.
I guess your damned if you update and damned if you don't.
And it's not necessarily just old stuff, either- there are brand new NVRs and cameras going in today that require IE and some godforsaken ActiveX control to work. IE is going to be around for a long time.
I feel you, and if you're an enterprise user still on the last LTSB release (1803) then yes - Outlook is still using a trident based browser.
If you're on 1903 or above, though, my understanding is that you're now on a WebView2 engine running roughly what's in Edge right now: https://docs.microsoft.com/en-us/microsoft-edge/webview2/
I know for a fact that our company's product for Outlook (an addin.js extension) has suddenly started working for customers in Outlook when they upgrade, and we're not IE11 compatible.
Maybe that's why my replies from Thunderbird using interspersed posting shows up empty for some Outlook users.
My biggest ever frustration.