HEML: an open source markup language for building responsive email | Hacker News Reader

HEML: an open source markup language for building responsive email

github.com

80 pointskawera31 comments

I applaud the initiative, but how is this better than, say MJML, which has been around for a while and has a lot of support in popular programming tools (For instance, I like the MJML syntax checker and preview in Atom/VS Code).

Reality is - if you want this to get off the ground, you might think about building up a library of pre-existing templates, especially for transactional emails. Those are very few and far between for budding SaaS developers.

MJML is opinionated and prescriptive, to the point of being a markup language in its own right. HEML is not opinionated: You write HTML and CSS. HEML just takes care of all the arcane eccentricities of various HTML mail clients.

Email should be plain text. It’s well working and good enough for just about any need I have.

Graphically designed email is used primarily for marketing bullshit - mails that i’d rather not want to receive at all in the first place.

I agree with you, but most people don't (specially those sending the mails)

In that situation, it seems more productive to advocate for multi-part emails with a sensible plain text part than to sentence "mails should be plain text only", with no arguments and no compromises...

I don't terribly mind html emails as such - sure, it's sad that those that enable html are more likely to get tracked and/or hacked, than those of us that stick to reading the text/plain and distinct attachments (eg: images).

The real question is: does this render nice, full, text/plain? I doubt it - it's certainly possible to go from <rich XML format> to markdown/ReST/etc+html -- but it seems much easier to get good text/plain results by using something like markdown as the foundation (markdown becomes the text/plain part).

The faq doesn't say, and from a glance the docs don't mention text/plain. So I'm guessing this generates invalid email (no usable text/plain part).

You’re right - this way of communicating doesn’t help finding a solution to a situation that - in your and my opinion- shouldn’t exist in the first place :)

I might be just too tired and not be open trying to search for these solutions until someone with a problem in that area hires me to solve it...

EDIT:

Reading my message again I must highlight there are some argumentation points in my original message :)

Are there any practical examples of the output of this language? I don't want to put a marquee in my email. I want to see how "responsive" it is, with blocks and paragraphs of text.

They have an editor where you can preview and see the output: https://heml.io/editor, with an example of marquee..

Right, that's what I was referring to. I don't want to learn the language and design something nice before seeing what I can make with it.

"HEML is designed to take advantage of all that email can do while still providing a solid experience for all clients."

Except mutt, mu4e, notmuch, and friends. :(

Actually, I have my mine fillets set to pump html through w3e, so if you're lynx-friendly, then maybe it'd be passable? I usually just delete html email without reading it though.

Well, any decent company setting up proper emails sends multipart bodies: one for html, and one for plaintext. Text-only clients should never be missing out on the essentials. Of course this relies on companies doing things properly, which is sadly not always the case.

Responsive? Do you mean I get a greater chance of receiving a reply?

Made my day :)

Or even - do i get a greater chance that someone sending me mail is actually willing to accept a reply in the same channel?

Many nowadays just force us to go to their websites, login, find a contact form, read through faq’s first, then find a form that, even though i just signed in, doesn’t know my name and customer number, so i have to enter all these again... to receive a standardized reply a few days later.

So, mail is just abused to force marketing messages down our throats in a single-direction communication.

And most companies investing energy in Mails looking greater do it just for this sake, is my prejudice.

As a receiver of email why would I want to receive a responsive email? What does it mean for me? And how will it look in Thunderbird, etc., when received from someone not on my trusted list?

It means it will look good in Thunderbird and Gmail for Android. Thunderbird will render custom CSS it won't load any external resources though (e.g. images). Maybe it's a nice idea to add preview to this tool how would it look like on Thunderbird and mobile.

What's "trusted list"?

The list of email addresses I know I won't be receiving spam from.

What are the current best practices available for responsive emails? Also, how's the client support looks like for stuff like CSS3 media queries?

Poor. Very... very poor

Best practices are to do as little as possible in my experience

Just use mail chimp. Client support: Abysmal

I wish we would all write email in markdown. It's readable as plaintext and if your mail software wants to make it look fancy it can.

Have you seen [Markdown Here](http://markdown-here.com/)?

I've been a happy user in Gmail at work.

Ha, nice. I've written a command line mail sending thing that works pretty similarly! But I was thinking more along the lines of sending only the markdown over the wire and mail clients adding support for it.

We could just start doing it too, at the moment text/markdown just shows as an attachment in clients that don't support it (i.e. all of them). So we could dual-send markdown as text/plain and text/markdown and gradually make clients adapt!

That's what I dream about at night anyways.

Edit: letters

Which clients are supported? Can't find any information.

It doesn't look too dissimilar to HTML email. What aspect of HEML makes it responsive?

Have you ever written HTML emails? It’s a mess, a disaster, with Outlook using an engine worse than IE5 and everyone else hacking emails to pieces and only supporting certain subsets of HTML and CSS.

This sort of thing makes navigating that absurd maze tolerable, so that you can write something comparatively straightforward and have it transform it into the eldritch horror that is HTML email.

This particular thing includes a few of the more mystical incantations to get the MSO renderer (Outlook and ) to do the right thing. I’m fairly impressed with it for that reason. It stays away from using VML for the best results, which… well, it’s probably safest.

Of course, the result is still far from perfect, because HTML for emails is that bad.

I suspect Lovecraft had premonitions about HTML emails.

> with Outlook using an engine worse than IE5

The worst is not Outlook, you can get it to do what you want most of the time... the worst are the myriad of webmail clients. They do not use iframes (which would be the best way, given you can limit what an iframe can load - scripts, images, other external resources - pretty good), but they filter and rewrite the markup each in a different way so they can inject it more or less safely in the primary markup...

And next upon the list are the Android mail clients, they're a mess, too... and there is no practical way to do automated tests or even comparisons, you gotta test 'em all by hand.

I assure you, I’ve had a lot more trouble on the MSO renderer than others. Sure, webmail clients are commonly fairly dodgy, and Android clients are pretty terrible, but the MSO renderer is the biggest one that seems to actively go out of its way to break your stuff. It’s the one that simply blows up in weird and wonderful ways rather than merely failing to use a declaration.

At FastMail, we’re looking forward to using JMAP in production, because then the defanging of HTML emails will be done on the client side rather than in a rather ancient hunk of Perl that works tolerably well but we’ve mostly avoided touching because JMAP is coming (still, it’s already fairly good as webmail clients go).

Who the hell wants to type markup every time they send an email!?

Makes zero sense to me.

People who design pretty marketing emails and are sick of having them get destroyed by email clients. You want to do as much as possible with as little risk of it getting mangled.

To be pedantic, no one really wants to write markup. Marketers want a simple solution that lets their emails get through intact. This is not a bad solution to that problem.

Reply on news.ycombinator.com