WD-layout-960608
WD-layout-960608This 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.
<!-- 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:
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?
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">
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>")
</script>
Has the same effect as the document:
<title>Test Document</title>
<p><em>Hello World!</em>
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()
Begin
If edit1.value = "abc" Then
button1.enabled = True
Else
button1.enabled = False
End If
End Sub
</SCRIPT>
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.
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.
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()}"
VALUE="0">
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.
<!ATTLIST SELECT
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 (< and & respectively).
This extends the OBJECT specification as defined in http://www.w3. org/pub/WWW/TR/WD-object.html.
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).
For an INPUT, TEXTAREA or SELECT element to be considered as part of a form, when submitting the form's contents:
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.
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:
<SCRIPT LANGUAGE="JavaScript">
<!-- 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 -->
</SCRIPT>
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:
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.
The World Wide Web Consortium:
http://www.w3.org/