Thanks to our cool customers’ input, we discovered a rather startling fact – anchor links aren’t working as reliably as we originally thought in a number of popular email clients. This could be a rather major design issue if your email newsletters and templates contain a table of contents (TOC), or ‘Back to top’ -style links.
Testing a variety of anchor links
We tested the following anchor links in an email newsletter to observe how individual email clients behaved when the links were clicked:
- Name anchors –
<a href="#anchorname">...</a> ?
<a name="anchorname">...</a> - Id anchors –
<a href="#anchorname">...</a> ?
<h2 id="anchorname">...</h2> - ‘Back to top’ links –
<a href="#top">Back to top</a>
Unfortunately, our tests uncovered a bit of a mixed bag, with web, desktop and mobile email clients all treating these links variably. Here are the results:
Client (by popularity) | Name | Id | #top | Notes |
Outlook 2003 / Express | Yes | Yes | Yes | |
Windows Live Hotmail | Yes | No | Yes | |
Yahoo! Mail | Yes | Yes | Yes | |
Outlook 2007 | Info | Info | Yes | Linked element displays ~ 100px below the top of the preview pane |
iPhone | No | No | No | Anchor links disabled as of iOS 8 |
Gmail | Yes | No | No | |
Apple Mail 4 | Info | Info | Yes | Linked element displays at the bottom of the preview pane |
AOL Mail | No | No | No | Anchor links open an unrelated landing page in a new browser window |
AOL Desktop | No | No | No | Anchor links do not work |
Thunderbird | Yes | Yes | Yes | |
Android 2.3 (default client) |
No | No | No | Anchor links do not work |
Thankfully, the most popular email clients (Outlook 2003, Express, Hotmail, Yahoo! Mail, or almost 60% of market share) deal with named anchor links just fine. But then there are notable exceptions like Gmail (~ 6% market share). Our support legend Stig has the following:
“Gmail uses loads of Ajax, and uses the anchor in the URL for navigation… So in order for anchors to work (and not mess with app functionality) a string is added to the name, both in the link and the anchor.
However, it only converts <a name="...">
tags and not <h2 id="...">
. So if you’re linking to an element’s id, the link will update but the id won’t.
Also, the actual anchor behavior – jumping from one point to another – has been replaced with JavaScript, and I’ve found that Gmail will only bother to jump to an anchor element if it is outside of the view pane.”
Moving onto other quirks, AOL’s Mail and Desktop offerings refuse to do anything remotely useful with anchor links. Surprisingly, Apple Mail displays the linked element at the bottom of the preview pane (confusing!) and from one of our customers’ observations, Lotus Notes will follow anchor links, but only after a considerable delay.
Rumor had it that wrapping anchor links in <span>
tags could potentially offer a fix, but we found this to not be the case. The most reliable option is to link to <a name="...">
tags and ensure your email can be easily navigated, even without a TOC.
So, is it time to drop the use of anchor links in email? Probably not. However, you may choose to place a little less weight on featuring a prominent TOC and instead opt for designing shorter email newsletters, with a clear sense of hierarchy and incentives to open the email and/or read beyond the fold.
Many thanks to @cjcorney, @get_dave, @crumpet and others for contributing to this post. Finally, do you use anchor links in your emails? Have you experienced anything unexpected when linking to sections of your design? Let us know in the comments below.