Section B. Technical overview
B. Technical overviewThe purpose of this book is to give an overview of all facets of JavaScript that are important in creating modern Web sites. I split JavaScript into six areas, each of which have their own purpose and problems, and each of which will be treated in its own chapter. The table below summarizes these six areas.
All scripts use the Core language, Events, and the DOM, because all scripts must be a program (Core), must wait for the user to do something (Events), and must update the page somehow to give feedback (DOM). StandardizationStandards-wise, JavaScript is a bit of a patchwork, and in order to understand the reasons for this you need a quick historical summary. (JavaScript's full story will be told in 1C.) De facto Netscape 3 standardJavaScript was invented and first implemented by Netscape, which back in 1996 was the leading browser. Then other browsers, such as Explorer, entered the market. In order to ensure that all existing Web sites functioned correctly, they were forced to copy Netscape's JavaScript implementation exactly. Therefore, even today all JavaScript browsers support the de facto Netscape 3 standard. It consists of Core 1.1, BOM, the traditional event model, and the Level 0 DOM. Back in those days CSS modification and data retrieval weren't invented yet, so they're not part of this standard. Nowadays the standard is distinctly antiquated, but since millions of Web pages still use old-fashioned Netscape 3 scripts, no browser can afford to relinquish this standard. Then followed the Browser Wars, during which Microsoft and Netscape struggled for pre-eminence in the browser market and made a distinct point of being as incompatible as possible. It took JavaScript many years to recover from this ordeal, and we're still suffering the consequences, especially in event handling. Modern standardsIn order to understand the modern standards we first have to discuss a fundamental distinction between Core and the DOM (which includes event handling and CSS modification). Although JavaScript is best known for its function as a client-side scripting language in Web browsers, it can be implemented in a variety of other environments. Adobe's ActionScript, for instance, implements JavaScript Core in Flash movies, and Netscape once had its own brand of Web servers that used JavaScript as their primary server-side language. Flash movies and Web servers are fundamentally different environments than Web pages. Nonetheless, they all use the JavaScript Core language in order to create a programming environment. DOM, on the other hand, is specific to XML documents (including HTML pages). Its view of a document as a hierarchical collection of nodes (see 8A) is excellently suited to Web pages, but largely useless in a Flash or server-side environment. That's why there are separate standards for Core and the DOM. The European Computer Manufacturers Association (ECMA) has standardized JavaScript Core, and this standard is (supposed to be) used in any JavaScript implementation, be it Flash, Web browsers, Web servers, or one that is yet to be invented. On the other hand, XML and its numerous offshoots are the domain of the World Wide Web Consortium (W3C). W3C created the DOM specification, which includes event handling and CSS modification. The BOM and data retrieval have not yet been specified officially. The Web Hypertext Application Technology Working Group (WHAT-WG) is working on the BOM, while at the time of writing W3C has created a first draft of an XMLHttpRequest specification for data retrieval. The BOM still follows the old de facto Netscape 3 standard, while XMLHttpRequest is being used as originally specified by Microsoft. Two tiersJavaScript standards are therefore a two-tiered construct. The older, lower tier consists of the de facto Netscape 3 standard which is universally supported but rather restricted, while the newer, upper tier consists of standards coming from ECMA, W3C, Microsoft, and WHAT-WG, most of which are supported by most browsers. The table below summarizes these two tiers:
Although nowadays all browsers are serious about following all standards, we're still suffering from a few holdovers of the Browser Wars. Microsoft has not yet implemented W3C's Events specification, but instead uses its own proprietary event model. In order to write cross-browser event handling scripts you must therefore understand both the W3C and the Microsoft models, as well as the older Netscape 3 standard. We'll discuss all this in Chapter 7. VersionsThere are several JavaScript versions, ranging from the obsolete 1.0 to the 2.0 that's under development at the time of writing. It's important to note that these version numbers only apply to Core; other areas of JavaScript (notably the DOM) have their own version numbers.
Originally, the idea behind these version numbers was to allow Web developers to specify what level of JavaScript they were using. It was supposed to work something like this: <script language="JavaScript1.2"> // scripts that use 1.2 features </script> Browsers that did not support JavaScript 1.2 were supposed to ignore the entire <script> tag, so that the scripts would only be executed in browsers that could handle 1.2. The advent of Netscape and Explorer 4 relegated this well-intentioned idea to the dustbin. Both browsers claimed to support JavaScript 1.2, but not even the most powerful fantasy can imagine them supporting the same JavaScript 1.2. Besides, this idea was only truly implemented in Netscape 2 and 3, though specifying "JavaScript1.2" triggers special and exciting incompatibilities in Netscape 4. Therefore these version numbers play no role in modern JavaScript development, and I advise you not to specify any version in the language attribute (in fact, you shouldn't use that attribute at all). Towards JavaScript 2.0As I write, JavaScript's inventor Brendan Eich is working on JavaScript 2.0. The purpose is to add new features to the Core language, including a better variable typing system, support for Java-like classes and interfaces, block scope for variables, and other innovations aimed at improving JavaScript as a programming language.
Mozilla and Opera are expected to start supporting some of these features in 2007, and other browsers are expected to follow later. Adobe participates in this effort, so ActionScript is also likely to implement Core 2.0. SecurityThe purpose of JavaScript is adding usability to a Web site, not breaching the user's privacy and security. First of all, picture what happens when an innocent end user finds a Web page that contains JavaScript. He essentially downloads an unknown program written by an unknown person that's going to run on his computer. In general, executing unknown programs that do unspecified things on and to your computer is the fastest way to get infected with viruses, Trojan horses, and other malign entities. In order to keep Web users secure from these hazards, as well as from breaches of privacy, JavaScript has strict security regulations. Its most important line of defense against malicious scripters is that it simply does not support certain actions. No access to host computerJavaScript cannot read from or write to the file system of your user's computer (with the exception of cookies; see 6G). Thus JavaScript cannot read password files from or write viruses to the user's hard disk. Same-source policyAs we'll see in Chapter 6, JavaScript allows you to access and run scripts that are located in another frame or window. Nonetheless, without any restrictions this would be a serious security hazard, since it might allow, for example, malicious site owners to read out the password the user types in his online banking tool, and then submit this password to their own servers.
Therefore JavaScript has a strict same-source policy: Cross-window communication is allowed only when the pages in both windows come from the same Web domain. If that's not the case, the browser gives a security error. This policy is very strict. Suppose I have two sub-domains, www.quirksmode.org and search.quirksmode.org. A page on the www domain opens a popup with a page on the search domain. Now the same-source policy kicks in and forbids any communication between the two windows, since they come from different (sub)domains. document.domainThere is one way in which I'm allowed to mitigate the same-source policy somewhat. I can set the document.domain property in both windows to 'quirksmode.org': document.domain = 'quirksmode.org'; Now both pages consider themselves to come from quirksmode.org without any subdomain, and the www page and the search page are allowed to communicate with each other. Obviously, you may only set document.domain to a value that's part of the real domain. This doesn't work:
The browser sees that my pages do not come from microsoft.com, but from quirksmode.org. Therefore the value is ignored and I cannot communicate with any page from microsoft.com. Other restrictionsApart from having no access to the host computer and the same-source policy, JavaScript has the following restrictions:
|
EAN: N/A
Pages: 116