The idea behind cross-browser compatibility is simple: ensure your website looks the same across all browsers. Seems common sense to be a desired outcome, right? Still, instead of tossing the phrase around when it comes debugging time, it’s important to understand the full meaning behind it.
Why are they different? What do these differences mean?
And more importantly: How do you test compatibility anyway?
Not All Browsers are Equal
When new standards or features come out, not every browser supports it immediately or at the same time. As a result of differences in how the browser is coded, they may interpret differently — or even ignore — how some lines of CSS or javascript are displayed.
This extends beyond just webpages, too. Email clients, such as gmail or Outlook, also choose to interpret CSS differently. In this case, they are more selective in choosing what to allow or ignore as a result of compatibility with their software and to protect from potential security issues.
However, they’re important to know when creating an email newsletter; using the wrong CSS property can result in VERY different-looking emails.
Different Result, Different Experiences
So what does this mean? Let’s consider the email newsletter again. Let’s say you haven’t tested across different clients and inadvertently rely on a CSS property that Outlook doesn’t support. The email is sent to hundreds of people, all using various email providers and clients. Soon you receive a message that the amazing newsletter design is not looking so amazing.
In many cases, this might seem a minor inconvenience and things are only slightly different — not enough to be noticed by most. However, there are some instances in which the newsletter may come out looking disastrously wrong.
For example, if you put in a background image with text on it, you have to do a lot more extra legwork to get it to work across all clients. In Outlook, which discourages background images, it will more than likely not display at all, leaving an awkward empty space and no information for your customers.
This email looks pretty good on most. But wait — notice Yahoo! Mail? The body background color isn’t loading as white, and as a result the body text is unreadable. That’s a major issue! (image source: 5 Useful Cross-Browser Testing Tools and Services)
At best, it’s unattractive. At worst, it’s useless.
Either way, you’ve sent out an unprofessional email to the masses. While most people will not take time to complain, they will delete it without a second thought or even unsubscribe altogether.
Sound intimidating? Take a chance to read these two articles, ” Design and Build Email Newsletters Without Losing Your Mind (And Soul)” and ” Email Newsletter Design: Guidelines and Examples” . They’ll help; trust me.
Continuing on: What about webpages?
When testing browsers, you’ll want to consider different operating system, screen resolution, and browser version.
Don’t forget to vary the combinations! (Source: CrossBrowserTesting)
Generally speaking, the potential differences here are often not as drastic. (Isn’t that a relief? Especially for all the developers out there who sighed a breath of relief over the discontinuation of Internet Explorer 6.) That said, you still need to check your site…just in case.
Cover all your bases too and test your site among different scenarios. If the user has javascript blocked, for example, do features on your site become unusable? Does the site scale correctly across all resolutions?
If you’re using newer CSS or Javascript code, is there a safe fallback on older versions? Make sure there’s always a safe (and good-looking) fallback when using things that are new or that a user or device may potentially block.
The Impact of Differences
So what is the result of these different experiences we potentially create? I’m sure you’re starting to get the picture now. These differences will shift their perception, for better or worse. The last thing you want to do is make it easy for a customer to have a bad experience with your brand.
This is why the goal of cross-browser compatibility is to create consistency. They don’t necessarily have to look the same everywhere — for instance, webpages on mobile should be optimized for that device and different from the desktop version for that purpose — but the experience needs to be the same. It should be functional, helpful, and designed with intention.
The goal of good design is to guide customers to what they need in the easiest and smoothest way possible. Even something that might seem a small bug, like a slightly misaligned menu, can cause problems. You think, ” Hey, on desktop it still looks pretty good.”
But what if that misaligned menu is now harder to touch on a mobile device? Suddenly that small problem is a big problem.
You can’t control how every person will come across your site or email, but you can control the result of each of these outcomes. Don’t let any customer slip away over design issues that could have been prevented.
How to Check Your Compatibility
You’re probably wondering now how to possibly check all these things. Do you buy every device for testing, or get your hands on every possible email client?! Fortunately, we can do testing with much easier means.
BrowserStack
BrowserStack lets you view a website on different devices and browsers virtually across their servers. It even lets you choose a specific version of each browser! While there are options that exist that can give you a screenshot of your site across many devices and browsers, browsing the experience in real-time is hard to beat and much more insightful — not to mention helpful for debugging when you can also use the browser’s inspector tools when you find something wrong!
Litmus
Litmus specializes in emails, helping you to see how they look in various email clients and pointing out any lines of code you used that might cause trouble. The additional checklists and analytics help make sure your emails are top-notch before they hit any inboxes. Its insight simply can’t be beat!
Although these are the two I recommend, there are alternative options you can look into as well. Alternatives to BrowserStack include Equafy, Browserling, SauceLabs, and BrowserShots. If Litmus is out of your budget, consider Email On Acid, Preview My Email, or MailChimp’s Inbox Inspector.
At the very minimum, run your email newsletter code through Premailer or Torchbox’s Email Inline Styler. Both of these will ensure your code is tip-top shape and let you know if any style properties aren’t compatible with the most known email clients. Best of all, both of those are free! (So now you have no excuse not to send great emails!)
Time to get compatible!
As they say, ” knowledge is power.” Now that you know what to look for, where, and why you’re looking, you’ll be in much better shape to bring your business’ best foot forward with every webpage and email you publish.
You’re doing a huge service to your brand and customers when you’re able to meet them equally across every browser, device and version.
