We live in a world where different browsers run in different operating systems on different types of devices. A big part of a front end developer’s job is to keep this multitude of compatibility issues in mind so as to provide the best experience regardless of the user’s device and platform. Even with accepted standards, a website might look perfectly fine in Safari when viewed on a Mac, but be totally wrong when viewed in Firefox on the same machine.

The adoption of new CSS3 attributes makes cross compatible development even trickier. Some browsers support all of the new CSS3 attributes while others support only a selection. One rendering engine can display forms differently than another—a jQuery animation may work one way somewhere, but erratically elsewhere. These are only a few examples of factors to play into the making of a functional web page.

Our team focuses primarily on delivering email and cross compatible mailto links for desktop and mobile browser display. In this post, I’ll share some of my strategies and tips for cross-browser and mobile development.

The Problem

When creating email layouts, email clients (both web-based and standalone) add an additional layer of concerns depending on where messages are viewed by the end user. An HTML-based email might display correctly while viewed in Outlook 2007 on a PC, and slightly less so when viewed via Outlook.com on a Mac. And, that same message may be fully broken when viewed on the default client from an Android device.

The mailto link — a vital element in @Pay’s two-click, full-stack payment technology — is another element that may behave differently across browsers. Unfortunately, the standard href=”mailto:john@domain.com” code will only work as desired a fraction of them. In other places the mailto might misbehave by opening a new browser based client, or simply not function at all.

The following solutions will help ensure cross-browser compatible mailto link behavior across all environments.

The Solution

Best Practices For Email Layouts

Web based email clients are often behind in supporting modern web standards. Because attributes like floats, and even margins may not be supported in various environments, it is common practice to use table-based layouts instead of DIV layouts. This reduces conflicts from rendering HTML emails in browsers, and, along with the use of inline styles, will ensure that mailto links are clickable across the board.

Client Specific “mailtos”

Some web-based browsers (e.g. outlook.com and yahoo.com) open mailto links in the end-user’s default email client (e.g. Outlook 2007, Apple Mail, or Mozilla Thunderbird). This might prove to be problematic if that client is not configured with the email address used in the browser.

Say johndoe@yahoo.com clicks on a button with a mailto link while logged into his account in Yahoo’s browser. Instead of continuing the two-click process in yahoo.com, Outlook 2007 (installed on his computer) opens. The process of the user being taken to a different browser, with potentially different configurations, can render the button useless.

Thankfully these browsers have their own version of a mailto link in the form of an URL that will behave as desired, thus keeping the workflow within the environment. So using “http://compose.mail.yahoo.com/?to=TO&subject=SUBJECT&body=BODY” in an email being viewed in a yahoo.com client, will open a new message within yahoo.com, solving the problem.

Targeting where emails are being viewed

Now that we have a way to create custom web client mailtos, it is important to be able to display them only where applicable. There are a couple ways to do this.

• The first is simple domain targeting: When sending a button we can detect whether the domain ends with yahoo.com (or rocketmail.com or ymail.com). If so, we attach the Yahoo compose link.

• The second option is to use CSS class and ID targeting: By looking at CSS files, we can sometimes identify a specific CSS class or ID used by the browser. When the browser renders the HTML, we can use those attributes to hide and show elements (such as buttons). For example, Outlook has a unique “ExternalClass.” When this class is present we use a CSS rule to say to display the Outlook mailto and, when not present, to hide any other mailto. This also allows other clients configured with this Outlook email (such as an iPhone) to display the correct button.

Conclusion

Finding a way to use custom mailtos—along with email and CSS targeting, and using best practices in developing HTML email layouts—will offer more coverage in email clients. It will also give developers more control in making sure the expected functionality occurs: In our case that’s seamless, two-click payments for web and email.