2
<table class="container">
  <tr>
    <td>
      <table class="row">
        <tr>
          <td class="wrapper last">
            <table class="twelve columns">
              <tr>
                <td>
                  <h1>Hi, Susan Calvin</h1>

This is what it takes to greet a recipient in an HTML email created using Zurb Ink. And it gets progressively worse. Here's a button, for example:

<table class="button">
  <tr>
    <td>
      <a href="#">Button Label</a>
    </td>
  </tr>
</table>

What we have here is around 20 different events that users can subscribe to in order to receive HTML email notifications. Plus, there are (at least for now) two languages this notifications can be sent in. Multiply the two and voilà -- forty distinct template files with massive duplications.

Now, I don't really want anybody here to go insane over this mess, so is my question:

Is there any kind of "meta-framework", which would remove all the duplicated and extraneous markup? I fantasize about preparing HTML email template markup using Bootstrap and then compile it down to Zurb Ink. Or a high-level HTML-like DSL that would then get compiled to Zurb Ink...

 <div class="container">
   <div class="row">
      <div class="twelve columns">
        <a href="#" class="button" />

..or anything else that would simplify our lives.

Anton Gogolev
  • 113,561
  • 39
  • 200
  • 288
  • what is the actual problem? Do you manually edit this HTML? If you use an external tool to create the emails I assume the only thing you need to do is changing CSS which does not really care about the markup complexity... I really doubt there are tools like that because you have a strong connection between CSS and HTML and you cannot just throw out things because they could be referenced in CSS – smnbbrv Oct 02 '15 at 13:37
  • @smnbbrv The problem is duplication and enormous verbosity of HTML. – Anton Gogolev Oct 02 '15 at 13:51

1 Answers1

1

I would say you can manage these two ways. I recently built 17 responsive email templates for a client. It was miserable, the best solution I could come up with was:

The modular approach, kinda like your snippets above are separated. Now you can also use a build tool, we have a boilerplate framework that allows you to write jade and compile to html, of course the bulk of HTML-emails css are inlined, so you can either try your luck with the inliner and compile it, or once the base templates are generated you can save the partials complete with the inline css as includes for jade files.

The other method is to save off header.html, footer.html or use php includes and save the finished html files.

nykc
  • 175
  • 12