|
||
|
Greg Reim, in a dialog with me about his blog at blogs.sun.com, brought up an example of a bug in Internet Explorer and expressed that some feel quite differently than I about the relationship of the various Web browsers to the continued development of the Web. His quality commentary spurred me on to explain my position more. I'll take the liberty of doing so below. Definitely, I can see bugs such as Greg describes coming up in IE. At least, there are work-arounds for bugs of that nature. The Mozilla and Safari bugs that I describe are not as easily worked around or are impossible to work around. The systems I have built and worked on have involved creating a lot of HTML on the client and using that to draw the GUI via 'document.write' calls. Internet Explorer has always performed very well with these w3c-standard systems. But Mozilla doesn't seem to do too well with this (double-copying the HTML content in some deeply nested containers), and also blocking cross-frame scripting when it should be allowed (i.e., when both frames are from the same domain) under 'https'. With my application framework, I have to treat Mozilla/N6+ just like Netscape 4 -- avoiding writing to deeply nested containers. It makes the GUI response slower. Also, not surprisingly, auto-scrolling (of the viewed Web page) is broken in Mozilla, but works great in IE. Safari and Opera both die on my legal cross-frame writes; I believe both even under 'http', not 'https'. I've filed detailed bug reports and provided test code for all these bugs, but only Mozilla has been responsive. However, the best result I've seen is for one of the bugs to get fixed and then re-appear later, broken. The bugs are so severe that I had to move on to other realms of software work a while ago and I've forgotten many of the details. I was one of the approximagtely 1300 developers that signed the petition in late 2000 on O'Reilly begging Netscape not to release v6, but they did anyway. Things have not changed much since. Regarding feature support, I imagine that Mozilla might encompass a larger area than IE, but from my experience, Mozilla functionality is often broken. It comes across as an app built by coders for coders. Mozilla Thunderbird, the e-mail program, is a classic example. It has lots of great features, but leaks memory like a sieve and once locked me out of my entire e-mail account folders. I had to manually reconstruct the installation. It would also not truly delete e-mails. This was the Thunderbird that shipped around Mozilla 1.4. After a year and a half of trying it, I chucked it and purchased Eudora. The appearance of so much Internet Explorer-specific Web content (Yahoo E-mail Plus, GMail) and the adoption of data-centric Flash is, as far as I can see, the logical result of the situation. The issue isn't that there are not any perfect Web browsers. There are are just too many bugs in Mozilla, Safari, and Opera. It's a fixable problem though, once it's seen. To clarify the deeply progress-withholding nature of some of these bugs, I will discuss the bugs on non-IE, non-Netscape 4.0 browsers with cross-frame JavaScript. Support for cross-frame JavaScript is absolutely crucial. To build a cross-platform "rich Internet" application, hidden HTML frames (i.e., width & height of 0) must be used as communication sockets. Some browsers have platform-specific ways of doing this, but using a hidden frame, which works on all robust, domain-security-rules-following Web browsers, makes the most sense. It even works on Netscape 4.0x. Myers and Nakhimovsky spread the word about how hidden HTML frames are perfect for communication sockets in their 1998 book, JavaScript Objects. Unfortunately, in my tests, Mozilla goes in and out of supporting this under 'https' depending on the release version (despite my extensive Bugzilla commentary and proof code over the years), and Safari and Opera fail on my cross-frame writes. In the case of Mozilla, the problem appears to be pure carelessness, while Safari and Opera just seem to explode under the weight of a real rich-client Web application. It is this kind of thing that truly leads developers and entire engineering departments to flee the standard browsers as development platforms, and it has become something of a tragedy for the Web. - Christopher M. Balz Contact info@treelogic-swe.com Last modified: Friday October 1, Pacific Daylight Time 2004 |