Hacker News new | past | comments | ask | show | jobs | submit login

I smell a lot of nostalgia in this thread, and rightfully so! IE has been a terrible browser, but it was our terrible browser.

But fear not! Outlook still uses the HTML parsing engine from MS Word (!) to display your HTML emails, and it's not going anywhere.




When Outlook becomes a PWA (currently in test, I think it's probably two-three years from stable), it'll be rendering mail with all the functionality of Blink. Which depending on your point of view, means a sigh of relief or time to buy more RAM.

https://www.windowscentral.com/project-monarch-outlook-web-u...


But Gmail is already a web app, and only supports a tiny subset of modern HTML and CSS. The limitation is of course arbitrary, it could in theory support any modern standards. But HTML mail is so quirky and full of hacks, that they probably have to do it that way to preserve compatibility. Apple's Mail app is one of the few modern mail clients that can render modern HTML/CSS


Given that email is MIME (i.e. you can add multiple “bodies” to a message, with different content-types, and the email client will select the best one it can render), you’d think we could just come up with a new content-type for email meaning “HTML, but for real”, and add that to email in addition to the current “HTML, but sucky” semantics we get from text/html-typed bodies.

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.)


I wish people sent text/plain as a fallback for text/html...


CSS grid email designs would be great, but we'd also get an avalanche of nightmare canvas-tag spam...


A canvas tag won't do much without scripts, and I really don't believe any client would allow running scripts from email...


Maybe more people will then demand plaintext as we come full circle


You can have one without another! Apple Mail supports grid, but doesn’t support canvas or script tags.


> a new content-type for email meaning “HTML, but for real”

text/email Mozilla/5.0 (KHTML, like Gecko)


I get what you mean, but it's not like we'd have to keep adding these on. "text/html" on email clients currently means "some specific ossified version of HTML4"; but text/html-for-real would hopefully mean "the newest and most featureful version of HTML that your rendering engine can manage." So there'd just be the one version of it.

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.)


> Apple's Mail app is one of the few modern mail clients that can render modern HTML/CSS

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.


I vote for putting HTML in calendar invites. As worst thing, I precise.


That's true, and I wish that emails could just work like everything else on the web. But simply removing Outlook and all its baggage from the equation would be a big, big improvement on the status quo.


There are good reasons to reject a lot of it. You don't want JS running in an email for example. Or even some of the fancier CSS abilities.


By "I wish that emails could just work like everything else on the web" I meant modern web HTML/CSS - I was replying to the GP - not the full set of browser capabilities such as Javascript. I suppose it's possible you'd also want to exclude certain CSS abilities, but at that point you're now diverging from the web CSS spec which isn't ideal either.


Web standard is continuously evolving but email don't need most of them. I think whitelist approach is better than blacklist for email.


Yes, but then who maintains the whitelist? What's to stop individual email providers from deciding they do/don't like certain standards? I agree that email doesn't need much of the CSS spec, but nor do the vast majority of web sites and yet we don't like it when browsers aren't standards-compliant...


HTML/CSS is designed to be safe for web by browser vendors and working groups. Unused HTML/CSS feature is fine as long as it's not vulnerable, but blacklist for email is problem because new feature is not designed to be safe for email.

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.


Can you share some CSS vulnerabilities that would work in email but not in a browser? I can certainly think of CSS vulnerabilities that would not work in email because email can't execute javascript, but can't come up with the reverse off the top of my head. Genuinely curious here.


* Any way that reference external resource like css url() can be used as beacon. It should be blockable by client like image, but thinking how it affect is difficult if all tags are allowed.

* 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)


> * Any way that reference external resource like css url() can be used as beacon. It should be blockable by client like image, but thinking how it affect is difficult if all tags are allowed.

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.


> You can already use url() to load background images - seems like this is a solved vector.

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.


I don't think there's any HTML or CSS that is problematic in an email. The problem is Javascript.


The surface of HTML+CSS is pretty big by now. Perhaps you could use CSS to restyle the "From" address: hide the original content and use an :after property to put "$bank_name" there. Perhaps you can generate a unique @font url for each user to track opening of messages. Just two things of the top of my head that maybe won't work, but it would probably be a cat and mouse game for a while when security researchers start poking at it.


Sounds like you’re talking about the subset of HTML+CSS used in ePub. Come to think, ebooks and emails have pretty similar “richness” needs.


That's a great idea, just use the ePub standard. Never made the connection between ebook formatting and email formatting before, nice.


Most ePub readers are intentionally not compliant with the standard, because the standard allows way too much. Including, for example, arbitrary execution.


> Sounds like you’re talking about the subset of HTML+CSS used in ePub.

EPUB3 supports JS.


EPUB3 is a half-baked standard that nothing actually fully supports. The JavaScript parts especially—most e-readers don’t ever plan on adding JS support, even if they nominally support EPUB3.


But then why have HTML email at all? You could just write in markdown.


Why have HTML email in the first place? No other messaging client lets you send entire HTML documents as messages. Just send me some words and a link to click on in a proper browser. The fact that HTML email is so bloated and a nightmare to eyeballs eveywhere is (IMO) a huge reason why conversations (even professional ones) shifted over to Slack, SMS, WhatsApp, FB Messenger, etc. I want a place to talk to people, not to shitty template engines. But if you're going to automate my conversation, use words, not posters.


You're comment made me think about why we actually use slack/IM when email is just as capable and I think the answer is that I can have notifications turned on for IM and I can't do that for email. Which means I respond much slower to email.

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 supports instant notifications, via your provider’s app or IMAP IDLE. I use Fastmail and get push notifications for email the instant it is received.


The point is if I turned on instant notifications I would go insane because they would never stop. I receive lots of emails and a lot of them are not very important or at least not urgent. While every IM I receive is something I at least want to glance at now.


That point, frankly, applies to some Slack workspaces too. Some of them just have too many notifications to keep track of.


Email notifications are flexible. I can choose to receive notifications only from contacts, search terms, or specific people.


I'm intrigued by that idea. Markdown or Markdown-like subsets have proven to be sufficient for communication in a variety of media (Slack, Wikipedia, forum comments, GitHub issues/comments, etc.)

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.


Not a bad idea.


AFAIK Thunderbird just uses Gecko - I wonder whether it's not running into similar problems.


Wow this is awful. I just moved to an outlook company after years on google. It’s so nice having my mail client be native.


> I just moved to an outlook company after years on google. It’s so nice having my mail client be native.

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.


Thunderbird is still a thing and Google supports IMAP.


Many companies disable IMAP for data security


FYI, Gmail works on Outlook. But the ability to use extensions may be limited on some platforms.


Is it?

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.


Damn, hopefully it is more than two or three years out. I'm enjoying Outlook being one of the most stable and least resource-hungry applications that I run on a daily basis.

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.


More RAM or worse performance? I doubt it, given the COM addons my employer stuffs in my Outlook client. Zipmail among others.


If you want to switch to this, PWA install is available for Outlook Web App right now (just sign into outlook.office.com and click on the plus button that appears in the address bar in Edge or Chrome). If you don't have any crazy mail needs it works fine.


Thanks for the tip - I just tried this out in the free outlook.com client, and it works there too.


I'm pretty ok with emails just being barely more than text thank you


Outlook is a PWA


Going a bit further back, IE 5 and 6 were the best browser by far. Strange for me to think that my now-beloved Firefox has its heritage embedded in Netscape, which at the same time as IE5 was an absolute pig.

- ed

for some reason I have it in mind as IE5.5 specifically that was The Great IE.


I have a version of myself aged in their twenties and working in web development that really wants to stab anyone believing that IE6 was the best browser.

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.


Compared to IE5 and Netscape Navigator 4, it was a great browser!

The issue was the length of time that it stuck around for.


Oh, don't get me wrong - it was a Trojan Horse, and my first ever web browsing experience was on Navigator, so it was a hard-hearted appreciation at the time.

But from my stand point then, It Just Worked.


Same for me - I started browsing the web on Mosaic and quickly switched to Netscape. I hung on during the Netscape 4.x days but at some point couldn't deny how much better IE was (I think maybe even IE 4 was already as good or better than Netscape).

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.


Some time around 2001 or 2002 I bought Opera (with tabs!) and that just made the internet usable.


IE6 almost made me quit web development once it grew stagnant. It was put on the back burner at some point and they rested on their laurels until Firefox started eating IE’s market share.


As a web developer, I might have billed 3x more hours thanks to IE 6. :P

I hated it but it made me a lot of money for many years, mostly thanks to governments requiring IE 6 support. LOL


IE 4 specifically was the big milestone. MS had a lot of catch up to do (they mostly ignored Internet before that). I've written web apps in IE4 (around 2000), it was capable of dynamically generating and manipulating the dom. While Netscape 4 could barely change a color of an element without crashing.


It was IE 5.5 that was particularly a champ compared to the terrible Netscape Communicator / Netscape 4 product. I continued to regularly use Netscape 4 through those years, as I didn't like IE, and it was a real dog in most every respect. Netscape took their eye off the ball in an attempt to further build their business away from the browser (Communicator of course was their suite attempt), and failed at both things in the process.


There's an old post about that by Joel Spolsky that I remember thinking was particularly insightful at the time:

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

I also vaguely remember jwz writing about the experience of developing it.


Thanks for confirming - I wasn't sure if I was mixing up the version number with Photoshop, which 5.5 was (if memory serves) the one that fixed terribly-kerned typesetting in v5, and added some new web-export wizziness.


I never got the feeling that IE was a good browser. It came by default with windows and that made it specially popular, but never good. Alternatives always looked like a better option.


As someone who used Netscape, IE and Opera back then, Netscape was unfortunately very buggy (and not just in terms of stability). It's offline cache didn't always work (i..e you could resize the window, and it would re-download things instead of using the local cache, which was very painful on 28.8 dialup!) I remember being able to browse some sites very quickly while dialed up in IE, and then later offline be able to view them more leisurely all fine in offline mode. Netscape couldn't consistently do that.

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.


Then you weren't around in the IE5-6 era. It was definitely a better browser. But then they decided IE6 could never be improved and sat on it for years.


IE was positively fantastic at the time. So much more stable, light-weight, and sane than Netscape Navigator.


Did we forget all about Mozilla already?


Nope, still using two of their products today, and waiting for the moment (as, I think, promised soon?) wherein I could donate/pay directly to/for firefox.

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.


I think you proved his point. ;) He's talking about the Mozilla browser, the precursor to Firefox. (Well actually, Firefox was named Phoenix before it became Firefox.)


Right and my memory is telling me that I was using it since one of the milestone releases, well before 0.9.5 when they added tabbed browsing.


Firebird


First Phoenix then Firebird, then they changed the name to Firefox because of the similarly named database (https://firebirdsql.org/).


Wasn't that the email client?


I think the email client was Thunderbird

https://en.wikipedia.org/wiki/Mozilla_Thunderbird


The email client is still Thunderbird, it's in active development.


"but it was our terrible browser."

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.


eBay has changed very little since then if that helps, however PayPal might as well be unrecognisable.


I often think that EBay are outdated in almost every regard. Their UI is confusing, spaghetti code, an obvious mixture of old pages and new pages and until recently, still seemed to use some bootstrap dll for requests.

I guess your damned if you update and damned if you don't.


I work in small business IT, and I literally have to use IE11 on a weekly basis to interface with some shoddy something.

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.


Isn't that also what people said about Flash?


Yes, and they were right. I have to deal with Flash regularly, too. So much so that I keep a VM around for solely that purpose.


> But fear not! Outlook still uses the HTML parsing engine from MS Word (!) to display your HTML emails, and it's not going anywhere.

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.


I agree with this one; it will always be etched on our hearts. The good thing is that even though IE 11 will retire, Microsoft Edge is here to stay. It's even better than other browsers, for sure. I tried using it, and I love the browsing experience.


If they took the Edge rendering engine (which is really like Chromium or some close approximation of it now) and put it in the IE UI instead of the opposite, I think that would get a lot of praise from me and probably many others including all the Google-drunk web developers. Those who like IE and prefer it to other browsers are doing so despite its horrible rendering engine.


The Edge rendering engine is Blink, because Edge is a fork of Chromium now.


I doubt such users had used Chrome frame instead of Chrome.


> Outlook still uses the HTML parsing engine from MS Word (!) to display your HTML emails, and it's not going anywhere.

Maybe that's why my replies from Thunderbird using interspersed posting shows up empty for some Outlook users.


I was helping a friend out with html email templates a while ago, and it was like time traveling back to 2001 Geocities web development. Table hell…


> But fear not! Outlook still uses the HTML parsing engine from MS Word (!) to display your HTML emails, and it's not going anywhere.

My biggest ever frustration.


no, not really. If I could I would be the first to thrown it in a deep hole in the ground and seal with concrete to make sure it never rises again.


not my browser! i use Linux - Chromium or Firefox




Applications are open for YC Winter 2023

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: