WHAT'S IN THIS CHAPTER?
WROX.COM DOWNLOADS FOR THIS CHAPTER
Please note that all the code examples for this chapter are available as a part of this chapter's code download on the book's website at
A SHORT HISTORY
As the web gained popularity, a gradual demand for client-side scripting languages developed. At the time, most Internet users were connecting over a 28.8 kbps modem even though web pages were growing in size and complexity. Adding to users' pain was the large number of round-trips to the server required for simple form validation. Imagine filling out a form, clicking the Submit button, waiting 30 seconds for processing, and then being met with a message indicating that you forgot to complete a required field. Netscape, at that time on the cutting edge of technological innovation, began seriously considering the development of a client-side scripting language to handle simple processing.
In 1995, a Netscape developer named Brendan Eich began developing a scripting language called Mocha (later renamed as LiveScript) for the release of Netscape Navigator 2. The intention was to use it both in the browser and on the server, where it was to be called LiveWire.
www.ecma-international.org/memento/TC39.htm). Made up of programmers from Netscape, Sun, Microsoft, Borland, NOMBAS, and other companies with interest in the future of scripting, TC39 met for months to hammer out ECMA-262, a standard defining a new scripting language named ECMAScript (often pronounced as “ek-ma-script”).
- The Core (ECMAScript)
- The Document Object Model (DOM)
- The Browser Object Model (BOM)
What exactly does ECMA-262 specify if it doesn't reference web browsers? On a very basic level, it describes the following parts of the language:
- Reserved words
- Global objects
The second edition of ECMA-262 was largely editorial. The standard was updated to get into strict agreement with ISO/IEC-16262 and didn't feature any additions, changes, or omissions. ECMAScript implementations typically don't use the second edition as a measure of conformance.
The third edition of ECMA-262 was the first real update to the standard. It provided updates to string handling, the definition of errors, and numeric outputs. It also added support for regular expressions, new control statements,
try-catch exception handling, and small changes to better prepare the standard for internationalization. To many, this marked the arrival of ECMAScript as a true programming language.
ECMAScript 3.1 became ECMA-262, fifth edition, and was officially published on December 3, 2009. The fifth edition sought to clarify perceived ambiguities of the third edition and introduce additional functionality. The new functionality includes a native
JSON object for parsing and serializing JSON data, methods for inheritance and advanced property definition, and the inclusion of a new strict mode that slightly augments how ECMAScript engines interpret and execute code. The fifth edition saw a maintenance revision in June 2011; this was merely for corrections in the specification and introduced no new language or library features.
The sixth edition of ECMA-262—colloquially referred to as ES6, ES2015, or ES Harmony—was published in June 2015, and contains arguably the most important collection of enhancements to the specification since its inception. ES6 adds formal support for classes, modules, iterators, generators, arrow functions, promises, reflection, proxies, and a host of new data types.
The seventh edition of ECMA-262, dubbed ES7 or ES2016, was published in June of 2016. This revision included only a handful of syntactical additions such as
Array.prototype.includes and the exponentiation operator.
The eighth edition of ECMA-262, called ES8 or ES2017, was finalized in January of 2017. This revision included asynchronous iteration, rest and spread properties, a collection of new regular expression features, a
Promise finally() catchall handler, and template literal revisions.
The ninth edition of ECMA-262 is still being finalized, but it already has a large number of features in stage 3. Its most significant addition will likely be dynamic importing of ES6 modules.
What Does ECMAScript Conformance Mean?
ECMA-262 lays out the definition of ECMAScript conformance. To be considered an implementation of ECMAScript, an implementation must do the following:
- Support all "types, values, objects, properties, functions, and program syntax and semantics” as they are described in ECMA-262.
- Support the Unicode character standard.
Additionally, a conforming implementation may do the following:
- Add “additional types, values, objects, properties, and functions” that are not specified in ECMA-262. ECMA-262 describes these additions as primarily new objects or new properties of objects not given in the specification.
- Support “program and regular expression syntax” that is not defined in ECMA-262 (meaning that the built-in regular-expression support is allowed to be altered and extended).
These criteria give implementation developers a great amount of power and flexibility for developing new languages based on ECMAScript, which partly accounts for its popularity.
ECMAScript Support in Web Browsers
By 2008, the five major web browsers (Internet Explorer, Firefox, Safari, Chrome, and Opera) all complied with the third edition of ECMA-262. Internet Explorer 8 was the first to start implementing the fifth edition of ECMA-262 specification and delivered complete support in Internet Explorer 9. Firefox 4 soon followed suit. The following table lists ECMAScript support in the most popular web browsers.
|Netscape Navigator 2||—|
|Netscape Navigator 3||—|
|Netscape Navigator 4–4.05||—|
|Netscape Navigator 4.06–4.79||Edition 1|
|Netscape 6+ (Mozilla 0.6.0+)||Edition 3|
|Internet Explorer 3||—|
|Internet Explorer 4||—|
|Internet Explorer 5||Edition 1|
|Internet Explorer 5.5–8||Edition 3|
|Internet Explorer 9||Edition 5*|
|Internet Explorer 10–11||Edition 5|
|Edge 12+||Edition 6|
|Opera 6–7.1||Edition 2|
|Opera 7.2+||Edition 3|
|Opera 15–28||Edition 5|
|Opera 29–35||Edition 6*|
|Opera 36+||Edition 6|
|Safari 1–2.0. x||Edition 3*|
|Safari 3.1–5.1||Edition 5*|
|Safari 6–8||Edition 5|
|Safari 9+||Edition 6|
|iOS Safari 3.2–5.1||Edition 5*|
|iOS Safari 6–8.4||Edition 5|
|iOS Safari 9.2+||Edition 6|
|Chrome 1–3||Edition 3|
|Chrome 4–22||Edition 5*|
|Chrome 23+||Edition 5|
|Chrome 42–48||Edition 6*|
|Chrome 49+||Edition 6|
|Firefox 1–2||Edition 3|
|Firefox 3.0. x –20||Edition 5*|
|Firefox 21–44||Edition 5|
|Firefox 45+||Edition 6|
The Document Object Model
The Document Object Model (DOM) is an application programming interface (API) for XML that was extended for use in HTML. The DOM maps out an entire page as a hierarchy of nodes. Each part of an HTML or XML page is a type of node containing different kinds of data. Consider the following HTML page:
<html> <head> <title>Sample Page</title> </head> <body> <p> Hello World!</p> </body></html>
This code can be diagrammed into a hierarchy of nodes using the DOM (see Figure 1-2).
By creating a tree to represent a document, the DOM allows developers an unprecedented level of control over its content and structure. Nodes can be removed, added, replaced, and modified easily by using the DOM API.
Why the DOM Is Necessary
With Internet Explorer 4 and Netscape Navigator 4 each supporting different forms of Dynamic HTML (DHTML), developers for the first time could alter the appearance and content of a web page without reloading it. This represented a tremendous step forward in web technology but also a huge problem. Netscape and Microsoft went separate ways in developing DHTML, thus ending the period when developers could write a single HTML page that could be accessed by any web browser.
It was decided that something had to be done to preserve the cross-platform nature of the web. The fear was that if someone didn't rein in Netscape and Microsoft, the web would develop into two distinct factions that were exclusive to targeted browsers. It was then that the World Wide Web Consortium (W3C), the body charged with creating standards for web communication, began working on the DOM.
DOM Level 1 became a W3C recommendation in October 1998. It consisted of two modules: the DOM Core, which provided a way to map the structure of an XML-based document to allow for easy access to and manipulation of any part of a document, and the DOM HTML, which extended the DOM Core by adding HTML-specific objects and methods.
Whereas the goal of DOM Level 1 was to map out the structure of a document, the aims of DOM Level 2 were much broader. This extension of the original DOM added support for mouse and user-interface events (long supported by DHTML), ranges, and traversals (methods to iterate over a DOM document), and support for Cascading Style Sheets (CSS) through object interfaces. The original DOM Core introduced in Level 1 was also extended to include support for XML namespaces.
DOM Level 2 introduced the following new modules of the DOM to deal with new types of interfaces:
- DOM views —Describes interfaces to keep track of the various views of a document (the document before and after CSS styling, for example)
- DOM events —Describes interfaces for events and event handling
- DOM style —Describes interfaces to deal with CSS-based styling of elements
- DOM traversal and range —Describes interfaces to traverse and manipulate a document tree
DOM Level 3 further extends the DOM with the introduction of methods to load and save documents in a uniform way (contained in a new module called DOM Load and Save) and methods to validate a document (DOM Validation). In Level 3, the DOM Core is extended to support all of XML 1.0, including XML Infoset, XPath, and XML Base.
Presently, the W3C no longer maintains the DOM as a set of levels, but rather as the DOM Living Standard, snapshots of which are termed DOM4. Among its introductions is the addition of Mutation Observers to replace Mutation Events.
When reading about the DOM, you may come across references to DOM Level 0. Note that there is no standard called DOM Level 0; it is simply a reference point in the history of the DOM. DOM Level 0 is considered to be the original DHTML supported in Internet Explorer 4.0 and Netscape Navigator 4.0.
Aside from the DOM Core and DOM HTML interfaces, several other languages have had their own DOM standards published. The languages in the following list are XML-based, and each DOM adds methods and interfaces unique to a particular language:
- Scalable Vector Graphics (SVG) 1.0
- Mathematical Markup Language (MathML) 1.0
- Synchronized Multimedia Integration Language (SMIL)
Additionally, other languages have developed their own DOM implementations, such as Mozilla's XML User Interface Language (XUL). However, only the languages in the preceding list are standard recommendations from W3C.
DOM Support in Web Browsers
The DOM had been a standard for some time before web browsers started implementing it. Internet Explorer made its first attempt with version 5, but it didn't have any realistic DOM support until version 5.5, when it implemented most of DOM Level 1. Internet Explorer didn't introduce new DOM functionality in versions 6 and 7, though version 8 introduced some bug fixes.
For Netscape, no DOM support existed until Netscape 6 (Mozilla 0.6.0) was introduced. After Netscape 7, Mozilla switched its development efforts to the Firefox browser. Firefox 3+ supports all of Level 1, nearly all of Level 2, and some parts of Level 3. (The goal of the Mozilla development team was to build a 100 percent standards-compliant browser, and their work paid off.)
DOM support became a huge priority for most browser vendors, and efforts have been ongoing to improve support with each release. The following table shows DOM support for popular browsers.
|Netscape Navigator 1.–4.x||—|
|Netscape 6+ (Mozilla 0.6.0+)||Level 1, Level 2 (almost all), Level 3 (partial)|
|Internet Explorer 2–4.x||—|
|Internet Explorer 5||Level 1 (minimal)|
|Internet Explorer 5.5–8||Level 1 (almost all)|
|Internet Explorer 9+||Level 1, Level 2, Level 3|
|Edge||Level 1, Level 2, Level 3|
|Opera 7–8.x||Level 1 (almost all), Level 2 (partial)|
|Opera 9–9.9||Level 1, Level 2 (almost all), Level 3 (partial)|
|Opera 10+||Level 1, Level 2, Level 3 (partial)|
|Safari 1.0.x||Level 1|
|Safari 2+||Level 1, Level 2 (partial), Level 3 (partial)|
|iOS Safari 3.2+||Level 1, Level 2 (partial), Level 3 (partial)|
|Chrome 1+||Level 1, Level 2 (partial), Level 3 (partial)|
|Firefox 1+||Level 1, Level 2 (almost all), Level 3 (partial)|
The content of this compatibility table is changing all the time and should only be used as a historical reference.
The Browser Object Model
- The capability to pop up new browser windows
- The capability to move, resize, and close browser windows
navigatorobject, which provides detailed information about the browser
locationobject, which gives detailed information about the page loaded in the browser
screenobject, which gives detailed information about the user's screen resolution
performanceobject, which gives detailed information about the browser's memory consumption, navigational behavior, and timing statistics
- Support for cookies
- Custom objects such as
XMLHttpRequestand Internet Explorer's
Because no standards existed for the BOM for a long time, each browser has its own implementation. There are some de facto standards, such as having a
window object and a
navigator object, but each browser defines its own properties and methods for these and other objects. With HTML5 now available, the implementation details of the BOM are expected to grow in a much more compatible way. A detailed discussion of the BOM is included in the chapter “Browser Object Model.”
|Netscape Navigator 2||1.0|
|Netscape Navigator 3||1.1|
|Netscape Navigator 4||1.2|
|Netscape Navigator 4.06||1.3|
|Netscape 6+ (Mozilla 0.6.0+)||1.5|
- ECMAScript, which is defined in ECMA-262 and provides the core functionality
- The Document Object Model (DOM), which provides methods and interfaces for working with the content of a web page
- The Browser Object Model (BOM), which provides methods and interfaces for interacting with the browser