Firefox, bah humbug

Commentary--Firefox has been getting a lot of press lately. Firefox is free software in the Stallman-sanctioned sense--released under a GPL license and built atop technology developed for the Mozilla project. Everybody LOVES Firefox. Not only is it a great browser, but it will make your teeth whiter and secure you a date with Carmen Electra.

Okay, perhaps I exaggerate, but on that note, I haven’t seen ANYONE criticize Firefox. To a certain extent, this is because it is the best alternative in a world dominated by Internet Explorer (cue Opera/Safari/Konqueror fans to go into a frothing rage). On the other hand, as I can personally attest, it is politically incorrect in the extreme to criticize anything stamped with the open source moniker.

In short, though Firefox is a good browser, political considerations have allowed it to escape some deserved criticism. Firefox supporters make some rather costly demands of Web sites, particularly given that it commands such a small, albeit growing, share of the browser marketplace. Recent feverish Firefox support pieces aside, I still think that ignoring IE’s non-standard features will prove a large, and unnecessary, barrier to the success of the best alternative to Internet Explorer.

My Experience providing support for Firefox
As a certain square-jawed actor might have said had he been abducted by aliens and forced to write software, "the experience of one programmer doesn’t amount to a hill of beans in this crazy world." Even so, for a browser that touts its support for HTML standards, I was surprised to find that it had difficulty with standard HTML.

Check out this link under Internet Explorer, and then Firefox. I have created a Web page with a fixed position left, top and bottom sidebar that surrounds a scrollable area. All regions resize to completely fill the browser when its dimensions are changed.

To make this work, I have a table which lays out the basic position of the main sections (left bar, top bar, bottom bar, content). I’ve placed a div tag inside the "content" area of the table, setting its width and height to 100% and adding automatic scrollbars by setting the "overflow" CSS attribute to "auto."

None of this is rocket science. Some might object to the use of tables, which in CSS circles might seem SO 1990s. I couldn’t care less. Tables are easy to use, are immediately intuitive to this old HTML hand-coder, and most important, have existed since the early days of HTML. Regardless of your preferences, there is no reason they SHOULDN’T work.

In IE, the page renders properly. In Firefox, the div tag refuses to size relative to its parent table (and doesn’t provide scrollbars), which causes the bottom toolbar to disappear past the edge of the screen.

I managed a workaround by detecting the browser and using a fixed width for the table and div tags when the browser isn’t Internet Explorer. This isn’t ideal, as the page doesn’t automatically adjust to fill the browser window, but it works. Even so, Opera still has problems, and the workaround makes no difference in Apple’s Safari browser.

Differences in scripting environment offered a few hurdles. Client-side scripting has come a long way since 1998, when I was tasked with making a Javascript tree-view work in both IE and Netscape. Since Firefox is a successor of sorts to Netscape (well, at least spawn of Netscape), that’s a good thing.

Still, there are a few gotchas. Why it would kill anyone to provide "document.all" support in scripts is beyond me, though document.GetElementByID() does the trick, if in a more verbose fashion.

In other areas, however, the replacement is not a match in terms of functionality. Like it or not, but showModalDialog is a better way to provide feature-rich user feedback windows than window.confirm (which Firefox supports, even though there is NO PUBLIC STANDARD for it). With showModalDialog, I can pop a window offering "Yes," "No," or "Cancel" buttons that requires a response before proceeding. With window.confirm, I have to craft all my questions as something to which "OK" or "Cancel" makes sense, never mind asking for three, four, or five state responses.

I’m not the only one who thinks so. Yahoo mail uses showModalDialog to generate prompts the look and feel of which matches that of the main page if the client is IE, but drops back to window.confirm for everyone else.

Unreasonable Demands
A number of respondents to my last article claimed incompatibilities didn’t matter, because if a site didn’t provide decent Firefox support, the community would apply pressure to force them to change or else face lost customers and/or bad press.

Though that may well be the case, it’s a bit like fans of a company which lays railroad tracks too narrow for most existing trains bullying engine manufacturers to alter their product to accommodate them. Would it not be so much cheaper, in the aggregate, if the tracks were the proper width in the first place?

Essentially, Firefox’s (or Opera’s, or Safari’s) refusal to implement features found in the browser used by 95% of people who access the internet means that they are insisting that hundreds of thousands of Web sites around the world tailor their sites to accommodate them. That seems an uphill battle, not to mention strange given that many who demand it are the same people who will be tasked with ensuring compatibility across all those browsers. I don’t know about you, but navigating browser idiosyncrasies isn’t my idea of a good time.

Besides, the resistance seems based on the mistaken notion that Web standards are a panacea for browser incompatibility. As noted in past articles, standards DO NOT MEAN that all implementations will have the same performance characteristics. My site now looks fine in Firefox (albeit fixed width), but looks less good in Opera, and doesn’t work at all in Safari. Both tout themselves as champions of Web standards, yet fail the consistency test, proof positive that incompatibilities aren’t dreamt up by executives bent on world domination, but are systemic to software development. As I’ve ALSO said before, there are reasons why one company or product regularly manages to dominate a particular software market.

Implementing IE’s non-standard features would make it easy for developers to target alternative browsers. It would enable developers to tap the reams of documentation which exist for Microsoft products. Ximian’s Miguel de Icaza has noted that Mono (an open source implementation of .NET) benefit from Microsoft marketing and documentation efforts. Microsoft provides EXTREMELY good documentation, a fact noted by many developers less enamored of Microsoft technology than myself.

Few have the money to create comparable documentation that is so centralized. Microsoft does. For a group whose biggest lament has been the lack of funds to market their products or pay for things that few volunteers want to do, the OBVIOUS solution would seem to be to ride the wave formed by larger competitors.

Conclusion
Firefox is certainly the best alternative browser I’ve come across. It makes Opera, its ally of convenience in a war against the common enemy Microsoft, seem downright lobotomized (cue Opera fans to burn me in effigy).

It must be admitted, though, that Firefox does have more support for "official" standards, as this link shows. I can’t say that all the missing features are equally important, and some I doubt I’d use at all. On the other hand, development environments are a bit like toolboxes. 15% of them you probably only use 0.2% of the time, but when that 0.2% comes up, it sure is great to have them.

So, as a middle ground, I’ll say Microsoft should implement more of the standard CSS attributes it lacks. As my example from the start of this article shows, though, there are areas where Firefox (and Opera and Safari, as neither browser handles my example well) could improve its treatment of workhorse CSS elements (the stuff most developers use 99% of the time). So, both have work to do.

Some in forums I’ve visited defend Firefox quirks by attacking the quality of the code it attempts to render (though, as you’ll note, my example was 100% valid HTML). In other words, "sloppy" code has no right to render properly.

That’s not only counter-productive, but ignores the reason people write HTML code in the first place. HTML is SUPPOSED to be easier to write than traditional user interfaces. HTML pages often have short lifespans, and thus HTML is supposed to be a forgiving environment which lends itself to rapid application development.

Most here would admit that IE does a better job of inferring proper behavior from incomplete or improperly-used HTML. That’s a GOOD thing, and Firefox would do well to learn the same lesson.

Lastly, as others have noted, Firefox is probably a safer security bet than IE. Don’t be lulled, however, into a false sense of complacency. Firefox certainly doesn’t use Browser Helper Objects, a technology misused by "spyware" vendors to monitor where a user goes on the internet (or, as I found on a friend’s computer, hijack it to strange locations). On the other hand, it’s not true that Firefox isn’t extensible. Binary installers (the standard way Browser Helper Objects find their way onto a Windows system) can install Firefox extensions just as easily as they install IE extensions.

In other words, the reason Firefox doesn’t face the threats IE faces is that they aren’t the browser used by 95% of consumers. That’s a bit like avoiding the threat of terrorism by moving to Pitcairn Island. It works for awhile, but if everyone has the same idea, your safety is compromised.

I LIKE the fact that IE, and Microsoft, face real competition. What I don’t like is the insistence that Web sites adapt to the upstart browser, not vice-versa. Remember, Microsoft has been down this path before, facing down a Netscape browser with a market share almost equal to that held by IE today. They chose to make IE fit the code developers produced, however non-standard, so that compatibility with IE involved little extra work. I see no reason why we shouldn’t expect the same of alternative browsers such as Firefox.