[RandomInteger4]

This is tangential, but needs to be stated:

What I've learned from email newletters is that Microsoft Outlook needs to die a swift and horrible death.

There is absolutely no good reason why we should have to create email newsletters that require tables for layout.

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

[Alex3917]

> There is absolutely no good reason why we should have to create email newsletters that require tables for layout.

One of my projects over the last couple months for FWD:Everyone has been stripping tables from commercial emails while keeping their content and trying to preserve a comparable layout while just using paragraph tags and other simple markup. It's an interesting challenge, given that tables can be recursively nested inside cells in all sorts of different combinations. You'd think that it wouldn't even be possible to do this and get the ordering of block elements right, but it actually seems to consistently work for tables with mostly text content.

In our case the reason we did this because we want to format emails in a consistent way to make them readable, and also it's easier to guarantee that our redaction tool is properly redacting content when we limit ourselves to a fixed subset of HTML.

[squiggy22]

Web based mail clients are nearly as bad with how much CSS etc. they strip out. Gmail is particularly aggressive. Yes Outlook is terrible, but there's plenty of security conscious developers throwing baby out with bathwater when it comes to email design .

[spookyuser]

I don't know how inbox does it, but I like how some newsletters are rendered on it, the product hunt newsletter shows up as just the top three/four posts of the day.

[JetSpiegel]

That and HTML email that doesn't have a text/plain alternative. Even the braindead conversion contain some nuggets of information.

[Spivak]

If you want your email to look the same on all clients text/plain is the way to go.

[Flimm]

That's not true. Plain text is usually hard wrapped with newlines, which leads to awful experiences on small screens.

[mi100hael]

You can send plain text encoding with format=flowed to avoid the hard wrap. Personally I prefer 80 chars, though. Still looks fine in landscape mode on any phone.

[fiddlerwoaroof]

Using lynx with `-stdin -dump` works pretty well in mutt

[JetSpiegel]

I had that, but lately I got best results from pandoc.

[catmanjan]

Worked on my first HTML email template, was a real blast to the past... Tables for layout and inline CSS on every leaf node is recommended...

[gogopuppygogo]

Apple Mail is no peach either.

In a dream world Microsoft & Apple could partner together on this and create a better set of standards...

[mgkimsal]

yahoo, gmail and others need to fall in inline - they all seem to require tables.

[markdown]

At this point I'd settle for them all just supporting the exact same elements and properties in the exact same ways.

The type of element is less important than there being consistency and documentation.