In a recent article I wrote: Web browser developers are failing their most important task, I took aim at web developers for forgetting the most important task of a web browser was rendering web pages. In this article, it’s time I took a turn at web developers. 

Once upon a whimsical time, web sites were nothing more than simple HTML. Those now ancient relics were static, sometimes hard to read (remember Geocities and all those black backgrounds and red fonts?), but a lot of fun to explore. They also, for the most part, were rendered the same across the board. Even text browsers like Lynx could faithfully render those sites, minus the animated backgrounds and various images. But the text? Oh yeah, Lynx could handle it. 

So too could Netscape Navigator, Internet Explorer (IE), Opera (which actually came into being on April 10, 1995), and Mozilla (the original Firefox).

A website, was a website, was a website.

SEE: This free Linux course has trained a million people in open-source tools

But then, evolution happened. Developers grew curious and decided it was time to stretch their creative muscles. So Java and JavaScript were born and helped to make the web interesting and fancy. Websites could have interactive elements, popup and expanding menus, and so much more. This was a boon for both developers and businesses wanting to better leverage the web to attract customers.

And it worked–an online presence, via a website, began to make a huge difference and more and more businesses employed them.

But then, evolution continued to have its say.

After a while, those static sites developed into dynamic, database-driven sites with ever more complicated code. More and more programming languages and frameworks were adopted to spawn incredible features that were unheard of a decade ago. 

That evolution had a rather ugly side effect–not every browser rendered those web 2.0 sites the same. Or worse, they couldn’t render them at all. This phenomenon led to a most unwanted practice: Many web developers only bothered to test their code with Internet Explorer. At the time, it made sense as IE was, by far, the most widely used web browser on the market. Even so, the side effect of this practice was those sites would only work with one browser. 

It seemed, no matter where you pointed your non-IE browser, you’d find a site that informed you that your browser wasn’t supported.

Interestingly enough, to this day there are still sites that either only function under the Windows browser, or function poorly on non-Windows browsers. Take Spectrum Cable, for instance. When I moved, AT&T UVERSE wasn’t offered in my new location. Because of that, I had to opt for Spectrum. Very quickly I learned that the On Demand feature the company proudly proclaimed could be watched anywhere with any device, was a bit misleading. During those first few months, their web-based on demand was still using Flash and would only function properly on a browser in Windows and even then, only IE or Edge. 

After months of complaints, Spectrum finally adopted HTML5 and the service would finally and regularly function under just about any browser. But, it took complaints, and lots of them.

The same kind of experience was found with a number of Kentucky government sites. If you weren’t using IE (and in some cases and out-of-date version of the browser), it was not good.

This is a problem, but I have a solution.

Web developers should do their primary testing with open source browsers like Firefox, Brave, Chromium, GNOME Web, Mirador, etc. Why should this be the case? First, open source browsers tend to stick to standards more than their proprietary counterparts. Also, because of the very nature of open source browsers, it’s easier for those that develop for the web to come to a mutual understanding on how sites should be rendered and how the various bits and pieces should work. When something doesn’t work, it’s possible for web developers to reach out to those who create the browsers and let them know. It’s a very important back and forth that would have lasting benefits across the landscape.

That’s not all. If web developers would target open source browsers, it’s far more likely that proprietary browsers would follow suit. If a website rendered on Chromium, Firefox, and GNOME Web, chances are very good it would behave in similar fashion on Edge, Opera, Vivaldi, and Safari. 

Even if a web developer doesn’t want to make open source browsers their primary testing ground, they should at least always test their sites on all browsers, both open source, proprietary, and mobile. Let’s not forget that Android has a stranglehold on global operating system market share–that means the world is rife with Chrome. Chrome is proprietary and who knows what bits and pieces Google crams into the code for that browser? You want to make sure your site works well with Chrome? Test it with the open source version, Chromium. By doing that, you have a good shot that Chrome, Edge, and any other Chromium-based browser will work just fine with what you’ve created.

Even so, you should still test.

Ultimately, that’s what it boils down to: Testing. Don’t make the mistake so many companies and developers made in the early 2000s and focus most of your testing efforts on a single platform. Test with everything you can. Throw the kitchen sink at your code. Test open source browsers, proprietary browsers, mobile browser, lesser-known browsers, browsers across platforms because Chrome on macOS might not render the same as Chrome on Linux. When you’re done with your testing, make sure to deploy a site that renders and works the same, regardless of browser.

As you begin the testing phase of your website code, consider starting with open source browsers. You might find this expedites the process and gets you where you want to be with less headache and less work. This is especially so as you start deploying more and more web-based applications. You want your site to function properly, regardless of platform. Even if you’re tempted to use a testing service that tests your code against all of the popular browsers, consider doing your own manual testing as well. Those testing services might neglect some of the lesser-known browsers.

I realize it’s next to impossible to get a website working flawlessly, with 100% continuity, across every single browser on the market. But, if your site works with open source browsers, it’ll probably be good to go on their proprietary counterparts.  

Open Source Weekly Newsletter

You don’t want to miss our tips, tutorials, and commentary on the Linux OS and open source applications. Delivered Tuesdays

Sign up today

Also see