Check out a free preview of the full HTML Email Development, v2 course

The "Links & Buttons" Lesson is part of the full, HTML Email Development, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Jason gives a survey of link and button conventions in HTML emails, explains how to make links and button accessible, and explores how the same buttons and links look on different browsers and email clients.


Transcript from the "Links & Buttons" Lesson

>> Jason Rodriguez: Now we're gonna look at links and buttons in our emails. Because this is where all the work happens in email campaigns. I mentioned earlier that all of your campaigns should have some sort of goal associated with them. So it's very rare that we're sending purely informational emails.

We almost always want somebody to take some action and an email, whether that's visiting a website, opening up an app on their mobile device, going to some sort of form. We want our emails to do some work for us. And the way that happens is through links. So using hyperlinks to take them different places.

So it's very similar to the web, like the magic of the web is in the hyperlink. That's what the web is built on. And the same thing applies for email. We wanna make sure that we can get people going where they need to. A lot of that is making sure that we're using those absolute URLs so they go where they need to.

But there's a couple of things to keep in my mind when you start introducing links into your email campaign. And a lot of this is related to accessibility, which we'll dig into a lot more in a few minutes here. So one of the main things is use descriptive links.

So don't just say, click here in a link because that's not descriptive really at all. You want to describe what happens when that person clicks here. So read this article and have the the title of the article or something like that. If they're going to a help site like, get help from our experts, might be a good descriptive link.

So use descriptive links, just don't say learn more or click here for whatever that link happens to be. That'll help people out to understand what is gonna happen when they take that action. One of my biggest things that I try to encourage people to do is to embrace those link conventions.

So by default, on the web, when somebody adds a hyperlink, we get that bright blue underlined text. And that's good because it establishes that convention. Anybody that goes online, they see that bright blue text that's underlined, they know that it's a link. It's gonna do something. It'll take them someplace.

So I'm a huge proponent of embracing that convention in your emails, in your websites. So in my mind, if something's underlined, regardless of what color it happens to be, it's a link. I wouldn't rely on the strong tag or emphasis for trying to convey emphasis instead of an underline, because you could introduce that frustration for subscribers if you use an underline that's not an actual link.

So I like using blue links too, but obviously, color those how you want. You rarely want to rely just on color for denoting something's a link because we do have people that are colorblind. And they can see they don't get that functionality based just on color alone. So using those two in combination is a great practice, that's why it's convention for a reason.

And a big thing, especially when it comes to buttons, is not using images for buttons. There's a lot of reasons why you don't wanna do that. The main one being a lot of email clients will disable those images by default. So if that is your main call to action, and the user doesn't even see it, the likelihood of them taking that action and doing what you want them to do is very, very slim.

So we're gonna be looking at a couple of different approaches to buttons. There's a document called Buttons.html in the GitHub repo. It's similarly named in CodePen. That'll give you a couple of examples of how to approach building out buttons in your email. So I wanna show you an example of that, then we'll get to this exercise here.

>> Jason Rodriguez: So I'm gonna open up, well, let's let's start by looking at that link that we had in our email campaign first. So we have this link up here. That's eventually gonna be a button. So let's look at this unsubscribe link here. So right now, it's just that default blue link that we're all used to seeing down here.

So we could leave it that way. Most email clients will render it as intended. But if we want to override that, then we can use style in here. We can update the color to something like purple. I am a big fan of updating the font weight of text links to be bold so that people that do have some sort of color blindness or it's, again, not just using the color to denote that link.

So we have the underline. We have the bolded weight, so you can tell that this is a link, which is helpful, especially when we add additional tech surrounding that link. So it's very obvious that this is itself a link, and it'll perform some action when you click on it.

But the main thing we're gonna be adding to our emails are those buttons. So we, eventually, wanna make this look like a button for people to click on. But the way you do that in email is a little bit different from how you would in the web world.

So on the web side of things, traditionally, you would have like some sort of CSS class called button. You have to use things, like depending on what it is, you might make it block level or an inline block element. And then you would use things like padding and the background color and borders to style that component to look like a button.

While we can do that for certain email clients, it doesn't work across the board for a lot of email clients. So we have to rely on a couple of different techniques to get these buttons working. So let's look at what this button looks like. So up here it's just this big blue button.

It has some rounded corners. This one has a hover cell applied. These ones don't, but we can add that as needed. But these, generally, look the same. This one's a little bit wider just because of how it was coded. But these ones are all buttons. They have rounded corners, the same text, same background color.

So there's a couple of different ways to do this. The the overarching term for something like this is called a bulletproof button. It's bulletproof because they work across all these different email clients. But the the first one we're gonna look at is the traditional kind of bulletproof button.

And this was developed by a guy named Stig Morten Myre, who works for Campaign Monitor, years and years ago. And Campaign Monitor, they have a tool out there called, which was a website where you can go and generate these bulletproof buttons, which is an amazing tool. So I grabbed some code from them and update it a little bit just for styling purposes.

But you can see that this is using something called VML. So we have this conditional comment here that says, <!--(if mso)>. So if this is viewed in Microsoft Office, then I want this code down here to apply. And this is using VML, which is vector markup language, which is this really arcane, verbose, strange language that is proprietary to Microsoft Office.

It's extraordinarily hard to find good documentation for VML. I actually have a blog post on my website. I think it was called Dial M for MSO, because I had enlisted the help of one of Litmus' engineers had to open up this really old file and get this documentation working and stuff.

I think it's up on GitHub now. But it's this really arcane language that nobody outside of Stig Morten Myre fully understands. But what you're doing is using VML, this vector markup to build these objects, these shapes for your button. So for Microsoft Office, it will see this, it will render that button, and it works in Outlook.

Whereas other approaches don't necessarily always do that. They work to some extent, but will lose sizing or padding on our buttons in Outlook or other clients. So really, the most bulletproof version of a button is this original bulletproof button that you can use at is great.

It allows you to update the text of your button. You can add a background image, if you want, something like a gradient or flames on the back of your image, something like that, your background color, your font color, the button size, border color, and then the URL. And it'll just spit out this code for you, which you can copy and paste in your email.

This is super handy. I highly recommend using it because it is the most bulletproof approach to building buttons. But sometimes you don't wanna have that in there. From a maintainability perspective, it's a little bit harder to maintain to update the styling if you need to update that on a per campaign basis.

So there's a couple of other ways to add buttons in there. The next one's using a padding based approach. So this is adding padding to whatever that container for a button happens to be. So for an email that's gonna be a table. So this your first kinda introduction to a table structure for an email.

So we have this table here. We're gonna be setting a couple of attributes there to override default styling for that table. But the magic happens on this table cell for our buttons. So we have the anchor tag in here, where we set things like the font size, the font, family, the color, similar to how we do any other text.

But on the table cell we introduce some padding to provide that structure for our button. And then we use something like border radius to affect the corners and then the background color attribute on that table cell. And that will give us that second button type. So this works pretty well in things like Outlook.

We'll see these in Litmus in a second. You'll lose a lot of that padding because it doesn't respect it on a table cell, which sucks. So it doesn't look as good as something like the VML-based button. So then somebody developed this other approach, which is using borders. So instead of providing all that padding on the table cell, we add these gigantic borders to the anchor tag.

So we, again, have this boilerplate stuff, controlling the text. The border-radius is in there. We have a background-color applied. But then you can see all of these borders, we declare each individual border. And then for things like the top and the bottom, we have a certain height on those.

And then for the right and left we have even more to make it look like a button. So again, this works in different email clients but not across all of them. So then somebody went through and combined those two things to this padding plus border based button. So we can see here we have a couple of things going on.

So we're doing a little bit of styling on the table cell itself, the background color on the table cell, table itself similar to how we did it for that padding based approach. But then we're adding a border in here and then the padding on the link itself instead of the table cell.

So again, this works in some email clients, but not across all of them. So those are a couple of options for different buttons. But I think it's important to see how this actually renders across email clients to get a sense of what you should have probably use. I still recommend using, I think when it comes down to it, I would fall back, that the VML approach just because it is the most reliable across all these email clients.

But if you are worried about maintainability, customizing it, if you're using some sort of build process or like a framework to help generate your emails, then you might need to fall back to one of these other solutions that is less verbose, less arcane, easier to maintain and easier to customize on a per campaign basis.

So you can see Apple Mail is awesome. It's the greatest email client in the world, no issues there. We Outlook the VML one looks perfect. The padding base button is not too bad. We lose that border radius and a little bit of the sizing around it. And then the border base button gets even worse, and then the padding plus border base is similar.

But we don't get things like those rounded corners. We're not gonna get background images in there, and that's across the board for most of the Outlooks here. Mobile and web mail clients are pretty much the same. They render things pretty well. Yeah, so Samsung mail is the one that doesn't play nice with VML based buttons.

But you could use one of the other ones, which is kind of annoying, but it is what it is Samsung mail. When you get into like web mail clients, you'll see some randomness in here, especially when you get into European based clients like DMX or things like that.

Some of them work, some of them don't. So I would recommend using that VML based approach because it is super reliable across most email clients. If you do need to update things easily, then you might wanna fall back on that border plus batting heading based approach is pretty reliable.

But one thing to keep in mind, too, is that if you're using one of these other HTML and CSS based solutions, then when you want to add things like hovers, then it takes a little bit more work because you're overriding more of those CSS properties. The VML one is nice because if we look up at these hover states, all I'm doing is assigning a class to that button and then using that pseudo selector, the hover state and updating the background color.

So we get that hover. It's super easy to override that with that VML based approach, which is awesome. But if you're using that padding or the borders, then you're gonna have to override each of those different CSS properties, which gets super tedious. You might leave one of those out.

And you'll get something with like a red top border and green bottom or something like that, and it looks super bad. So that's why I recommend using that VML based approach. And it's super easy cuz you can rely on to just generate that code for you. You can dump it in your campaign, it works well.

The one thing that doesn't work that great is responsive stuff for that button. So if you have a long string of text in that button and you expect it to wrap on mobile devices because it's too long to fit in that container, making that responsive using the VML button is a little bit harder to do.

So that's where those other approaches are really handy too. If you are using long links or long CTAs in your buttons, you might want to use one of those other approaches. Because you can adapt the text size and stuff like that a little bit easy than what you can do for the VLM based approach.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now