It’s always been difficult to send Coda content as a professional HTML email. This pack tackles all of the heavy lifting by converting the HTML Coda exports to email friendly HTML. There are some fun Easter eggs and power user features included as well.
One Simple Formula
CreateEmail([My Page])
Pack: https://coda.io/packs/html-email-pro-43947
Doc: https://coda.io/@ben/html-email-pro
Check out the companion doc for a ton of information on what the pack includes, how to use it, and exactly what’s supported.
- Facepiles
- Image Handling for Every Scenario
- Exhaustive Table Style and Conditional Formatting Support
- Easy Style Presets, like
darkmode
- Full Power-User Control
ProMode and ColorMap for Power Users
For power users who want full control, all styling configuration attributes are surfaced and configurable with ProMode and JSON. The doc even includes an easy to use JSON builder for this. And if you want absolute control over colors, a ColorMap is also included so you can customize red to your preferred and exact red. This doc also includes an easy JSON builder for this feature.
Give it a try and I’d love feedback!
8 Likes
This is an excellent and powerful pack.
I will take it for a spin and let you know how it goes.
Well done.
Max
1 Like
Thank you so much, @Max_OBrien!
I’ve added the Mailgun(Email on Acid powered) results to the doc now. I’ll find some time to tag them better soon, but you can use table search until then. There are 100 device/system/client previews to click through. Only an issue or two on older systems and holding off a bit to see if they even matter. I’ll tag those later as well so they stand out and people don’t have to search for them.
2 Likes
How things render side-by-side
See side-by-side images for all features at What's Supported · HTML Email Pro .
Images in a grid setup
Inline images
Tables
Table conditional formatting
Notes
The pack truncates tables with rowLimit so you never have to worry about sending an email with 50,000 rows on accident. And rowLimit is an optional formula parameter so you customize it to your needs.
There is even an appended last row with a message “showing the first {count} rows” so readers know the table was truncated.
2 Likes
New Release: v1.1.1
Fixed a few bugs where special characters were corrupting output in a few areas. Also cleaned up some tech debt and improved stability and maintainability.
Highlights
- Special characters in your content (like $, &, <, and quotes) now render exactly as typed.
- Button labels display character-for-character, including symbols like & and <, with no risk of broken or missing text.
- Table footer and facepile overflow messages now render as plain text, so apostrophes, ampersands, and other common symbols always display correctly.
- Custom list marker symbols handle special characters reliably.
- General internal cleanup for long-term stability and maintainability.
2 Likes
Haven’t tested it out yet but looks like stellar work!!!
Seems like leaving Coda did you well @Ben_Lee 
Can’t imagine you making this pack while being officially on the team.
Technical question. Do I understand it correctly that when you pass a page/canvas to a Coda formula (an action formula probably), it implicitly calls ToHtml() on it and passes it as HTML already? And your pack then transforms that HTML? Or do you get to the page’s formatting metadata somehow differently? (i.e. obtain the Slate object and then load tables separately)
P.S. Nvm, read the accompanying doc. Seems like you’re already receiving the Coda-rendered HTML of a page in your pack.
One of the ways you could restore the e.g. columns and callout styles is if you also asked pro users to pass a [Page]._Merge().ToText() of that page, and then figure out proper styling from that data. Just an idea 
2 Likes
Hi @Paul_Danyliuk!
This uses the same functionality as the ToHtml() pack formula from Eric Koleda’s pack.
I picked this project because my goal was learning more about code building strategies and HTML email is an impossible problem to solve. That means plenty of decisions would have to be made and I’d have to really dig in and understand every aspect. The clearest example of this is Outlook requires MSO conditionals to display a lot of the nicer styles, but Gmail strips all MSO code before sending it. Finding best fit solutions over 30 email clients that all conflict with each other is why no engineers ever wanted to take this on with me, even as a hackathon project, and rightfully so.
But I’m pretty proud of what I was able to accomplish with it. I was also a big part of the performance efforts while I was at Coda, so there are a lot of efficiencies built into this. Like truncating tables before processing all the HTML so the pack doesn’t spin on 50,000 records that aren’t intended to really be emailed. Or creating the JSON override system for configurable variables that’s used both for ProMode as well as for the quick style presets. One system powers multiple features.
I like your idea on using _Merge() to get the extra JSON data about the page or canvas, but It gives me a gut feeling that there could be content collisions or issues under certain circumstances. There’s just something about both pieces being lossy in data and having to be parsed in a way that provides reliable matches, even if the exact same line of content is used repeatedly in a page. I want to hold reliability as a high priority on this project.
I was also careful to use graceful failure rules instead of breaking errors. If a color is passed in that doesn’t match a colormap value, it retains the passed in color instead of erroring out. There are chains of fallbacks too so it’s pretty robust.
The goal wasn’t to offer every feature, it was to choose the fewest number of optional parameters that offered the maximum flexibility and most desired features for end users. The one hard-line rule is that only one required parameter is allowed, keeping it easy for users of any technical skill level.
Definitely test it out and keep posting your thoughts if things come up!
4 Likes
