Client-side JavaScript

From Seo Wiki - Search Engine Optimization and Programming Languages

Jump to: navigation, search

Client-side JavaScript (CSJS) is JavaScript that runs on client-side. While JavaScript was originally created to run on client-side, this term was coined because the language is no longer limited to just client-side, e.g. server-side JavaScript (SSJS) is also available.



One Internet media type for JavaScript source code is application/javascript, which was registered in 2006, however Internet Explorer, including versions 6 through 8, ignores scripts with the attribute type="application/javascript". The HTML 4.01 and HTML 5 specifications mention text/javascript, which is supported by all major browsers and is more commonly used. When the type attribute is not specified in a script tag, the type value is by default "text/javascript" per HTML 5 specification.

To embed JavaScript code in an HTML document, it must be preceded with the Template:Tag tag and followed with Template:Tag (possible attribute options omitted).

Older browsers typically require JavaScript to begin with:

<script language="JavaScript" type="text/javascript">

and end with:

// -->

The <!-- ... --> comment markup is required in order to ensure that the code is not rendered as text by very old browsers which do not recognize the <script> tag in HTML documents (although script-tags contained within the head-tag will never be rendered, thus the comment markup is not always necessary), and the LANGUAGE attribute is a deprecated HTML attribute which may be required for old browsers. However, <script> tags in XHTML/XML documents will not work if commented out, as conformant XHTML/XML parsers ignore comments and also may encounter problems with --, < and > signs in scripts (for example, the integer decrement operator and the comparison operators). XHTML documents should therefore have scripts included as XML CDATA sections, by preceding them with

<script type="text/javascript">

and following them with


(A double-slash // at the start of a line marks a JavaScript comment, which prevents the <![CDATA[ and ]]> from being parsed by the script.)

The easiest way to avoid this problem (and also as a best practice) is to use external script, e.g.:

<script type="text/javascript" src="hello.js"></script>

Historically, a non-standard (non-W3C) attribute language is used in the following context:

<script language="JavaScript" src="hello.js"></script>

HTML elements [1] may contain intrinsic events to which you can associate a script handler. To write valid HTML 4.01, the web server should return a 'Content-Script-Type' with value 'text/javascript'. If the web server cannot be so configured, the website author can optionally insert the following declaration for the default scripting language in the header section of the document.

<meta http-equiv="Content-Script-Type" content="text/javascript" />

Hello World example

For an explanation of the tradition of programming "Hello World", as well as alternatives to this simplest example, see Hello world program.

This is the easiest method for a Hello world program that involves using popular browsers' support for the virtual 'javascript' protocol to execute JavaScript code. Enter the following as an Internet address (usually by pasting into the address box):

javascript:alert('Hello, world!');

DOM binding

User interaction

Most interaction with the user is done by using HTML forms which can be accessed through the HTML DOM. However there are also some very simple means of communicating with the user:


Element nodes may be the source of various events which can cause an action if a JavaScript event handler is registered. These event handler functions are often defined as anonymous functions directly within the element node.

See also DOM Events and XML Events.


Note: Most incompatibilities are not JavaScript issues but Document Object Model (DOM) specific. The JavaScript implementations of the most popular web browsers usually adhere to the ECMAScript standard, such that most incompatibilities are part of the DOM implementation. Some incompatibility issues that exist across JavaScript implementations include the handling of certain primitive values like "undefined", and the availability of methods introduced in later versions of ECMAScript, such as the .pop(), .push(), .shift(), and .unshift() methods of arrays.

JavaScript, like HTML, is often not compliant to standards, instead being built to work with specific web browsers. The current ECMAScript standard should be the base for all JavaScript implementations in theory, but in practice the Mozilla family of browsers (Mozilla, Firefox and Netscape Navigator) use JavaScript, Microsoft Internet Explorer uses JScript, and other browsers such as Opera and Safari use other ECMAScript implementations, often with additional nonstandard properties to allow compatibility with JavaScript and JScript.

JavaScript and JScript contain several properties which are not part of the official ECMAScript standard, and may also miss several properties. As such, they are in points incompatible, which requires script authors to work around these bugs. JavaScript is more standards-compliant than Microsoft's JScript, which means that a script file written according to the ECMA standards is less likely to work on browsers based on Internet Explorer. However, since there are relatively few points of nonconformance, this is very unlikely.

This also means every browser may treat the same script differently, and what works for one browser may fail in another browser, or even in a different version of the same browser. As with HTML, it is thus advisable to write standards-compliant code.

Combating incompatibilities

There are two primary techniques for handling incompatibilities: browser sniffing and object detection. When there were only two browsers that had scripting capabilities (Netscape and Internet Explorer), browser sniffing was the most popular technique. By testing a number of "client" properties, that returned information on computer platform, browser, and versions, it was possible for a scripter's code to discern exactly which browser the code was being executed in. Later, the techniques for sniffing became more difficult to implement, as Internet Explorer began to "spoof" its client information, that is, to provide browser information that was increasingly inaccurate (the reasons why Microsoft did this are often disputed). Later still, browser sniffing became something of a difficult art form, as other scriptable browsers came onto the market, each with its own platform, client, and version information.

Object detection relies on testing for the existence of a property of an object.

function set_image_source ( imageName, imageURL )
    if ( document.images ) // a test to discern if the 'document' object has a property called 'images' which value type-converts to boolean true (as object references do)
        document.images[imageName].src = imageURL; // only executed if there is an 'images' collection

A more complex example relies on using joined boolean tests:

 if ( document.body && )

In the above, the statement "" would ordinarily cause an error in a browser that does not have a "document.body" property, but using the boolean operator "&&" ensures that "" is never called if "document.body" doesn't exist. This technique is called minimal evaluation.

Today, a combination of browser sniffing, object detection, and reliance on standards such as the ECMAScript specification and Cascading Style Sheets are all used to varying degrees to try to ensure that a user never sees a JavaScript error message.


See also

External links




Cooperation with

Personal tools

Served in 0.399 secs.