Then I realized that Opera’s dev tools don’t include a screen ruler, a tool I use all the time through Chrome’s Pendule extension.  No problem, I thought – Opera has its own extensions, called “widgets.” Except, they don’t seem to work – I found a screen ruler widget in less than a minute, but it refused to properly install, and once it was done I still couldn’t actually run it.

Annoyed, I went on to find further annoyances. Amazon.com doesn’t allow Opera to use the “Look Inside” feature. Opera’s aggressive pop-up blocking led to sites that rely heavily on pop-ups becoming unusable, even when pop-up blocking was turned off. Some sites refuse to serve content to Opera at all, putting up a message that only Internet Explorer, Safari, and Firefox are supported. Opera does feature a handy user-agent switcher to trick these sites into thinking it’s Firefox, but that actually leads to further problems. Google, for example, actually does the right thing when it comes to Opera support, but GMail became a scrambled mess with my user-agent string set to Firefox.

So, while the original browser wars are well behind us, and while standards-based development has easily become the norm, we’re not out of the woods yet. The new battleground is the established trio of renderers – Trident, Gecko, and WebKit – vs. everyone else. While these three represent the vast majority of browsers in the world, things were not always this way, and site developers would do well to code to the standards and not to the popular rendering engines of the day. If your site really does have some advanced features, test for browser capabilities, not for the specific browser in use. That way, you’ll avoid what is surely the most embarrassing gaffe I’ve come across while using Opera – disney.com doesn’t recognize Opera, and so it assumes that you’re using an iPhone!

[If you're wondering what browser I actually use after all that ranting, the answer is Opera. I've really come to like it, and when an individual site doesn't work right, it's fast and easy to fire up Chrome, or even Firefox for those truly annoying sites. Don't even get me started on government sites that only open in Internet Explorer.]

But Firefox has always had its issues. The great Firefox memory hole has consistently shrunk with each new release, but it still exists, bringing the browser to a grinding halt with disturbing regularity. Page rendering speeds have improved over the years, but they haven’t necessarily kept pace with the increasing complexity of application-weight websites.

I want a browser that gets out of my way. Pages should load quickly and render perfectly, there shouldn’t be any delays switching between tabs, and the browser should have useful tools for analyzing and inspecting site source code – all while remaining stable and using a minimum of operating system resources.

So, lately I’ve been doing all of my browsing (and development) with Google Chrome. I started using Chrome last year on Windows out of sheer curiosity, but quickly dropped it and returned to Firefox. But Chrome, too, has been growing and evolving, along with the WebKit engine that it runs on. WebKit has the best CSS3 support of any browser, letting me test out all the newest techniques without waiting for Firefox to add support. Chrome is now quite solid, even in its developer releases, and incredibly fast. And while there are times that I miss the Firebug extension for Firefox, WebKit’s “Inspect Element” pane has evolved into a quite capable replacement for my purposes, especially when combined with new Chrome extensions like Pendule.

Am I done with Firefox? Certainly not. Firefox is the world’s second most popular browser, and for good reason; Firefox dramatically raised the bar for what users could expect from a web browser, and it continues to improve through regular releases year after year. It is still the browser that I would recommend to anyone for general use, and I will continue to test every site I create in Firefox (along with Safari, Opera, and Internet Explorer). When using Chrome, I miss the ability to search Google, Wikipedia, and more from a tiny search box in the upper right (Update: I just needed to “Edit Search Engines“), and Firefox’s add-ons feel a lot more robust than Chrome’s extensions.

But at this time, for my own use, Chrome has supplanted Firefox.

(P.S. – I’m still looking forward to the impending Firefox 3.6. I may be switching back if I’m suitably impressed. It’s so wonderful to live in a time where we have real competition between browser makers!)

Image from Google Blogoscoped

The answer is a set of three related ideas: browser grading, progressive enhancement, and graceful degradation. Taken together, these three ideas help designers come to terms with their utter impotence in the face of the Web, and create sites that look beautiful on any device that views them, even screen readers.

Start with Semantic HTML

Before we get started, it’s important to point out that all of these techniques ultimately come back to using semantic HTML. If the browser can’t make any sense of what your content actually means, your job as a designer is going to become much, much harder. If you’re not sure what I’m talking about, be sure to check out my earlier article on the topic.

The Old Browser Problem

If there’s one tenet of the Web that will always remain true, it’s that old browsers take a long time to die. Microsoft, Mozilla, and Apple come out with new browsers at least once a year, each better than the last, each encouraging users of the existing version of their browser to upgrade. Yet, generally speaking, people tend to upgrade their browser only when they buy a new computer – because it comes with a new browser pre-installed. Witness, for example, Internet Explorer 6.

IE6 was a bold new advance when it came out with Windows XP. Microsoft had won the “browser war” with Netscape, and for the first time since the start of the browser wars, sites could be built that more or less worked the same everywhere. Then, as designers started adopting CSS to do all of a site’s presentation (as opposed to the older, table-based approach), IE6′s flaws started to appear. IE6 had inherited a bunch of strange behaviors from IE5.5 before it, and designers got upset. Firefox appeared from nowhere and started gaining market share; Apple started making the Safari browser to replace IE for Mac; Google developed Chrome off of the same WebKit codebase; there was massive growth everywhere in the browser landscape. Microsoft realized that it was losing the Web it had worked so hard to lock down, and so it created IE7, and made IE7 a “High Priority” Windows update – meaning that users who were receiving automatic updates would get the new version automatically. The following year, Microsoft produced IE8, with even more improvements, and again it was to be made a “High Priority” update. Now that IE8 has been released, and IE7 has been around for over a year, one would expect that no one would still use IE6. But you would be wrong. IE6 is still used by about 40% of Internet users, and it’s still the most popular browser in the world. IE6 will only truly die when developers and designers around the world decide to piss off those 40% of users and stop making sites that work in it.

Why? Because users don’t like to upgrade their software, because Microsoft (and other companies as well) has too often released software updates that break more than they fix. So users turn off automatic updates, and stop updating at all for good measure. No updates means no new browsers, which means more headaches for designers.

Browser Grading

Enter browser grading. The folks at Yahoo had the smart idea that old browsers would be around forever, and you couldn’t really expect to support every browser ever made going forward. There would have to be a cutoff point where Yahoo could say “So sorry” to a user with an ancient browser, but that line in the sand would have to be drawn very carefully so as not to drive away potential customers just because of their browser. So they made a list of what they considered “A-grade” browsers, which they would do everything in their power to support, along with a “C-grade” browser list that should expressly be given the most toned-down, simple version of the site possible. Every other browser is treated as “sink-or-swim” – the browser will be given the “A-grade” version of the site, but if it doesn’t look right, that’s the browser’s fault, not Yahoo’s. As long as your site works in all of the A-grade browsers, you as a designer don’t need to worry about testing your site on every combination of browser and hardware in the world. Obviously, as new operating systems and new browser versions come out, Yahoo revisits their browser gradings to keep everything up-to-date.

Some designers, upon hearing about graded browser support, think about the “C-grade” category and say “This sounds like more work – I have to make two versions of every page now?” The answer is no, and the reason why is semantic HTML. Just serve your HTML page with no CSS or JavaScript to the C-grade browsers. If your site has been properly written with progressive enhancement and graceful degradation, the C-grade browsers will be able to use your site just fine. It won’t look pretty, and it won’t have any of the behavior that JavaScript provides, but it will be functional enough to use. (HTML5 may throw a bit of a wrench into this idea, but we’ve all got at least ten years before it becomes a final standard.)

Semantic HTML, and the concepts of progressive enhancement and graceful degradation, demand an entirely different way of looking at how sites are built. Again, please be sure to read my earlier article for an introduction to semantic HTML and its benefits. Because PE and GD are such a large topic, I’m going to close here for today. Just remember that no matter how many browsers are created, or how many devices your sites are viewed on, it’s OK to make your own dividing line of which browsers you will fully support and which browsers will get the “My Site for Dummies” experience. As long as you’re not cutting off users of older browser entirely, the experience of the “A-grade” site might just persuade your users to upgrade to a browser that didn’t come out when the Hamster Dance page was popular.