Lately, I’ve been on a bit of a rampage on the subject of cross-browser compatibility, becoming especially incensed by prominent websites and web 2.0 applications that don’t work in Apple’s Safari browser. I know some of you are sympathetic, but think I should just be pleased that these sites work in Mozilla Firefox, which runs on all platforms known to man (or woman (or Martian)).

Yes, it’s definitely worth celebrating that Firefox has broken through the stranglehold with which Microsoft’s Internet Explorer had gripped the industry for so long, providing not just a viable alternative, but a demonstrably superior web browsing experience. Firefox is the descendent of Netscape Navigator that’s finally returned to beat off the IE interloper, and it has a huge following among developers as well as users.

But there are a number of other excellent web browsers that get shortchanged when a company is testing its site or application in only IE and Firefox. For as good as Firefox is, it’s not the best in all aspects of web browsing, either on Windows or the Mac. This article highlights a few facts about the browser market and points to some really useful features found in non-IE, non-Mozilla browsers that explain why users remain devoted to them and, like me, continue to raise a stink when they are ignored. The other two browsers I use pretty much every day, in addition to Firefox, are Opera and Safari.

A Rapidly Changing Browser Market

Everyone who’s been paying attention to the browser market knows that the times they are a-changin’ there… IE’s share is slowly being whittled down by two rising stars: Firefox and Safari. The accompanying chart shows the change in shares from October 2004 (shortly after Firefox 1.0 was released) to April 2006, and though the drop in IE share looks small, it’s actually almost 10 full percentage points. Likewise, though the increase in Safari’s share looks small, it’s actually more than doubled over this time period–from less than 1.5 percent to over 3.0 percent. Firefox has gotten the most attention, and deservedly so… it’s gone from about 2.5 percent to over 10 percent since October 2004–a quadrupling! Opera, which just went “free” last fall, remains at only about 0.5 percentage point, although in interpreting these data it’s important to understand that Opera, in particular, is able to masquerade as other browsers, and it’s not clear that these data (which come from Net Applications) are able to distinguish real IE from fake IE.

Safari

Safari’s share is particularly interesting because its 3.3-percentage-point share in April 2006 consists entirely of Mac OS X users. That’s because, for now at least, Safari only runs on that operating system. However, in the months since Apple open-sourced its KHTML-forked WebKit core last summer, a great deal of activity has occurred in the Safari nightly builds, and recently the team made clear they are working on versions of WebKit that will run on other operating systems. Already, Konqueror, the original KHTML browser, runs on Linux, but it has an unmeasurably small share of the market at this point. WebKit itself has already been ported to Linux, though the port is still in the alpha stage.

When you realize that the Mac market share in April 2006 stands at 4.3 percent, Safari is apparently the browser of choice of over 75% of Mac users. There are good reasons for that, though like their Windows counterparts, many Mac users browse with whatever web browser is installed on their system. Until Microsoft stopped producing IE for the Mac, Apple included IE as well as Safari with Mac OS X. Now, however, Safari is it unless you download another browser.

Regardless of why it’s favored, developers need to understand that when they fail to include Safari in their compatibility testing, they are basically thumbing their nose at Mac users. In my world, that’s not just a nasty thing to do, it’s also illegal. After all, it’s essentially the same as putting a sign on your shop window that says “No Jews served,” or “No Illegal Immigrants served,” etc. The web belongs to everyone, and if you’re going to set up shop there, you should have to do it in a way that doesn’t discriminate against a particular group. Mac users browse with Safari, so if you’re a developer on a Windows system, you need to find a way to test your code with Safari.

By the way, developing for Safari isn’t as hard as it’s made out to be. In my latest update to this heavily JavaScript/CSS/Ajax-driven website experiment, there were only one or two items that worked differently in Safari than in Firefox or Opera. The only hard browser to support was IE. And I do mean hard, as in forget it hard. I probably spent three full days just getting the site to its current level of support for IE, and even then I had to dumb down certain features to get it to work.

Why do developers think supporting Safari is hard? For one thing, they have no way to test their code. Like Opera, Safari used to be pretty quirky when it comes to JavaScript support, and they remember that. But mostly, I think, it’s because they’re using Microsoft development tools to build their code. The problem is, if you use Microsoft tools, you inadvertently produce non-standard JavaScript and CSS code that won’t work in other browsers. Microsoft knows this, and in fact does this in all of its tools as a way to make cross-platform development more difficult than it should be. (Remember what they did with Java, after all!) So if you’re developing for the web and you want to be standards-complaint, definitely avoid Microsoft tools (whether they’re free or not).

It’s worth noting that not only has the Safari market share doubled in the last 18 months, the Mac OS X share has increased by one-third. If I were a betting man, I’d put down a big wager that the Mac market share will continue to grow for the next year or two at least.

Opera

So, if Safari is ignored by developers today, does it surprise anyone that Opera is, too? After all, the Opera market share isn’t growing at all, and at 0.6 percent in April, it’s almost below the radar screen. Yet Opera is by many measures the best browser available, and the latest versions are free, with no annoying ads to try to get you to pay up. Both Opera’s status as a free browser, and its status as one of the most standards-compliant browsers are fairly new. Opera has been around for so long that many of the nerds who would be inclined to try it out against IE or Netscape still haven’t gotten their head around the fact that it’s worth another try in 2006. When that happens, I suspect Opera’s share will start to rise. (Readers interested in standards compliance, as measured by the ACID2 test, might like to visit this list showing the current status of compliance in all the major browsers.

As I mentioned before, Opera can easily masquerade as other browsers. In a world where so many legacy websites are still around that work best (or only) in IE, it’s most likely that any masquerading done would be with an IE mask. Once you start masquerading, you may not remember to set Opera back. That happened to me just yesterday. I was coding a notice of apology aimed at IE users and was surprised when I kept getting it in Opera. Although I had Opera’s overall preference set to browse as itself, I had at one point set a site-specific preference to masquerade as IE on Musings from Mars, and never changed it back. (Speaking of compatibility, the WebKit team has compiled a “Compatibility Hit List” of the major websites that Safari fails to render correctly, inviting users to participate in identifying and fixing the errant WebKit code.)

One final point about Opera is that its user base is overwhelmingly non-U.S. in origin. When I look at the usage statistics Google Analytics provides me for both this site and my commercial website, Classic 45’s, Opera is the only browser where the percentage of U.S. visitors is significantly under 50%. Opera has a large and enthusiastic community of users and developers, and deserves support because it is now just as standards-compliant, if not more so, than Firefox. Just because many of its users are European doesn’t mean you should ignore them.

Performance Data

One of the metrics of web browsing that’s relatively easy to measure is speed. There are any number of ways to measure speed, but two that are particularly relevant for developers building Web 2.0 sites and apps are CSS and JavaScript performance. It’s when you look at the data for these two components of a website that you realize why geek types avoid Internet Explorer like the plague. Not only is it quirky and require a great deal of special handling in building code, but it’s slow as well.

Mark Wilton-Jones (”Tarquin”) maintains the incredibly useful and informative “How To Create” website, which I referenced as a source of DHTML code in an earlier article. One of the sets of data he maintains is a comprehensive suite of browser speed measures. For the JavaScript measures, the author uses the BenchJS test. If you haven’t used BenchJS yet to test JavaScript performance in your browser of choice, I encourage you to do so. Not only can you get a useful measure, you can compare it with the results that other users are currently getting.

What Tarquin’s measures show is that, if speed were all we cared about in a browser, everyone would be using Opera. Seriously… it tops the list in nearly every measure on the site. I’m going to focus here on just the CSS and JavaScript measures, and I’ll try to go over these quickly because most people, I find, are easily bored by statistics. (By the way, I’m going to exclude historical browsers and only report on the latest versions from the major players.)

CSS Rendering Speed

Here’s the way the browsers shake out on the Windows platform (data measured in seconds):

1. Opera 9 (beta) (0.92)
2. Opera 8 (0.92)
3. IE 6 (1.32)
4. Netscape 8 (1.43)
5. Mozilla 1.8 (1.49)
6. Firefox 1.5 (1.52)
7. IE 7 (beta) (1.58)

Opera clearly leads the pack in this measure, and after you jump from Opera down to IE 6, the rest of the browsers are all in a pretty tight range. So, aside from Opera’s clear lead in CSS rendering on Windows, all the browsers perform well with no clear reason to prefer one over another.

Here’s the picture on Mac OS X (again, in seconds):

1. Safari 2 (0.35)
2. OmniWeb 5.1 (1.41)
3. Opera 9 (beta) (1.57)
4. Opera 8 (1.71)
5. Mozilla 1.8 (2.88)
6. Firefox 1.5 (3.04)
7. Camino 0.8 (3.08)

Wow! Here, you can see that Safari is way ahead of the pack, and in fact is the CSS Rendering King with by far the fastest performance on both platforms. So, unlike IE, Mac users actually have a performance reasons to choose Safari over other browsers. OmniWeb uses the WebKit engine at its core, but clearly uses something else as well, which may explain why it’s so slow at JavaScript parsing (as we’ll see). Opera is the next-fastest browser, followed by the Mozilla family, the members of which are significantly slower on Mac OS X than on Windows.

JavaScript Parsing Speed

Take a look at the way the Windows browsers perform in parsing JavaScript (in seconds):

1. Opera 9 (beta) (13)
2. Opera 8 (13)
3. Firefox 1.5 (21)
4. Mozilla 1.8 (23)
5. Netscape 8 (28)
6. IE 7 (beta) (40)
7. IE 6 (60)

Woah! No wonder Windows users are switching to Firefox when their native browser is the slowest of the pack by a country mile! IE 7 appears to be improving the situation somewhat, but is still only about half as fast as the Mozilla family of browsers. Opera again tops the list on Windows.

On the Mac, the browsers are much closer together in JavaScript performance, with one big outlier (again, in seconds):

1. Opera 9 (beta) (22)
2. Opera 8 (22)
3. Safari 2 (27)
4. Mozilla 1.8 (38)
5. Firefox 1.5 (40)
6. Camino 0.8 (48)
7. OmniWeb 5.1 (121)

Here’s where Opera really shines, performance-wise, on the Mac. (Actually, Opera also tops several other Mac OS X performance measures from Tarquin’s website, though Safari is usually not far behind.) But the difference between Opera and Safari is pretty close in JavaScript speed. By contrast, Firefox is only half as fast as Opera on the Mac, and again, only half as fast as its PC equivalent. It’s in perceptions and measurements like this that Mac users feel somewhat short-changed by Mozilla’s Gecko engine, which apparently is optimized for performance on Windows, but not on the Mac. Since IE has been the focus of their competition, this is understandable, and clearly they have proven that Firefox is a much better browser than IE on Windows. But it’s not there yet, performance-wise, on the Mac. OmniWeb’s back-of-the-pack status in JavaScript performance is odd, and I suppose someone from the Omni Group could explain what’s going on there. They must be using a different JavaScript run-time engine than WebKit (though the Omni Group website says otherwise), though they use WebKit for other page rendering tasks. I ran OmniWeb myself through the BenchJS tests, and sure enough, OmniWeb simply sucks at certain types of JavaScript-powered manipulations.

And now for the pretty pictures! The charts below are the same data I just described, rendered through Apple’s Pages software into lovely visuals. (All data courtesy of the How To Create website.)

A Few Favorite Features

My opinion of the browser market right now is that there are three excellent web clients available to users, with other excellent variations thereof, and there’s one web client that’s pretty bad. Fortunately for Mac OS X users, there are no real clunkers at the moment. Even OmniWeb, which has such miserable JavaScript performance, has many other unique virtues that presumably entice its users to shell out $30 to use it without annoying registration reminders. I have personally never been so enticed, but I came close shortly before Apple released the first beta version of Safari in January 2003.

For those who like Safari, there are a couple of top-notch, full-featured WebKit-based browsers available, both for free, and dozens of other products that use WebKit as a web rendering engine for part of their functionality. (For a full list of every such product, check out Darrel Knutson’s comprehensive list of every Mac web browser known.) Both of these browsers, interestingly, are from Japanese developers, and both are worth checking out:

• Shiira
  

  Shiira is a web browser based on WebKit and written in Cocoa. The goal of the Shiira Project is to create a browser that is better and more useful than Safari. All source code used in this software is publicly available.



• Sunrise Browser
  

  Light & fast. The open-source browser for web developers.

Mac users who like Firefox but would prefer a browser that uses Mac OS X’s native Cocoa framework have an excellent option in Camino, a side project of the Mozilla group. Before Tiger (Mac OS X 10.4), I had given up Safari completely and was using Camino full-time. It was noticeably faster and otherwise a joy to have with me on the web.

I’m also a fan of the Mozilla browser Seamonkey , which is the “all-in-one” application suite that Netscape Communicator tried to be. I’ve heard people grumble about Nvu, the web page editor that’s descended from Netscape Composer, but actually I find it to be one of the best free web page builder on the market today. A subset of Nvu is built into Seamonkey in the same way that Composer was built into Netscape Communicator. I always found this to be a powerful combination… open any web page you meet in an HTML editor! But the idea fell into the garbage heap along with several other great features of Communicator, when the Microsoft monopoly juggernaut awoke and flicked the whole Netscape thing off its back.

Windows users have it pretty good, too, of course, but this is one category that they can’t claim to have more software available than Mac users. That’s probably because Microsoft has so cowed Windows developers that no one’s been seriously challenged to develop a competitor to IE, except for open-source developers who use Windows, of course. So you’ll find all the same Mozilla browsers that are available to Mac users, plus a few Windows-only flavors that use the Gecko rendering engine. Windows users also have Opera, of course, but the other main family of browsers is based on Microsoft’s proprietary Trident rendering engine that’s at the core of IE. And as these objective speed tests prove, Trident is way behind both Gecko, Opera, and WebKit in powering a web surfer’s activities in 2006. What’s missing on Windows, then, is WebKit, which despite being the butt of a surprising number of snotty remarks in blog comments, is a truly powerful, open-source engine that nowadays far outpaces Gecko in performance on Mac OS X.

Opera 9

Opera 9 was a revelation to me (For a rundown of its features, see this review by the founder of OperaWatch.com). Like many users, I had tried Opera off and on over the years as new versions were released. But I was never hooked, especially since I didn’t want to pay for a web browser, and I certainly didn’t want to be subjected to advertising for the privilege of using any browser… no matter how good it might be.

But Opera 9 was different. For one thing, this website you’re visiting suddenly worked, when previously it required as much hacking as IE to get it to render in Opera as well as in Firefox and Safari. This is obviously a reflection of Opera’s maturing support for web standards, which they do tout as a feature in the new release. I’ve now used Opera off and on for a couple of months, even switching from Apple Mail to Opera Mail for awhile. Opera has won me over as a fan, and I now use it every day… though not as my default browser.

Here are the things I really like about Opera that make it worth returning to for awhile each day:

JavaScript Debugger

Even as good as Firebug for Firefox is today, with its new JavaScript debugger built in, I still find Opera’s handy debugger superior. With Opera, I get a succinct statement of the problem, with a detailed backtrace from the offending event through each line of relevant JavaScript back to the source line where the problem originates. 99 percent of the time, this cleanly formatted statement is all I need to know how to fix the problem. To illustrate this, take a look at these two debugging statements. The first is from the Mozilla Venkman debugger, which required me to do a great deal of clicking and setting of breakpoints to get this information.

#0: function anonymous(element=void:void) in  line 543
	541:
	542: Effect.Fade = function(element) {
	543: element = $(element);
	544: var oldOpacity = element.getInlineOpacity();
	545: var options = Object.extend({
	Continuing from breakpoint.
	Exception ``TypeError: element has no properties'' thrown from function anonymous(element=void:void) in  line 544.
	[e] message = [string] "element has no properties"
	Exception ``TypeError: element has no properties'' thrown from function updateContent(box=void:void, url=string:"/ajax_software.php?numberposts=20&postcat=25&cat=26&tag=Freeware") in  line 363.
	[e] message = [string] "element has no properties"
	Exception ``TypeError: element has no properties'' thrown from function onclick(event=MouseEvent:{0}) in  line 1.
	[e] message = [string] "element has no properties"
	#0: function oncommand(event=MouseEvent:{0}) in  line 1

This next debugging statement is from Opera, which didn’t require anything of me other than to open the Error Console (which also debugs CSS, HTML, XML, and many other protocols but, like the Mozilla console, lets you focus on one type if you choose):

JavaScript - http://test.musingsfrommars.org/?cat=25&p=646
Event thread: click
Error:
name: TypeError
message: Statement on line 544: Could not convert undefined or null to object
Backtrace:
  Line 544 of linked script http://test.musingsfrommars.org/js/src/effects.js
    var oldOpacity = element.getInlineOpacity();
  Line 363 of linked script http://test.musingsfrommars.org/js/newsbox.js
    new Effect.Fade(box, {duration : 0.6});
  Line 1 of  script
    updateContent("post", "/ajax_software.php?numberposts=30&offset=0&tag=Automator&postcat=25&cat=118");

Now honestly, which do you prefer?

Tab Navigation

I don’t understand why the browser makers don’t understand that we need better navigation tools for a tabbed-browsing experience than we have. Using the OS’ application-switching keyboard shortcuts (Alt-Tab, Cmd-Tab) just doesn’t cut it. Opera is the only one that gets it right thus far. In Opera, you can use the same sort of keyboard shortcut you use for navigating among windows, to move from tab to tab. On the Mac, it’s Option-Tab, and you can configure the functionality to go straight through the tabs either forward or backward, or (and this is my current favorite) to have the switcher navigate to the previously used tabs in order of use.

Speed

Opera is definitely a speed demon on the Mac, just as it is on Windows. I often have to do a double-take to realize the browser has already rendered a page I just requested, it’s that fast. I’ve read that Opera’s speed difference becomes more noticeable as your system’s free memory becomes tighter, and that’s been my impression as well. Whereas Safari starts out like a racehorse, it seems to flag after awhile and needs to have its cache emptied to keep it going. I tend to browse in Opera with the cache totally disabled, which is useful for development anyway, and I hardly ever need to restart the browser or feel it slowing down. That’s a very significant virtue, in my book.

Stability

I’m trying to remember if Opera 9 has ever crashed on me… well, maybe once or twice over 2-3 months. I’m now using the second beta version of Opera 9, which is even more stable than the first. And keep in mind we’re talking about beta software here, folks. That’s stability!

Drag to Text Fields

Firefox can do this, too. Why can’t Safari? As embedded (so to speak) as drag/drop is in the Mac computing culture, it’s inconceivable that after 3 years Apple’s engineers haven’t recognized the need–and addressed it–for dragging text to an HTML form’s text field. You can drag to a TEXTAREA field, but not to a TEXT field. In Opera, you can, and I like it.

Draggable Tabs

Speaking of dragging things, Safari is way behind in not letting you drag and reorder your tabs. It’s not a failing of WebKit, because other WebKit browsers (Shiira, for one) can do this, so what’s the prob? Like Firefox, Opera lets you easily rearrange your tabs… though, oddly enough, Camino doesn’t. Something else about Opera tabs that I really like: You can choose to have new tabs open adjacent to the one you’re currently using, rather than at the end of the row of tabs. This is quite often very useful and saves a lot of mousework. In conjunction with this, you can choose to lock certain tabs in position. In general, Opera has more options than any of the other browsers and includes natively most of the useful features that are available in Firefox through plugins.

Easy Theming

Firefox users will say, “Hey, we got lots of themes, too!” And that’s certainly true. Safari has none, which is sad and reflects Apple’s control-freak impulse that makes modding the OS more difficult than it needs to be. (But that’s another article…) However, when you want to try out a new Firefox theme, you have to shut your browser down and restart! And Firefox is easily the slowest browser out of the starting gate of all the ones discussed in this article, so that’s no insignificant time-waster when you’re trying a lot of themes. Opera, on the other hand, lets you change themes–and preview them–without doing anything more than selecting one from a list. After working with themes in Firefox, this was quite a shocker. A good one!

Zoom and “Small Screen” View

These are both simply amazing tricks. The zoom feature is interesting mainly as a technical marvel… Opera has implemented a Zoom that actually magnifies all page elements equally… graphics, CSS styles, text, and all. You can zoom up to 1000 percent (that’s BIG, folks!), and down to 20% (anybody need a thumbnail quick?) But while that’s cool, Opera’s “Small Screen” view is both amazing and a practical boon to developers.

You choose “Small Screen” as one of the “View” menu options, and Opera immediately reorganizes all of the page’s content–including the content set with a display:hide attribute–into a thin vertical strip 250 pixels wide. That’s about the width of your typical PDA screen, so right away this is a useful way of seeing how your web site will render on a screen that size. What about all the graphics? And JavaScript? And Ajax? Believe it or not–and you really do have to try this for yourself to appreciate what I’m saying–everything works correctly. The images are all neatly scaled down, and the content is arranged in the order presented on the page. As such, this feature is ideal for checking the accessibility of your content. And I do mean all of your content. If anyone else is like me, you are tempted to echo database queries in hidden DIV tags during development, as a debugging technique. If so, you will realize those are still “accessible” when you view your site in Opera’s “Small Screen” mode. Um, of course, I had already–(cough)–removed those debugging echos from my code before I did this check just now.

There are many other great features of Opera, but these are the ones that make me launch it so often during the day now. Opera also has its share of quirks and drawbacks, which keep me from using it full-time. Since the focus of this article is on the great features of these browsers, I won’t spend a lot of time on them. But to give you an idea of what I’m talking about, here’s a short list:

• Trouble downloading zip files… takes more than a point-and-click for some reason.
• Source view is sometimes incomplete. I noticed this recently when I tried to get my weekly newsletter in the usual way from a PHP script I built. I had to run back to Safari.
• Drag/drop problems. I found I couldn’t drag and drop text from a web page like you can in Safari. There may be a trick I’m missing, but when you try to drag the text, the mouse loses the selection.
• Missing contextual menus. As with Firefox, none of my usual contextual menu items (and I have a ton of ‘em) work in Opera.
• No AcidSearch! Opera’s customization options for the web search field are weak compared with its strengths in other areas. It does have one cool feature that almost–but not quite–suffices: Go to any site, right click on its search field, and you can add the site to your search engines list. Problem is, you can’t easily rearrange the items in the list. No, nothing–not even any of Firefox’s many plugins–equals what AcidSearch lets you do in Safari. That’ll have to be the subject of another story.

Firefox

The best thing about Firefox is that it’s so extensible, and that there is so much development taking place around it. You can find Firefox extensions for virtually anything it seems, and if you have enough time, you’ll probably find two or three that you’ll actually use every day. The main ones I use are

• Scrapbook
• Weather
• AdBlock, and
• Web Developer

I’ve never been a big fan of the sidebar, so most of the Firefox plugins that work there don’t have much appeal. The same is true for Opera and Safari. (Safari has some plugins that introduce a sidebar, and both Shiira and OmniWeb employ them.)

Most recently, my one big reason for running to Firefox is FireBug. Now here’s an extension I can really dig my teeth into! Where the Web Developer extension was nice, it wasn’t a whole lot more than a bunch of bookmarklets all rolled up into a neat little interface. FireBug is worth writing home about… the equivalent of which today is “worth blogging about.”

Even surpassing what Microsoft provides IE developers, the Mozilla group and its legions of open source developers has assembled the very best tools for debugging and testing web pages of any browser on any platform. With FireBug, Firefox now has a tool that combines usefulness with ease of use. The Mozilla DOM inspector is useful, but very clunky to use when compared with the Web Inspector tool the WebKit boys have cooked up. The Mozilla Error Console and Venkman JavaScript debugger were a formidable pair, though as I’ve noted earlier, Opera’s relatively simple interface provides the gist of what you need to know in a much more usable form. FireBug combines the best of all the Mozilla tools into one interface that I now rely on for a number of tasks. In FireBug, all you have to do is go into Inspect mode and troll around the page peeking into the guts of each element through the tabs below. If you want to focus on one element, just click on it. At that point, you have five tabs full of info about the element:

Source code

The basic source code, though oddly, in a form you can’t copy/paste from.

CSS styles

Here, you can see what the browser thinks the CSS styles are for the element. (Often quite different from what you thought!)

Layout Info

A wealth of useful information here, these are the element’s style properties you can access in JavaScript, both for DOM scripting and for dynamic style changes. Want to know what the offsetLeft or scrollHeight value is for an element? Now you can find out without having to resort to alert tags or poking through Venkman’s interface!

Events

Here you can test–in real time–the mouse events an element is receiving, as well as their values… For example, the element’s clientX and clientY values.

DOM inspector

Finally, here is all the DOM detail you will ever need, presented in an interface that’s much easier to use than the DOM Inspector or Venkman extensions.

Aside from the Inspector, the new Debugger is useful when I can’t get what I need from Opera, but FireBug’s Console is critical to me in doing Ajax pages. The Console displays errors, of course, but you can also ask it to display remote page requests. So now, each link I click that runs an Ajax call gets displayed in the Console, and I can inspect both the returned data and the page headers for the request.

Speaking of bugs, Firefox has a few that aren’t going to be easy to eradicate. The biggest aspect of Firefox that bugs me is the absence of my treasured contextual menus and inability to access my Mac OS X Keychain, but it’s also the browser’s poky startup time and relatively slow page rendering. The look/feel thing isn’t such a problem now that Firefox has native OS X form widgets and a huge store of nice themes. Oh, and I’d also miss AcidSearch in Firefox as well.

Safari/WebKit

As noted in the speed tests, Safari really is just about the fastest browser available for Mac OS X. I actually find Opera to be faster in continual use, but the difference isn’t huge. For a period of time, Camino was clearly the fastest Mac browser, but that’s just not true anymore.

Aside from speed, Safari is the best there is at remembering your form information. And I’m not talking about just usernames and passwords. You can configure Safari to keep a running history of everything you’ve typed in any form field you encounter. Why is this useful? Well, suppose that you, like me, do a great deal of data entry in your web browser. For example, in managing Classic 45’s, I fill out a form of information for each 45 that goes into inventory. Safari remembers everything, so when it’s time to type “Tetragrammaton” one more time in the “Label” field, Safari does its useful autocomplete thing for me. When it’s time to enter a new B side product number, Safari remembers the last one entered, so it’s easy to update. Opera has a “Wand” feature that lets you remember form data, and I haven’t fully tested it. But I’ve tested it enough to know it only remembers one value per field. Safari can remember hundreds of values. None of the other browsers even comes close to Safari in this functionality, and it’s one of the things that keeps me returning. (Sadly, WebKit leaves this feature out, so even WebKit can’t fully substitute for Safari for me.)

Then there’s Safari’s Magic Page Cache. That’s my term for it, but it’s a very useful feature that’s saved me an untold amount of time. Here’s what you can do in Safari. Say you’re halfway done filling out a form, when you remember some text you’d like to include from two pages back. You could open a new tab and browse to the page using the browser’s history, but the most intuitive thing to do, and the fastest, is to just hit the back button a couple of times, copy what you need, and then hit the forward button a couple of times. In Safari, you can actually do this, and the browser won’t wipe out the info you’d already typed when you return. All of the Mozilla browsers wipe forms clean by default when you browse backward or forward to them through the browser cache. Opera comes close, but Safari is the Page Cache king, in my experience. Likewise, it’s fast as lightning in Safari to browse back a number of pages through your history cache. Firefox wants to render each page afresh, even if you have it set to use the cache. I remember this was an annoyance with Netscape Communicator, too, and it appears that Gecko still has this behavior.

Though Safari doesn’t have nearly as many plugins and extensions as Firefox, it’s got some great ones that Firefox lacks. Besides the aforementioned AcidSearch, which is a simply amazing free extension to the Safari web search field, the main one I can’t live without on other browsers is SafariBlock. All the browsers have some way to let you block ads nowadays, but I find SafariBlock to be the most convenient and easily customizable; unlike AdBlock for Firefox, the Safari equivalent follows the Mac philosophy of keeping things simple and focused. For example, in Firefox if you want to remove an image that has an imagemap on it, you first have to remove the imagemap. Now, I ask you… Why on earth would you want to remove just the imagemap? (Does it have an ad in it?) Or, to put it another way, is the price of accommodating the extremely rare occasion when you want to remove the imagemap but not the image worth the cost of having to do it every time? That’s the kind of basic usability mistake that infests the Windows OS but which the Mac OS blissfully avoids for the most part: Just because you can provide an option in your software doesn’t mean you should.

I also use SafariExtender, which lets you rearrange tabs and save tab sets, and SafariStand, a free extension with an amazing array of functions (including rearranging tabs), the most useful of which to me is its history and bookmark search features. These last two don’t top anything available for Firefox, but they encapsulate probably a dozen extensions into only two. If you’re interested in exploring the wide world of Safari extensions, there’s a great site for that, appropriately called Pimp My Safari.

Finally, there’s Safari’s interface and foundation as a Cocoa application. Cocoa offers Mac OS X users a wealth of mostly open-source tools that can be shared among all the Cocoa apps you use. For example, one little fellow makes it so I can navigate to a URL merely by selecting and clicking it while pressing the command key. There’s a whole set of TextExtras that you can activate in any Cocoa app, and a system of mouse gestures that work likewise. I make heavy use of a Cocoa extension that puts the Mac OS X Services menu in my contextual menus, and you just can’t do that in non-Cocoa applications. On the lighter side, there’s my favorite, SetAlphaValue, which lets you adjust the transparency of each application’s windows. A large number of contextual menus are available only in Cocoa apps, as well as a large library of other “Cocoa enhancers”, most of which are offered by developers for free. Camino is the only Gecko-based browser that’s written in Objective-C, the Cocoa language of choice, so none of this wealth is available if you choose to browse with Firefox or Opera. Some of the functionality is available, but if you’re a Mac user, wouldn’t you prefer to access the same function in the same way? Besides that, to use Firefox you’d have to locate, test, and install all of the extensions that get you there. Frankly, I can’t help but feel that as Firefox gets more and more loaded down with extensions, both its stability and its performance will degrade. So for me, the fewer extensions one has to rely on, the better.

Safari’s has two primary failings. The first is one that pisses off developers but has little, if any, impact on users. Namely, Safari still doesn’t have a built-in XML/XSLT parser, so if you want to serve XML files, you have to XSLTize them on the server. This is a serious failing, though, because there are some cool advances in developing dynamic pages that apparently provide some speed improvement over parsing the DOM. The good news is that the WebKit team has announced that support for XSLT is now available in the nightly WebKit builds, so we can assume this capability will make it to Safari soon.

The second is one that’s bad for users, too. Again, the WebKit project is moving along in this one, but it’s still much harder to develop a WYSIWYG editing tool for Safari than for Firefox, IE, or Opera. Safari has lacked support for the “ContentEditable” API that enables this functionality. As a result of this, Safari users are typically presented with a blank TEXTAREA field where other users get a nice, word-processor-like interface to format their text.

All the Lovely Browsers, Redux

Did it really require so many words to explain why I use Safari and Opera? Well, anyone who knows me knows I like to be thorough–and accurate. Though I could have spent another several pages explaining the good features of these browsers, my point is that they’re all very good browsers!

It strikes me that today we have the largest number of truly great browsers than we’ve had in a long time. All three of the major competitors to IE–Firefox, Opera, and Safari–have matured to the point that they are not only way ahead of Microsoft’s line-in-the-sand, but they are all well worth getting to know and perhaps using daily for different kinds of tasks. From the turbulent 1990’s browser war, which was fought between only two primary browsers, we now have four players worthy of entering the race. As a result, web developers should avoid seeing this race as a two-way “battle” between IE and Firefox. Rather, we should celebrate the terrific browser diversity we now have at our disposal, and take advantage of it.

Mac users have very good reasons for not choosing Firefox, as good as it is, as their default browser. And if you’re developing for the web and aren’t knowledgeable about WebKit-based browsers like Safari, it’s time you took a walk on the wild side! You might just understand why some of us Safari users keep making a fuss when we get left out of the game.

Achieving relative functional and design parity among Firefox, Safari, and Opera is incredibly easy if you stick to JavaScript/Ajax libraries that are certified to work in all three. The only problem comes when you have to tune the site for IE or for browsers older than that. But universal accessibility is a burden everyone must bear who presents information, products, or services of interest to those user groups on the web.

You know how everyone understands by now that “friends don’t let friends drive drunk”? Well, I’m hoping to influence one or two web developers to start adopting the attitude that “developers don’t let developers build non-standard web code.” If you adopt this attitude, you will pretty much by default produce code that works in Safari and Opera, as well as Firefox. Of course, it will still leave you hacking away at IE (yes, even IE 7), but maybe if enough websites start being optimized for standards-compliant web browsers rather thann for IE, the IE-to-Firefox/Opera/Safari migration will pick up some additional steam. And that would definitely be a good thing for web developers!