Section A. The browsers
A. The browsersEvery browser contains a code engine (or rendering engine) that is responsible for interpreting the code on a Web page. A browser's JavaScript interpreter is part of this code engine, and therefore it's the code engine that really counts when it comes to JavaScript support. It's impossible to test your scripts in all of the JavaScript-capable browsers. There are simply too many of them. Nonetheless, l introduce a few important browsers (and code engines) in order of the excellence of their JavaScript support. The Mozilla familyNetscape founded the Mozilla Project in 1998 after the miserable failure of Netscape 4. The idea was to create a code engine that anyone could use to build a browser. This code engine is called Gecko, and right now it powers the browsers marketed as Mozilla, Firefox, Netscape, and Camino (as well as a few others, I suppose). Mozilla and its numerous ilk are arguably the best browser family when it comes to JavaScript support. In theory Gecko ought to work on every operating system, but in practice the Mac version usually contains a few minor bugs that are absent in the Windows and Unix versions. Unfortunately, browsers are not required to include a new Gecko version as soon as it is released. Firefox and Mozilla do so, and Firefox contains an automatic update feature that makes sure users always have the latest stable version installed. Netscape, on the other hand, poses a problem: it's rarely possible to find out which Mozilla version it uses (the 8.1 release says "based on Firefox," which is untrue as well as unhelpful). Besides, Netscape also offers the possibility of using Explorer's code engine, which muddies the waters even more. Fortunately, it has a tiny market share nowadays. When bug reports start to come in, you'll usually find that one tester has an older version of Mozilla, Firefox, Netscape, or Camino installed, and it's hard to find out exactly which Gecko version runs under its hood. I generally ignore these complaints and tell people to upgrade to the latest Firefox. There are just too many Mozilla-based browsers to keep track of them all. Fortunately, the trend is towards the adoption of Firefox; at the time of writing its user base is larger than the user base of all other Mozilla family members combined. This gives you a better chance of writing scripts that work in "all Mozilla versions." Explorer WindowsExplorer (officially, Microsoft Internet Explorer for Windows) has had a market share of about 80 to 90% since 1999. The vast majority of Web users have Explorer 6.0 installed, but in the next few years they'll slowly migrate to Explorer 7.0. Explorer's code engine is called Trident; Trident is not used for any other browser. Explorer 5.0, released in March 1999, was the first browser to support the W3C DOM and XMLHttpRequest, but it was also the last Explorer version to contain a major JavaScript update. The 5.5, 6.0, and 7.0 versions only added a few JavaScript features and bug fixes. Essentially Explorer's JavaScript interpreter hasn't been updated for seven years, but even though that becomes noticeable here and there, its JavaScript support is still easily better than that of any browser except Mozilla. Unfortunately, Explorer still uses quite a few proprietary methods and properties in certain areas, notably event handling. At the time of writing, the Microsoft Internet Explorer team is dedicated to following standards, as all other browser vendors do, but it hasn't fixed JavaScript yet. SafariSafari is Apple's browser. Released in 2003 and using the KHTML code engine, it is well on its way to becoming the default browser for the Macintosh platform. Safari has its share of bugs, and is slightly behind Mozilla and Explorer when it comes to JavaScript support. Nonetheless, it's a good browser that rarely gives me problems, as long as I don't try anything too fancy. When you write really advanced scripts, though, you'll encounter Safari's limitations. Apple is steadily working to make it a better browser, so I assume that Safari's JavaScript support will eventually rival that of Mozilla and Explorer. OperaOpera is an independent browser with a rather small market share (around 0.5%). It managed to surviveand even thrivethrough the Browser Wars, without a large and prosperous corporation behind it. This achievement is not to be despised. When it comes to JavaScript, Opera has always been slightly behind the other browsers. During the Browser Wars, it didn't implement DHTML (i.e., the Microsoft or Netscape proprietary DOMs), which in hindsight was an excellent decision. Although it has largely caught up with the other browsers, it remains the most difficult browser to develop scripts for. It has its share of bugs, and its market share is so tiny that the temptation to just forget about it when you encounter a bug is difficult to resist. Other graphic desktop browsersA few other browsers support large parts of the W3C DOM: iCab is a small independent browser for Mac, and Konqueror is one for Linux/Unix. Both have good (though not excellent) JavaScript support, and I occasionally test my sites in them. Konqueror uses the KHTML code engine that drives Safariin fact, KHTML was developed for Konqueror. Although code sharing takes place regularly between the Safari and Konqueror projects, there are differences between the two browsers. Explorer for Mac is a wholly different story. Although it theoretically supports a quite decent amount of JavaScript, in practice it crashes with disturbing regularity when you try to run a script like Usable Forms. Tasman, the Explorer Mac code engine, was created in 1999 and 2000, and has hardly been updated sinceeffectively, it's a dead browser. In addition, when it was ported to Mac OS X, quite a few things went horribly wrong, and the 5.2 release for OS X is decidedly more buggy and crash-prone than the older 5.0 and 5.1 versions for Mac OS 9. When I develop a script, I always test it in Explorer Mac, but as soon as it shows any sign of not being able to keep up, I add a browser detect to bar it from accessing the advanced interface (see 3D). I no longer bother to solve its bugs; it's too much work for too small a percentage of the browser market. Besides, they're usually unsolvable. A minuscule percentage of Web users still use older browsers, for instance Netscape 3 or 4. These browsers haven't a prayer of executing any modern JavaScript, but as long as you use proper object detection, as we'll discuss in 3C, you won't encounter any problems. Mobile phonesMobile phones with an Internet connection are the Next Big Thing, and they'll change the market Real Soon Now. Back in 1999, the company I worked for reached this conclusion when WAP became available in Europe. In 2002, the next company I worked for reached the same conclusion when former monopolist KPN tried to introduce the Japanese iMode system on the Dutch and German markets. Both attempts essentially failed. In fact, everybody's mumbled the mantra so often that "Real Soon Now" has taken on the meaning "maybe year after next." During one of the overheated 1999 meetings I made a strategic decision. I would start to pay serious attention to mobile phones as soon as a serious client turned up who was willing to pay serious money for mobile phone support. Seven years have passed, and I'm still waiting for that client. Frankly I don't believe that Internet over mobile phones will ever amount to much in Europe and North Americathough Asia is another matter. The phone displays and keyboards are too tiny, especially when compared to the wide swaths of space people are used to having available on their desktop and laptop computers. I could be wrong, though. We'll see year after next. From a testing perspective, mobile phones are an abomination, because there are far too many of them. I once heard a story about a testing protocol for mobile phones: an entire basketful is carried in and spread among the long-suffering Web developers, who spend their next few days catering to the phones' whims. I don't know if the story is true, but it could easily be. This dark cloud has a silver lining: Mozilla, Microsoft, Apple, and Opera have meanwhile developed mobile versions that are being implemented in the next generation of phones. This is decidedly an improvement over the "browsers" cobbled together by the mobile-phone vendors themselves, which are generally unable to support even HTML properly, let alone CSS or JavaScript.
Screen readersI discussed screen readers in detail in 2E. They are generally programs installed on top of an existing browser (most commonly Explorer), and their JavaScript support is chaotic and unreliable. There's nothing we can do about it. Sight-impaired Web users won't be able to appreciate our clever scripts any time soon. All the more reason to keep our sites accessible. |
EAN: N/A
Pages: 116