If I were asked to identify one primary annoyance associated with a web development career path, it’d be the abundance of browser inconsistencies. From the consumer’s point of view, the web is an endless source of content, and they are given the ability explore that world. Browsers permit such exploration, but the resulting experience depends on a multitude of factors, most of them transparent to the consumer.
There’s an organization known as the World Wide Web Consortium (W3C), and their entire goal in life is to ensure the long term growth of the Internet. In accordance with this objective, the W3C took the time to define standards for the core technologies they created, such as HTML and CSS. Yet, the reality is that browser developers don’t necessarily adhere to these standards, as there’s no way to enforce their adoption. While some respect the standards, others instead travel the road of partial compliance, with proprietary technology added in. As a result, when a consumer tries to access a website, he may face a situation where it:
- loads properly, and all appears to run well.
- encounters issues when loading, but remains usable.
- encounters issues when loading, resulting in a broken interface that cannot be used.
- refuses to load, and asks the consumer to launch a supported browser.
Even with the best outcome, scenario 1, there may still be “problems” that are invisible to the user. For example, it is very possible that the source code includes browser detection logic that is used to cater the content to the consumer’s browser. If all browsers supported the standards fully, such handling would be unnecessary, and developers wouldn’t need to worry about browser-specific code. As a result, the web would speed up for all. On desktop computers, that performance gain won’t necessarily be crucial to the experience; however, keep in mind that mobile phones are increasingly web-enabled, and yet, have a fraction of the resources that desktop computers do.
Scenarios 2 and 3 suggest that the website creators may not have devoted enough time to testing with different browsers. After all, in most cases, a website should be identical regardless of what browser is being used to access it. Without such a guarantee, some users may suffer a flawed experience.
Scenario 4 is rare, but is usually encountered in a business context with highly specialized web applications. The rejection of a particular browser doesn’t necessarily mean that the standards weren’t being followed – perhaps the web application was designed to take advantage of one specific browser’s feature, one that isn’t offered elsewhere. This is not necessarily a bad thing, though I would argue that it enforces limits that would otherwise not be there. However, if we’re talking about a public website that refuses a visitor solely because they are using a specific browser, I’d consider it more of an insult to the open nature of the web.
So finally, a web developer must take browser differences into consideration. Thankfully, things are improving – for example, the infamous Internet Explorer 6 is now finally on its way out. Good news, sure – but it isn’t a magic pill. There are still plenty of browsers and browser versions out there, and like it or not, they differ. To test properly, a developer must have a way to run their code in multiple browsers, which usually requires the use of virtual machines. At least that’s how I used to do it, until I found a better approach.
Meet BrowserStack, a web-based cross-browser testing tool. How does it work? Well, it’s actually a pretty clever idea. Users are simply asked to enter the site they wish to view, the browser they want to view it with, the browser version, and the operating system. They will then be given web access to a virtual machine that has the requested webpage loaded, in the right environment and browser. Here’s an example below:
The panel on the left makes it very easy to change any of the parameters, while also offering popular debugging tools. I was initially impressed by their ability to switch between configurations with relative ease. Then, I found out that they also allow you test local content by using SSH tunnelling – now that, I found even more impressive. Add the fact that they have multiple versions of Safari, Chrome, Firefox, Internet Explorer, and Opera – and you’ve got quite a service.
For those interested in testing it out, they’re offering 30 mins of use for free, but beyond that, you’d have to look at their pricing plans. If I were still doing web development as a full time job, I’d love to have access to such a tool – the time it saves would add up quickly.