The history of JavaScript

JavaScript is a lightweight object-based scripting language created by Netscape Communications Corporation for developing Internet applications. JavaScript is lightweight in that there isn't a great deal to learn and you can be productive with it very quickly, in contrast to much more complex languages such as Java. As a scripting language, JavaScript is meant to tell an application what to do. Unlike languages used to create applications, it cannot do anything without the application.
You can develop server applications or client applications with JavaScript. In this book, the term "server" refers to the computer where your Web pages reside. The term "client" refers to the browser application that loads and displays your Web pages. This book focuses on teaching you to create client applications with JavaScript-specifically, documents (Web pages) on the World Wide Web.
You can embed JavaScript statements in Web pages, which are written in HTML (Hypertext Markup Language). JavaScript is an extension to HTML that lets you create more sophisticated Web pages than you ever could with HTML alone. To appreciate this, it helps to know a little history.

The history of JavaScript

Strictly speaking, HTML is a Standard Generalized Markup Language (SGML), Document Type Definition (DTD). An SGML document has three parts. The first part defines the character set to be used and tells which characters in that set distinguish text from markup tags. Markup tags specify how the viewer application, or browser, should present the text to the user. The second part of an SGML document specifies the document type and states which markup tags are legal. The third part of an SGML document, called the document instance, contains the actual text and markup tags. Because there is no requirement that the three parts of an SGML document reside in the same physical file, we can concentrate on the document instance. The Web pages you create are document instances.
Most HTML browsers assume a common definition about the character set used, and about which characters distinguish text from markup tags. They also generally agree about a core set of legal markup tags. They then diverge on which additional new markup tags to permit.

HTML 1.0 and 2.0

HTML 1.0 refers to the original set of markup tags. HTML 1.0 is so limited that a browser that restricted HTML documents to HTML 1.0 would be a museum piece.
HTML 2.0 includes a more generous set of markup tags than HTML 1.0; in particular, it allows markup tags that define user input fields. As of this writing, HTML 2.0 defines the de facto common core of markup tags. You can create a relatively sophisticated Web page with HTML 2.0 markup tags.

HTML 3.0 and NHTML

HTML 3.0, still in the process of standardization, adds additional markup tags to those defined in HTML 2.0, such as tags to define tables, figures, and mathematical equations. HTML 3.0 expands some tags to include more functionality, such as centering text or images in the browser, and adding background colors and images.
NHTML, a nickname for Netscape's extension of HTML 2.0, is another set of markup tags that goes beyond those defined in HTML 2.0. Netscape, like other developers of cutting edge Web browsers, is trying to influence the development of the HTML 3.0 standard, and has developed extensions of its own. At the same time, Netscape is making an effort to conform to the evolving HTML 3.0 specification. Furthermore, Netscape continues to support markup tags that the draft HTML 3.0 specification has declared obsolete.
Netscape's browser, Netscape Navigator, is not precisely HTML 3.0-compliant. The best way to find out whether Netscape Navigator supports a particular markup tag is to get the latest version and try a document containing the tag.

Why NHTML isn't proper SGML

Formally, a Web page is the third part of an SGML DTD, and as such, should conform to the SGML DTD specification.
A few features of NHTML do not conform to the rules of the SGML DTD specification. If browsers actually treated a Web page as the third part of an SGML DTD, this would be a problem. However, browsers typically accept a certain hard-coded level of HTML-typically HTML 2.0 with some HTML 3.0 extensions and some NHTML extensions-and ignore markup tags that they do not recognize.
Where this nonconformity does present a problem is in writing tools that validate Web pages. These tools typically use an SGML parser, and they require a page to be part of a properly conforming SGML DTD for the level of HTML they check.
Should you validate your Web pages? I think so, although as of this writing, it's not a viable option for JavaScript pages. So far, no one has come up with a validation tool that recognizes and validates the syntax of JavaScript. But count on it; someone will. And when they do, try it on your pages. Validation tools have saved me countless hours of headaches trying to figure out why my HTML code wasn't working correctly.
Just for the record, here are the nonconforming parts of NHTML:

• NHTML makes liberal use of the % character. It's used to specify that certain entities occupy a fixed percentage of the window's real estate, or to specify scaling on images. The problem with this is that the % character is a reserved character in the SGML specification for declaring parameter entities in a DTD. It does not belong in a Web page. There is no workaround to achieve the same effect. An SGML parser-based validation tool will not accept pages with % characters in the attributes.
• NHTML allows the BORDER attribute to be specified in two ways:
  <TABLE BORDER>and
  <TABLE BORDER="1">The SGML DTD specification does not allow an attribute to be specified in two entirely different fashions like this. While a grammatically correct SGML DTD cannot handle both forms simultaneously, a grammatically correct SGML DTD can handle either form. Since BORDER alone means the same thing as BORDER="1", BORDER alone is redundant, and you can write a DTD that says the BORDER attribute always takes a numeric argument. From the standpoint of making your pages clear and easy to maintain, it's always a good idea to state the border size explicitly.
• SGML parsers will not accept tags like <FONT SIZE=+3> and <FONT SIZE=-2>. Fortunately, this one is easy to work around: Place the value in double quotes, like this:
  <FONT SIZE="+3">and
  <FONT SIZE="-2">
• Color attributes specified as six-digit hexadecimal values will not pass an SGML parser if written like this:
  <BODY BGCOLOR=#123456>As with the incremented or decremented font sizes, you can fix this problem by placing the offending value inside double quotes.
  <BODY BGCOLOR="#123456">