{"id":269999,"date":"2018-04-20T06:58:58","date_gmt":"2018-04-20T13:58:58","guid":{"rendered":"http:\/\/css-tricks.com\/?p=269999"},"modified":"2018-04-23T08:58:03","modified_gmt":"2018-04-23T15:58:03","slug":"choosing-a-responsive-email-framework%e2%80%8amjml-vs-foundation-for-emails","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/choosing-a-responsive-email-framework%e2%80%8amjml-vs-foundation-for-emails\/","title":{"rendered":"Choosing a Responsive Email Framework: MJML vs. Foundation for Emails"},"content":{"rendered":"

Implementing responsive email design can be a bit of a drag. Building responsive emails isn\u2019t simple at all, it is like taking a time machine back to 2001 when we were all coding website layouts in tables using Dreamweaver and Fireworks.<\/p>\n

But there’s hope! We have tools available that can make building email much easier and more like coding a modern site. Let\u2019s take a look at a couple of different frameworks that set out to simplify things for us.<\/p>\n

<\/p>\n

First, the Situation<\/h3>\n

You have to be compatible with lots of old email clients, many of which don\u2019t even support the most basic web standards (floats, anyone?). You also have to deal with all sorts of webmail clients which, for security or technical reasons, have made their own opinionated choices about how to display your precious email.<\/p>\n

Furthermore, now emails are read from different devices, with very different viewports and requirements.<\/p>\n

The best solution, as is often the case, would be to keep things simple and stick to basic one-column designs, using multiple columns only for menus or simple interface elements of known width. You can produce great, effective designs using only one column, after all.<\/p>\n

However end-users and clients, who are used to the \u201cnormal\u201d browser-based web, may hold their email-viewing experience to the same high standards they do for viewing web pages in terms of graphics and responsiveness. Therefore, complex designs are expected: multiple columns, different behaviors on mobile devices as opposed to desktops, lots of images, etc., all of which have to be implemented consistently and pixel-perfect across all email clients. What options are available to make all that happen?<\/p>\n

Option 1: Build From Scratch<\/h4>\n

One option you could choose is coding each email by hand, keeping it simple, and testing it while you go. This is a viable option only if:<\/p>\n

    \n
  1. You have a very simple design to implement.<\/li>\n
  2. You have direct control of the design, so you can eventually simplify things if you can\u2019t come out with a consistent solution for what you intended to do.<\/li>\n
  3. You can accept some degree of degradation on some older clients: you don\u2019t mind if your email won\u2019t look exactly the same (or even plain bad) in old Outlook clients, for example.<\/li>\n
  4. You have a lot of time on your hands.<\/li>\n<\/ol>\n

    Obviously, you need to test your design heavily. Campaign Monitor has a great CSS guide<\/a> you can reference during the build process and is sort of like Can I Use, but for email. After that, I recommend using automated test suites like Litmus<\/a> or Email on Acid<\/a>. Both offer you a complete testing suite and previews of how your email will look like on a huge variety of email clients. Expect some surprises, though, because often the same design does not look correct even on the same email client, if viewed on different browsers, or different operating systems. Fonts will render differently, margins will change, and so on.<\/p>\n

    \"\"
    Screenshot of the same email design tested on different devices on Email on Acid.<\/figcaption><\/figure>\n

    Option 2: Use a Boilerplate Template<\/h4>\n

    Another option is to use one of the various boilerplates available, like Sean Powelll’s, which you can find here<\/a>. Boilerplates already address many of the quirks of different email clients and platforms. This is sensible if:<\/p>\n

      \n
    1. You are working alone, or on a small team.<\/li>\n
    2. You have lots of experience, so you already know most of the quirks of email formatting because you\u2019ve met them before.<\/li>\n
    3. You have set up your own tools for managing components (for different newsletters which share some pieces of design), inlining styles<\/a> (and yes, you should keep inlining your styles<\/a> if your emails target an international audience), and have some kind of development toolkit in place (be it Gulp, Grunt or something similar) which will automate all of that for you.<\/li>\n
    4. You have the kind of approach where you\u2019d like to control everything in the code you produce and don\u2019t like to rely on external tools.<\/li>\n
    5. You prefer to solve your own bugs instead of having to solve possible bugs caused by the tool you are using.<\/li>\n<\/ol>\n

      Option 3: Use a Framework<\/h4>\n

      However, if any of the following points are valid for you:<\/p>\n

        \n
      1. You have to produce a lot of email templates with shared components.<\/li>\n
      2. The job has to be carried out by a team of developers, who might change and\/or have a variable degree of proficiency and experience with email implementation.<\/li>\n
      3. You have little or no control on the original design.<\/li>\n<\/ol>\n

        …then you will likely benefit a lot from using a framework.<\/p>\n

        Currently, two of the most interesting and popular frameworks available are MJML<\/a> and Foundation for Emails<\/a>. The biggest advantages in using either framework is that they have already solved for you most of the quirks of email clients. They also provide you with an established workflow you can follow, both alone and as a team. They also handle responsive design very well, albeit differently from one another.<\/p>\n

        Let\u2019s look at an overview of both frameworks and compare the best use cases for each before drawing some conclusions.<\/p>\n

        MJML<\/h3>\n

        MJML<\/a> is a project that was created internally by Mailjet<\/a>, a company specializing in email marketing tools. It was then open-sourced. It works with its own custom, HTML-like templating language, using its own tags. For example:<\/p>\n

        <mj-text>Your text here<\/mj-text><\/code><\/pre>\n
        When you compile the final code, MJML will convert their tags into HTML for everything from tables to custom components they have created for you, all using its internal engine. It takes out the heavy lifting for creating complex markup and it\u2019s all been tested.<\/p>\n
        MJML has a set of standard components<\/a>. They include sections, columns, groups, buttons, images, social links (which are very easy to create), tables, accordions, etc. They even include a pre-styled carousel, which should work in most clients. All of these components translate well into responsive emails, apart from the \u201cinvoice\u201d component which I could not get to work in my tests. All of these components have parameters you can pass in your code to customize their appearance.<\/p>\n
        For example, the social links component allows you to stack icons vertically and horizontally, and to choose background colors for the related icons. There are actually a lot more parameters<\/a> you can play with, all with the intent of allowing for greater flexibility. Even the logo image files are already included in the package, which is a great plus.<\/p>\n
        Here\u2019s a preview of a simple configuration of the social links component:<\/p>\n
        \"\"
        Screenshot from the MJML website<\/a>.<\/figcaption><\/figure>\n
        You can also create your own custom components<\/a>, or use components created by the community. There is just one community component available at the moment, however.<\/p>\n
        MJML handles responsiveness automatically, meaning that components will switch from multi-column (more items in the same row) to single-column (items are put one under the other instead of side-by-side) without any active intervention from the developer. This is a very flexible solution, and works fine in most cases, but it gives the developer a little less control over what happens exactly in the template. As the docs mention<\/a>, it’s worth keeping mind that:<\/p>\n
        For aesthetics purposes, MJML currently supports a maximum of 4 columns per section.<\/p><\/blockquote>\n
        This is most likely not only an aesthetic preference but also about limiting possible drawbacks of having too many columns. The more columns you have, the more unpredictable the output, I guess.<\/p>\n
        How to Work With MJML<\/h4>\n
        MJML can work as a command line tool, which you can install with npm, and output your files locally, with commands like:<\/p>\n
        $ mjml -r index.mjml -o index.html<\/code><\/pre>\n
        This can be integrated in your build procedure via Gulp or the like, and in your development work by using a watch command, which will update your preview every time you save:<\/p>\n
        $ mjml --watch index.mjml -o index.html<\/code><\/pre>\n
        MJML has plugins for Atom and Sublime Text. In Atom, it even supplies a real-time preview of your layout, which can be regenerated on every save. I haven\u2019t tried it personally, but it seems very interesting:<\/p>\n
        \"\"
        Image from Atom.io<\/a><\/figcaption><\/figure>\n
        MJML also has its own simple desktop app<\/a>, and it\u2019s free. You can set up your code and components, have it build your designs for you, and get a real-time preview of the results, both for mobile and for desktop. I find that it works pretty well on Ubuntu, but the only drawback I\u2019ve found is that you should never, never, never<\/em> open your files with another editor while they\u2019re open on the app, because the app crashes and the content of the file gets lost.<\/p>\n
        Here are some screenshots of the previews at work:<\/p>\n
        \"\"
        Desktop preview of email<\/figcaption><\/figure>\n
        \"\"
        Mobile preview of email<\/figcaption><\/figure>\n
        The app can also be integrated with a free Mailjet account, which allows you to send test emails immediately to yourself. This is very handy to quickly check problematic clients if you have them available directly. (I would suggest taking out that old Windows machine you have in the storage room to check things in Outlook, and to do it as often as possible.) However, I would still recommend using either Litmus or Email on Acid to test your emails cross-client before deploying them because you can never be too careful and email standards can change just like they do in browsers.<\/p>\n
        Overall, I have found MJML very easy to use. However, when I tried to make a pixel-perfect template which was identical to the design our client requested, I had some difficulties dealing with custom margins for some images. Not all of the component parameters available worked as expected from their description in the documentation. In particular, I had some problems customizing image margins and padding between desktop and mobile.<\/p>\n
        Advantages<\/h4>\n