[jameslk]

I'm surprised we haven't seen the mIRC's of email yet (or maybe there have but that just didn't work?). mIRC was a popular client for IRC on Windows. It extended IRC with features such as color and formatting in your messages, which was beyond the protocol. A feature like that worked just fine because the color codes were mostly invisible to those who weren't using a client that supported them. In this way, mIRC and other clients could move the protocol forward via graceful degradation without having to wait for a new IRC specification update.

I can imagine the same thing being done to email, where modern features could be built on top of email, which just gracefully degrade if those features aren't available in the client (e.g. something similar to inline source maps, which can decorate parts of the email for clients that support it, but are otherwise out of view for clients that don't). If the feature is useful enough, other clients will adopt them, pushing the protocol forward.

[moreira]

That can be done easily enough with @media queries, I suppose. It's possible to send a table-less, fully responsive, modern HTML email that is invisible for less-modern clients. It doesn't require anything special and is possible today.

The problem is that people who send email need it to look a certain way, and leaving older clients behind, just like you'd have done in IRC/mIRC, is not an option. So having the option to use modern features doesn't change anything, at least for email.

[Spivak]

> The problem is that people who send email need it to look a certain way

I think it's fair to say that actual people don't need any of this. It's businesses and advertisers that would be the overwhelming consumer of these abilities.

[marssaxman]

> The problem is that people who send email need it to look a certain way

As a person who receives email, I would really prefer the people who send email not to have this ability.

[jon-wood]

Multipart emails have been doing this for as long as I can remember - emails are delivered with an HTML part and a plain text on for compatibility with clients that don't support it. There's no reason you couldn't release your new mail client with text/mailml support, but you'll have to get people to use it.

[majewsky]

> with text/mailml support

Also, please use text/markdown instead of inventing yet another weird markup. Bonus points if it's CommonMark (which is much more strictly defined and thus guaranteed to look the same across renderers).

[Freak_NL]

I've wondered about the viability of text/markdown for email from time to time. It would make a very nice sensible default: the sender can write an email with a hierarchy of headers, quoting (exactly the same way done now with text/plain and supported by most clients), emphasis, hyperlinks, lists, etc., all without depriving the receiver of their preferred formatting and font settings. Also, not nearly as verbose as HTML (and not nearly as much crap).

[spyhi]

I've been thinking about this a lot lately--I'd really love in-email applications, especially with Web Assembly working its way into viability. Being able to act on stuff without leaving my inbox would be fantastic. Unfortunately, lots of potential for abuse and also the fact that email protocol is so entrenched.

[mattkrause]

So...Lotus Notes?

[wwn_se]

no, no, please dont hurt me, please.............

[Alex3917]

> I can imagine the same thing being done to email, where modern features could be built on top of email, which just gracefully degrade if those features aren't available in the client

There are dozens of apps like this. The most straightforward example is probably Redkix.

[krrrh]

winmail.dat [1]

[1] https://mobile.nytimes.com/2010/11/25/technology/personaltec...