W3C: WD-layout-960608

Client-side Scripting and HTML

W3C Working Draft 12-Jun-1996

This version:
Latest version:
Dave Raggett <dsr@w3.org>

Status of this document

This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C working drafts can be found at: http://www.w3.org/pub/WWW/TR

Note: since working drafts are subject to frequent change, you are advised to reference the above URL, rather than the URLs for working drafts themselves.


The HyperText Markup Language (HTML) is a simple markup language used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of applications. This specification extends HTML to support locally executable scripts including JavaScript, VBScript, and other scripting languages and systems. Richer means for binding events are anticipated in future revisions to this specification.


This specification extends HTML to support client-side scripting of HTML documents and objects embedded within HTML documents. Scripts can be supplied in separate files or embedded directly within HTML documents in a manner independent of the scripting language. Scripts allow HTML forms to process input as it is entered: to ensure that values conform to specified patterns, to check consistency between fields and to compute derived fields.

Scripts can also be used to simplify authoring of active documents. The behaviour of objects inserted into HTML documents can be tailored with scripts that respond to events generated by such objects. This enables authors to create compelling and powerful web content. This specification covers extensions to HTML needed for client-side scripting, but leaves out the architectural and application programming interface issues for how scripting engines are implemented and how they communicate with the document and other objects on the same page.

The SCRIPT Element

<!-- SCRIPT is a character-like element for embedding script code
      that can be placed anywhere in the document HEAD or BODY -->
<!ENTITY % Event "CDATA" -- event name and optional param list -->
<!ELEMENT script - - CDATA>
<!ATTLIST script
	type         CDATA    #IMPLIED -- media type for script language --
        language     CDATA    #IMPLIED -- predefined script language name --
        src          %URL     #IMPLIED -- URL for an external script --

Note that SCRIPT has "CDATA" as its content model. This means that characters like < and & can be used as is and are passed by the parser to the script engine uninterpreted.

The following describe the attributes used with SCRIPT elements:

The Internet media type specifying the scripting language, for instance: type="text/javascript" or type="text/vbscript". Using text as the primary media type has the advantage of allowing people to view scripts as text files. An alternative would be to register "script/tcl" or "application/python" etc.
Names the scripting language using well known identifiers, for instance "JavaScript" or "VBScript". This attribute is deprecated in favor of the TYPE attribute.
The optional SRC attribute gives a URL for an external script. The external script takes precedence over scripting statements defined between the start and end tags for the script element.

HTML documents can include multiple SCRIPT elements which can be placed in the document HEAD or BODY. This allows script statements for a form to be placed near to the corresponding FORM element. Note that because script statements are evaluated when the document is loaded, attempts to reference objects will fail if these objects are defined by HTML elements which occur later in the document.

Is this true or is execution of SCRIPT elements deferred until the whole of the document has been retrieved, included embedded objects?

Default Scripting Language

In the absence of TYPE or LANGUAGE attributes the, the default scripting language is assumed to be JavaScript, unless set using the META element, as in:

    <META HTTP-EQUIV="Content-Script-Language" CONTENT="Tcl">

Self-Modifying Documents

Some scripting languages permit script statements to be used to modify the document as it is being parsed. For instance, the HTML document:

    <title>Test Document</title>
    <script type="text/javascript">
        document.write("<p><em>Hello World!</em>")

Has the same effect as the document:

    <title>Test Document</title>
    <p><em>Hello World!</em>

Defining Event Handlers with SCRIPT

You can include the handler for an event in an HTML document using the SCRIPT element. Here is an example of an event handler for a text field:

    <INPUT NAME=edit1 size=50>    
    <SCRIPT TYPE="text/vbscript>
      Sub edit1_changed()
        If edit1.value = "abc" Then
          button1.enabled = True
          button1.enabled = False
        End If
      End Sub

Some scripting languages like VBScript provide language conventions for binding objects that source events to script functions that handle events. Other languages typically allow you a run-time mechanism to set up such bindings, e.g. to register call-backs, or a way to poll for events and dispatch them to appropriate handlers.

Scoping of Object Names

How do scripts identify objects? In many cases objects associated with HTML elements such as form fields can be identified by virtue of the document markup, e.g. the tag names and attribute values. HTML ID attributes provide identifiers that are unique throughout a given document. NAME attributes on form fields, on the other hand, are limited in scope to the FORM element containing them.

Authors will want to name objects within objects embedded as part of HTML documents using tags like IMG and OBJECT. You may also want to name objects in parent frames, when a frame contains a nested document, or external objects such as the browser or even other applications. A particularly simple form of scripting is to just wire up objects that source events with ones that sink events. One event my be multicast to several recipient objects.

One way to deal with naming is to introduce language specific naming conventions, e.g. "document.form1.button1" as used by JavaScript. Another is to rely on the context in which a SCRIPT element is located to guide search for a named object. For instance, if the SCRIPT element is within a FORM element, then object names matching field NAMES are sought in preference to matching ID values.

Some scripting languages provide modules with names limited in scope to a module. This suggests the possibility to specifying the scope as an attribute of the SCRIPT element when this isn't supported by the scripting language itself. A general solution for dealing with object names is outside the scope of this specification.

Intrinsic Events

A number of common events can be handled using attributes placed on the HTML elements associated with the object generating the event. The attribute names for intrinsic events are case insensitive. The attribute value is a scripting language dependent string, known as a "scriptlet". It gives one or more scripting instructions to be executed whenever the corresponding event occurs.

In the following example, userName is a required text field. When a user attempts to leave the field, the OnBlur event calls a JavaScript function to confirm that userName has an acceptable value.

    <INPUT NAME="userName" OnBlur="validUserName(this.value)">

Here is another JavaScript example:

    <INPUT NAME="num"
        OnChange="if (!checkNum(this.value, 1, 10)) 
            {this.focus();this.select();} else {thanks()}"

The scripting language assumed for intrinsic events is determined by the most recent SCRIPT element, preceding the element in which the event handler attribute occurs. The default scripting language is assumed to be JavaScript, but can be set using the META element, e.g.

    <META HTTP-EQUIV="Content-Script-Language" CONTENT="Tcl">

The complete set of intrinsic events are listed below together with all of the HTML elements they can be used with. The attribute values for intrinsic events are defined as SGML CDATA values, e.g.

        name        CDATA       #REQUIRED
        size        NUMBER      #IMPLIED
        multiple   (multiple)   #IMPLIED
	onfocus     CDATA       #IMPLIED
	onblur      CDATA       #IMPLIED
        onchange    CDATA       #IMPLIED

As a result special characters like < and & need to be escaped as SGML entities (&lt; and &amp; respectively).

A load event occurs when the browser finishes loading a window or all frames within a <FRAMESET>. The OnLoad event handler executes the scriptlet when a load event occurs. Can be used only with BODY or FRAMESET elements.
An unload event occurs when you exit a document. The OnUnload event handler executes the scriptlet when an unload event occurs. Can be used only with BODY or FRAMESET elements.
A click event occurs when an anchor or form field is clicked. The onClick event handler executes the scriptlet when a click event occurs. This event is generated by buttons, checkboxes, radio buttons, hypertext links, reset and submit buttons, and can only be used with INPUT, and anchor elements.
This event is sent as the mouse is moved over an anchor. This attribute can only be used with anchor elements.
A focus event occurs when a field gains the input focus by tabbing or clicking with the mouse. Selecting within a field results in a select event, not a focus event. This attribute is used only with the SELECT, INPUT and TEXTAREA elements.
A blur event occurs when a form field loses the input focus. This attribute is used only with the SELECT, INPUT and TEXTAREA elements.
A submit event occurs when a user submits a form. This may be used to control whether the form's contents are actually submitted or not. For instance, JavaScript won't submit the form if a scriptlet for the OnSubmit event returns false. This attribute can only be used with the FORM element.
A select event occurs when a user selects some of the text within a single or multi-line text field. This attribute can only be used with the INPUT and TEXTAREA elements.
A change event occurs when a form field loses the input focus and its value has been modified. This attribute can only be used with the SELECT, INPUT and TEXTAREA elements.

Using OBJECT elements as Form Fields

This extends the OBJECT specification as defined in http://www.w3. org/pub/WWW/TR/WD-object.html.

The NAME attribute - CDATA

The NAME attribute allows an OBJECT element to act as a new kind of HTML form field. NAME indicates that the VALUE property of the object defined by this OBJECT is to be used as part of the submit process. If NAME were absent the object would be treated as though it were not actually part of the form (even though it may have appeared within a FORM block).

Using form fields without a NAME attribute

For an INPUT, TEXTAREA or SELECT element to be considered as part of a form, when submitting the form's contents:

  1. The element must have a NAME attribute.
  2. The element must be contained by a FORM element.

If either of these two conditions are not met, then the field isn't treated as part of a form. This allows fields such as text fields and buttons to be used together with scripting to build user interfaces independent of the role of these elements for forms.

Deployment Issues

Authors may wish to design their HTML documents to be viewable on older browsers that don't recognise the SCRIPT element. Unfortunately any script statements placed within a SCRIPT element will be visible to users. One solution is to enclose the script statements in an SGML comment, for instance:

<!--  to hide script contents from old browsers
  function square(i) {
    document.write("The call passed ", i ," to the function.","<BR>")
    return i * i
  document.write("The function returned ",square(5),".")
// end hiding contents from old browsers  -->

Further Work

This specification defines some extensions to HTML needed to support scripting. To ensure that scripts and plug-ins work smoothly with browser implementations from different vendors, specifications for application programming interfaces (APIs) are needed for:

  1. How User Agents communicate with document objects
  2. How User Agents communicate with Scripting Engines
  3. How Objects and Scripts can identify and send messages to other objects on the same document
  4. Platform independent properties and events for common objects

It may be worth developing a language and platform independent API for this based on an interface definition language. For now, this is left to vendors for individual scripting languages and user agents.

Another area for further work is defining a more complete set of "intrinsic" objects, methods, and events than is currently proposed.


Internet Media Types - RFC 1590
J. Postel. "Media Type Registration Procedure." RFC 1590, USC/ISI, March 1994. This can be found at ftp://ds.internic. net/rfc/rfc1590.txt.
MIME - RFC 1521
Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993. This can be found at ftp://ds.internic. net/rfc/rfc1521.txt
SGML Marked Sections
Dan Connelly has a paper on the use of SGML Marked Sections at http://www.w3. org/pub/WWW/MarkUp/WD-doctypes. And the TEI also has information: http://www.ebt. com/usrbooks/teip3/2404.
The Component Object Model specification
This is available from http://www. microsoft.com/intdev/inttech/comintro.htm.
ActiveX Scripting
An introduction to ActiveX(tm) Scripting is available from http://www.microsoft. com/intdev/sdk/
This is available from http://www.csn.net/MetaCard/mtd.html
An overview is available from http://home.netscape.com/eng/mozilla/Gold/handbook/javascript/index.html
Visual Basic Script
An overview is available from http://www.microsoft.com/vbscript/default.htm
Find information on the Python language at http://www.python.org/

W3C: The World Wide Web Consortium: http://www.w3.org/