Simplified HTML emails

You have to realize, though, that many email clients have what can charitably be called “nightmarish” support for HTML. MS Outlook is one of the worst offenders and actually went backwards in HTML support in latest releases.

That is, for email you are often better off pretending it is 1999 and no HTML features after that point were ever invented or even used, including a lot of CSS…

so, about that…

This is an extremely high risk, low reward change.

3 Likes

I’m not sure I understand how this is an argument against the proposed changes. I am one of those Outlook users routinely annoyed by its bad HTML support and discourse mails are among the worst in Outlook, especially the summary emails. So my thought while reading this thread was that things might improve with simplifier HTML. But maybe I’m just not grasping the proposed change?

I’m a bit of a fan, which I think shows itself by how much I quote on Discourse :wink:

But joking aside, it’s always been a common and popular practice within Mozilla, and is far easier to do with Mailman or Google Groups (because they don’t wrap content in a table).

Right, but this is exactly what I’m wanting to achieve with simplified HTML. Not to replace tables with flexboxes, but rather good ol’ fashioned <br>'s.

Once you’ve removed the header, is there any risk at all here? This is the table as it currently stands:

So without the header we have a table of one column and one row. That seems like rather an unnecessary table to me.

Summary emails are one of the places I wouldn’t support removing tables. I’m only proposing we remove them because they break responding inline, and where they break responding inline, and the summary email isn’t a respondable-to email. In fact, I’m not sure the layout of the summary email would be possible without the use of tables.

4 Likes

Maybe, if you can prove it by running it through https://litmus.com for the top 10 email clients, then I’ll believe you!

3 Likes

10? How about 24?

Looks pretty good to me :wink:

That’s just a blockquote; where is the table bit at the top with the author info?

Maybe I wasn’t clear enough: by header I meant that table bit at the top with the author info.

Enough author info already appears in the From and Date email headers to make this header unnecessary, when trying to create a mailing list style experience.

This is why I thought you were joking…

I think this also bears repeating, and emphasising:

If anything here can be more generally applied, that’s great, but the primary goal of the proposal isn’t to change default behaviour, but rather add an option for simpler, more mailing list-esque, emails out.

2 Likes

Strongly disagree, username, full name, avatar and title would all be missing.

I suggest you try rebuilding that without tables, as you proposed.

1 Like

It strikes me that you could start with Step Zero:

Make just the header a table, the part in the top <tr> row pictured ↓

… and move the rest of the email, the bottom <tr> row ↑ , outside that table.

4 Likes

That’s sort-of the point, though. Putting all that metadata at the top of the email clutters it up, and I’m aiming for simplicity here.

GitHub does this, dropping its avatar, username and title:

Not the same, github does not have title or full name, plus it lacks optional group overlays on avatars too.

I think there is a huge divide here, which is why you are having trouble parsing this:

On one side of the :mountain: you have users who use “email” as a “trigger” to get them to visit forums.

On the other side you have users who want to do the majority of interaction via email, they do not care that a forum exist, all the want is MAILMAN foreva ™

For the mailman users:

  • They do not care about titles and avatars, email is enough, when they see all this duplication they have an internal fit.

  • They also do not care about all the emphasis to visit the site, large footers and big blue buttons turn them off.

  • They hate the way titles are full of [XXXX] [YYYY] before they see actual title.

I do not see us being able to make both “groups” of users happy out of the box that easily.

What I would prefer to see done here is to provide the extensibility to override these templates.

Where I would recommend starting is with a plugin that allows users to select an email template as “minimal” or something along those lines. Then @LeoMcA can have all the Mailman ninjas :necktie: simply select a different “minimal” template.

I think it is incorrect to look for a solutions that works for two groups that have almost nothing in common. We will just end up making everyone unhappy.

14 Likes

This sums it up nicely. Here on meta, we’ve been through this conversation several times already through the years, and I’ve resigned myself to look to the future and think of discourse more as a self-hosted facebook equivalent than an upgrade to mailman or google groups.

Here are two readily available examples:

Right, this was what I was trying to get at by proposing putting this behind a global pref, thanks for putting it more clearly.

I hadn’t considered that even within Mozilla there may be people who want to use email as a “trigger”, rather than for interaction - so a user preference makes more sense. We’d probably be wanting to set it to “MAILMAN foreva ™” mode by default, though :wink:

This is required, I can’t see a way of managing to change the template used from a plugin without doing something horrific like monkey patching ActionView::Helpers::RenderingHelper#render.

And I think it makes sense to place these custom templates in a plugin - it allows individual Discourse instances to use whatever custom templates they want.

But I’m not sure between those two points what should be in core, and what should live in a plugin. Would you see this extensibility in core take care of the user preferences side of things, simply enabling a plugin to specify a template and name?

Or would you see the piece in core being more general, allowing any plugin to override any template, with this specific plugin hooking into that and handling the user preferences side? How would we decide, in core, which plugin gets the final say on what template gets rendered?

Yes this is my preference.

I think that is imagining a problem that will, in practice, never exist

1 Like

I disagree; I think the HTML email was in a giant table for … zero good reasons.

De-table-izing this in the HTML emails, which is currently active as you can see ↑ above, is worthwhile in the name of simplicity alone, putting aside every single other issue.

KISS! :kiss:

3 Likes

Has this helped things now that this change shipped in 1.8?

Definitely - when combined with enabling incoming email prefer html, inline responding now works pretty well! :tada:

It’s not perfect, but good enough for the time being. We’ve got a few other priorities at the moment, but getting rid of that pesky additional metadata (through a plugin, as discussed above) is still on our roadmap.

8 Likes

Is this still on your list @LeoMcA?

Somewhere, way way way down on the list. I’m not gonna get to it anytime soon, so if someone else wants to work on it there’s no danger of duplicated work.

2 Likes