When the web was young, a 56k connection was fast, CSS was new, and Flash was but a glint in Macromedia’s eye, there was a phrase that graced half of all splash screens: Best viewed in IE6. You see, back in the early 00s, the web was a lot less competitive. It was perfectly possible to ignore 40% of your users and still turn a profit. In fact, given the expense of maintaining a different codebase for every browser, it was often financially inviable to build for more than a single browser. [pullquote]front-end code still renders very differently in different browsers[/pullquote] Over the years, the web became far more competitive, and developers serious about building profitable sites looked for ways to code sites for a wider audience; web standards began to emerge. It’s difficult to envisage how we would have coped with the exponential growth of the mobile web without the backbone of web standards. However, web standards have fed the misconception that browsers display code consistently; The truth is that front-end code still renders very differently in different browsers.
Why Aren’t Browsers Consistent?
Despite near-industry wide commitment to web standards, browsers still render web pages very differently. There are a few reasons for this:
Evolving Web Standards
Releasing a new feature of CSS3, HTML5, and especially ECMAScript takes a long time. From initial proposal to recommendation there are hundreds of revisions and amendments. The problem is that early-adopters frequently find themselves going to production with an out-dated version of the specification. Take CSS’s Flexbox, which enjoys excellent support across all major browsers, officially, even IE; Unfortunately Microsoft coded in an older version of the specification and anyone who still needs to support IE will find they need to run backwards compatible code.
Scope for Interpretation
Web standards deliberately leave a lot of scope for interpretation. There are numerous properties that are rendered differently because the specification refers to a default setting, without defining that default. While is may be frustrating, there’s a solid reason for this flexibility: Compare a select element on macOS’s Safari browser, with the same select on iOS’ Safari browser; Not only is the select styled differently — as it would be on Edge, or Chrome — it’s an entirely different UI element!
Bugs, Legacy Code, and Hacks
Like all coders, the engineers that build browsers aren’t perfect. They work with the same pressures, deadlines, and marketing departments that the rest of us contend with. The result is patchy code that’s often buggy, especially in edge cases. There’s a classic browser bug that only appears in Chrome: Input fields with placeholder text, rotated 180 degrees on the Y axis, unexpectedly override the backface-visibility property. The reason? Somewhere down the line, someone working on Chrome’s engine (probably in an effort to speed up rendering) chose to toggle visibility instead of detecting the current current state.
Designing for Inconsistency
We’re lucky that the browser wars are far behind us. But for the reasons listed above, developers must embrace the fact that in subtle, but unmistakable ways, browsers are inconsistent. Naturally, websites don’t need to look the same on every browser and device — one of the reasons that there are multiple browsers is that different users have different preferences — but a site must function, and be familiar (especially across mobile and desktop) however the user chooses to access it. One way of testing sites is to buy 10 – 20 computers, and 20 – 30 mobile devices, install multiple browsers onto each one, and painstakingly test on each one, every time you tweak your code. The smarter way is to use a cross-browser testing app like Lambdatest.
Designing with Lambdatest
Lambdatest is a SaaS that enables testing on a huge range of devices from the comfort of your development machine. You don’t need any special equipment, just log into the site for a range of different testing options:
Cross Browser Testing
Lambdatest lets you perform live, and interactive testing across over 2000 different browsers installed on numerous devices. These aren’t simulators, they’re real browser instances that you access remotely. Through an intuitive UI you can navigate through the top browsers on macOS, iOS, Windows, and Android. Compare inconsistencies, and even use the screenshot and video options to record problem areas as buggy. This manual approach to testing is flexible, and ideal for checking individual components of your build. It’s great for checking that bug-fixes are fully resolved. But for really comprehensive testing a manual test is too labor intensive, for that Lambdatest provides automated testing.
Where Lambdatest really comes into its own is with automated testing. Automation allows you to test your design against up to 2000+ browser implementations. Simply select your OS and the browsers you want to test on, run the automated screenshot process, and review the results in your dashboard. For ongoing testing during development you probably only want to compare your target browsers, but for any build milestones it’s worth testing as comprehensively as possible. Using the restful API you can automate logs, test metadata, and hunt down bugs at world-record pace, saving you time, money, and reputation.
As well as manual testing, and automation, Lambdatest also integrates with a wide range of third-party tools including Jira, GitLab, and Trello. This means you can test your site thoroughly, without ever leaving the safety of your existing workflow. There are also a Chrome extension, and a WordPress plugin. Both allow you to take a screenshot of your site, on 2000+ browsers, with a single click either in your browser, or in the WordPress admin panel.
Smart Comparison Testing
Perhaps the feature we like the best, is the Smart UI testing feature. What this innovative feature does is automatically detect when something’s gone wrong. It’s great for designers and developers working remotely, who don’t have a colleague’s fresh pair of eyes to borrow to check changes. Simply pull up one of the screenshots from Lambdatest’s automated testing to use as a baseline, then run the Smart Comparison Testing tool, and it will flag up any notable differences. It’s a fantastic tool for when you’re rapidly fixing bugs, and need to double-check your fix didn’t break something else. Given that the vast majority of bugs in code are introduced when hacking around browser inconsistencies, it’s always wise to check that the solutions you introduce aren’t bringing with them a host of all-new problems.
Why Choose Lambdatest
The number of different browsers and devices you need to test on, just to cover the more popular brands on the market, is prohibitively expensive for most teams. Not to mention the constant demand to keep updating. Lambdatest eliminates this cost and brings comprehensive testing within reach of every web professional. Without the cross-browser testing that Lambdatest enables, it’s all but impossible to design and build a modern website. What we love about Lambdatest is that it’s a flexible way to work comprehensive and reliable testing into your existing workflow. There are other apps that allow you to test across different browsers, but they typically force a new way of working on you, Lambdatest doesn’t. You can try Lambdatest for free by taking advantage of the freemium plan that gives you 6 x 10 minutes of testing, 10 sessions of screenshots, and 10 sessions of responsive tests. Once you’re happy that Lambdatest is right for you and your team, plans start at just $15/month. [– This is a sponsored post on behalf of Lambdatest –]