Replies: 1 comment 1 reply
|
Hey @vnunez85 thanks for the comment! I think that's a great idea. And as you mentioned, it would come pretty easy to implement, because we already have everything bootstrapped, well, except the most important part, the emailing. You mentioned it would not need any actual emailing, and would do exports, but we plan to have emailing ASAP, and this would complement it in a nice way, to have it integrated directly in Instatic. I am not yet sure if it would come as an plugin or part of a core. I will need to prototype it and think about it, so we will see. |
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Instatic already has a visual canvas, design tokens, and a publisher that outputs clean HTML and CSS. It feels like a natural extension to add email as an output format.
The idea: let users design an email template on the same canvas they use for pages, then export it as a downloadable HTML file with inlined, email-client-compatible markup (tables, inline styles, the whole ugly-but-necessary stack). No sending, no SMTP, no campaign management — just design and download. Users can then drop that HTML into whatever ESP they already use (Campaign Monitor, Mailchimp, etc.).
On the implementation side, two approaches come to mind:
Either way, the publisher already knows how to transform canvas output into clean markup — email would be a second compilation target rather than a ground-up feature.
Right now anyone designing emails has to jump to a completely separate tool. If the canvas could export email-safe HTML alongside its current static page output, Instatic becomes the one place for both web and email design.
Would love to hear if this is on the radar or if there's a plugin approach that could get there.
All reactions