Browser Wars: Is One All We Need?
Browser Testing. The words hang in the air like the smell of a summer trash day in Manhattan. The sound of these words causes any front-end developer’s eyes to roll back into his/her head a little, followed by a pronounced slouch and sigh.
This doesn’t work in IE8. This doesn’t animate in Firefox. These fonts look weird in Webkit. You can’t use this; that’s experimental. Vendor prefixes; unsupported standards.
“But—” I’ll hear you say, defending your favorite platform. But when you take a step back, you realize even your beloved rendering engine has flaws. Just like a loved one, they’re not perfect; you learned to love them so much you ignore their flaws, and focus on how you can do better to them. They can do no wrong.
Actually, no—that’s not quite right. People aren’t quite that committed to a browser. Browsers change popularity over time. Heck, the Browser Wars are still raging, some may say. Still, many people can get as fanatical about a browser as they can their favorite NFL team. Yeah—that’s good. Sports teams are closer to what I’m talking about.
But stepping back further, as a front-end developer, I ask: does browser testing even make sense? Why in the world would we want to test browsers if we didn’t have to?
The River
Back from the time Windows XP was released in 2001 until Firefox started picking up steam in 2008, there was really only “one” browser: Internet Explorer. You designed websites for Internet Explorer. You tested websites in Internet Explorer. You decided what was and wasn’t possible based on… Internet Explorer.
What was the problem here?
The problem, as designers soon noticed, was that you couldn’t design for web. At least, not like you could with print. Embedded fonts? Forget about it. Images that weren’t rectangles? Nope. CSS styling? JavaScript? Well, kinda, but don’t get your hopes up. And don’t even get started on security.
There was a bit of a standstill here in improvement. Sure, it’s the internet, and it was still developing at an astronomically fast pace. But it wasn’t until Firefox stole some of IE’s thunder that the rains came and the flood gates of competition burst forth, releasing a river of new ideas and capabilities. Both users and developers began to see the light about what web standards could actually accomplish.
Before we knew it, we were doing inconceivably crazy things! Things like letting the browser validate forms. Letting CSS handle hover images. Oh, and my personal favorite: ditching <table>s. It was a Renaissance of sorts, and a new beginning to how we viewed the web. We even came up with a stupid name to show our excitement: Web 2.0 (man, were we young back then!).
The Wetlands
Sounds like a dream, right? Well, sure. I’m amazed everyday at the things that are happening on the web. And it only keeps getting better! Web has almost caught up to print in terms of design, limited only by things like threading text (continuing content from one container to another) and hanging punctuation (obviously, I’m omitting the interactive parts of the web that print can’t physically obtain).
Writing code that works for every browser is hard. And when impossible, writing browser-specific fixes is time-consuming.
But in spite of this veritable cornucopia of web-goodery, there exists the opposite edge of the sword: browser testing. No longer in the droughts of monopolistic browser reign, the rivers of openness have come, only to flood everything in sight. The nature of browsers now is more like an endless bog of vendor-specific rules.
Isn’t that a bit dramatic? I mean, there are only, like, 4 main browsers†.
True, and it’s worth noting that out of Chrome, Firefox, Internet Explorer, and Safari, two of them use webkit as their rendering engine. But still, writing code that works for all four is hard. And when impossible, writing browser-specific fixes is time-consuming.
† I would’ve said Opera if it hadn’t been losing so much market share lately, and if it would have not switched to Webkit.
An example of time-consuming: I was animating an SVG the other day. I had embedded the SVG code onto the page, and I was only animating certain <path>s within the SVG. Webkit let me rotate those paths along the edge. Gecko (Firefox) did not, and I had to split up the SVG into two files and re-code the animation. So, end of the world? Nope. But was it necessary for both to support SVG but have each cherry-pick implementation? I feel like it could be better.
The Lightning
So, to answer the question you thought I’d abandoned in my rant: Why do we need more than one browser if we have to test? Is Webkit all we need? I will say this: it is the competitive nature of having different browsers that has led us to develop the web at the fastest pace.
Put another way, we’re all trying to solve a problem: what is the best way to share this interactive experience we call “the web”? So far, things like HTML, CSS, and JavaScript have evolved organically as great solutions to this problem. Could there be more solutions? I would most definitely hope there would be. But for now, focusing on these simple problems—what they even are, and how they can be more interactive, has proven quite difficult. And we’ve only been working at this for a couple decades! Imagine how much farther we have to go!
If we look at it in this way: trying to solve a problem by hitting it from different angles, we’re sure to come up with a much better solution to our problem than if we approach it from one side. So if we can get there faster by having more examples of what a browser could be, then I say, yeah. It is totally worth browser testing.
I’ll leave you with this, and this is the principle of attacking a problem from multiple angles at once: lightning. The most efficient exchange of electrons between differences in charge between the sky and the ground involve multiple—thousands of exchanges trying to find the quickest connection between earth and sky.
The fastest, most efficient route wins. Eventually.