Make HTML Email Development in Rails Better With These Tools
If you’ve worked with HTML emails, you know that they pose their own special challenges. Best practices for CSS in emails are different from best practices for modern web CSS. It’s tricky to preview changes, and testing on different email clients gets time consuming quickly.
But there’s a few tools and tricks you can use to set up an email development workflow that looks more like the front-end development workflow you’re used to. Read about them below, or skip straight to the example Rails app set up with all of these tools.
HTML Email Development using Premailer & Foundation
Many email clients ignore externally linked stylesheets, so your best bet for compatibility is pretending that it’s 1998 and writing all your styles inline. Premailer makes this process suck less by letting you write your styles as normal stylesheets, then compiling them into inline styles when the email is sent. Plus, it’s compatible with Less and Sass (through the Rails asset pipeline). This means you can keep the syntax you’re used to.
Email CSS has compatibility issues that are completely separate from the browser compatibility issues we all know and love. So, it’s nice to start out with a set of tried-and-tested style rules to prevent reinventing the wheel. Enter Foundation for Emails and Inky, a framework and templating language for writing great HTML emails.
Foundation/Inky is available as a Ruby gem, so it’s ready to drop into Rails. You can find instructions for setting up Foundation and Premailer together here.
Once you’ve installed both gems and generated an email layout and basic stylesheet with
rails g inky:install, it’s time to make sure the Rails asset pipeline plays nice with your new setup.
You have two options here:
application.cssso that Rails automagically precompiles it with your other stylesheets
- configuring the asset pipeline to compile
foundation_emailsinto its own file
I’d recommend the second option, since otherwise your email styles will be mixed in with the styles for the rest of the application.
You can find this config option in
config/initializers/assets.rb. Uncomment the line starting with
Rails.application.config.assets.precompile and add
foundation_emails.css to the array of files there.
Now your email styles will precompile into their own separate bucket and not interfere with the styling of the rest of the app.
Level Up Your Foundation Setup
Foundation’s templates and defaults are great, but you’ll probably want to use your own colors and settings. I used this settings file as a template for customizing Foundation’s default settings. Just make sure to import your settings file before
And if you want to use Inky, Foundation’s templating language, you don’t have to give up erb. To tell Rails to run your email through both Inky and erb preprocessors, name your mailer view files with the extension
.html.inky-erb (you can also use the
.inky file extension, but I prefer
.inky-erb for clarity).
Set Up Email Previews
One frustrating aspect of working on HTML emails is the need to resend the email each time you make a change. Luckily, Rails has built-in support for previewing emails using a special class in
test/mailers/previews, depending on your setup). Once you’ve followed the Rails Guide setup directions, you’ll be able to view the email you’re working on in the browser and refresh to see changes.
With this setup, building HTML emails is as straightforward as working on any web page – at least until you get to the testing stage. There you’ll need one more tool that we love: Litmus is an email testing service that lets you preview your emails in different email clients so you can uncover those pesky bugs before they reach your customers’ inboxes.
That’s it! You’re all set for some less painful HTML email development in Rails. If you’d like to try out the tools mentioned here, there’s an example app so you can see them in action.