 In 1996, I created my first website on GeoCities. I was in high school and a big fan of the band Radiohead. So I decided to make my first site a fan site for the band. While creating this, I learned a lot about HTML and who knew at that time I'd eventually make a career of this. Fast forward, 2018. And you'll notice that not much has changed when you look at the HTML that I wrote in 1996 and what you write in emails. Well, writing the markup back then was fine as the web was still very new. Today, we have better ways of doing things. So when developers are asked to create an archaic HTML email template, we often feel like we're being punished in some way. What did I do to deserve this and who did I wrong? Fortunately, there are some new options to consider. And that's what I'm here to cover in this Lightning Talk, the easy and sane way to create responsive HTML emails. A little bit about me. My name is Michael Otteri. And I work at a company called Penske Media Corporation, or PMC for short. We have some pretty cool brands like Variety, IndieWire, Deadline, Rolling Stone, and Women's Wear Daily, which is short. We call it WWD. I'm the lead engineer for our subscriptions team. I live just outside of New York City in beautiful New Jersey with my wife, Stephanie, four-year-old daughter, Emily, and our vicious cat, Lusa, which is short for Lucifer. Most of the music I listen to is about 20 years old. I like to work on my yard and garden. And I drink a lot of craft beer and recently start making hot sauce. So what does this talk have to do with WordPress? Absolutely nothing. Though this is a WordPress talk, although we are at WordCamp for publishers. So responsive HTML newsletter is probably relevant to your job and or company. For anyone that has ever crafted an HTML email newsletter template, in short, it's pretty horrible. Like I said, it reminds me a lot of the coding I did in 1996. Like using tables for layouts and nesting those tables within tables, within tables, tags like font and center, pretty common. With the emails, you have to write inline CSS to make sure you're styling the actual thing you want styled. Nothing modern is ever fully supported. And the code you write looks pretty unreadable garbage. At PMC, we decided to overhaul the Women's Wear Daily email publication called the Digital Daily. The mock that was presented to our team had a single hero followed by three rows with two articles side by side, unmobile. All the articles were stacked. For this, I wanted something that was easy to build and maintain and did a bit of research to find a framework for building this email template as well as others in the future. And yeah, this is a high fashion site. And I don't understand what that picture is. So are you not going? Well, that one. Let me turn it off and turn it on again. Sorry. Oh, here we go. I was just carrying the internet. In last of testing, we landed on Foundations for Email, which some of you might know is formerly called Inc. Really had some awesome features, including instead, you could write your CSS as SAS. It's pretty compatible with most email clients. A grid system to make the layout responsive, breaking markup components into partials for reusability. Very important feature was not stripping out AMP script, which is a scripting language of exact target, or it's the service we use to actually send our emails. And even using handlebars, which is HTML templating language, you can extend with a little JavaScript. Lastly, it's open source with the MIT license. Here's a super simple example. It's a preloaded video. The code here is what you will write and maintain. Next, you would run npm run build for production, or npm start for development. Foundation for emails has a node component for building its assets. After completion, a browser will open and navigate you to your email. And back in the editor, the distro directory has a transpiled markup that you can use in your email. This file is what's generated from the HTML emails and text that's in your SAS file. The digital daily is made up of four different lists of customers, all with subtle differences. One thing I want to do with this project was to make as many reusable elements that could be shared. Part of this was breaking it up into partials, which is just pieces of HTML markup that can be reused in many places. With that, the actual difference between the lists were just settings. Some were Booleans like whether to present a unsubscribe link or not. Others were just simple texts like an email for accepting feedback. With these settings, we could easily leverage handlebars within the markup and handle these subtle differences when building the email templates. As I mentioned before, one of the things that foundations for email needed to support was not stripping out the AMP script. In our case, it is used to parse an RSS feed to populate the articles dynamically for our send. This is done in exact target on the send. For testing, though, I created this mock feature in handlebars, which was something I just extended handlebars with, to swap out the AMP script code with test data. This has allowed me to easily test the layout that I was creating. And it's just a simple switch statement that just sees pieces of the AMP script and just uses some default setting. This is the final product, what it looks like, with desktop on the left and mobile on the right. This code was tested on litmus and rendered great, or at least satisfactory, for 19 email clients. Since using foundation for email, updating the code is a breeze. Prior to this, I would have to make the same change to four different very ugly templates that we were using before this. And now this change is in one place. And I just let foundations for email work its magic. Since this is a short talk, I can't cover nearly everything. Some other features of foundations for email is submitting to litmus testing by just running npm run litmus. You could also do some test sends with npm run mail. And you could zip up all your assets with npm run zip. For the litmus and the test sending, you need to create a configure file, config.json file. That's all very well documented in the projects readme file. One last thing I wanted to bring up was that there is a plug-in that our PMC director, our director, has been messing around with that will export something designed in Sketch and be able to import into foundation for email. It's pretty new. He just gave me a demo of it before I gave this talk. But essentially what it does is he can take a piece of the layout, export that, and then import it into foundation for email or use it right in foundation for email as a partial. Here are a couple of relevant links. First is foundation for emails project. There you'll find instructions for gang started, and the documentation is pretty good. The second link is a half hour video just showing you start to finish how to create an email. The last one is just a repo for Brian Kuberman's Sketch to the Foundation plug-in. Again, my name is Michael Autierry. If you're interested in following or contacting me, my website is MichaelAutierry.com. You can also find me at Twitter at MWaterry or MWaterry79 on Instagram. If you like craft beer, I'm on untapped as MWaterry. That's it. Thank you very much. All right. Do it up.