WD-script-960614
WD-script-960614This 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.
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 -->
<!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 --
>
The content model for the SCRIPT element is defined as CDATA. In this kind of element, only one delimiter is recognized by a conforming parser: the end tag open (ETAGO) delimiter (i.e. the string "</"). The recognition of this delimiter is constrained to occur only when immediately followed by an SGML name start character ([a-zA-Z]). All characters which occur between the SCRIPT start tag and the first occurrence of ETAGO in such a context must be provided to the appropriate script engine.
Note that all other SGML markup (such as comments, marked sections, etc.) appearing inside a SCRIPT element are construed to be actual character content of the SCRIPT element and not parsed as markup. A particular script engine may choose to treat such markup as it wishes; however a script engine should document such treatment.
The restriction on appearance of the ETAGO delimiter may cause problems with script code which wishes to construct HTML content in the code. For example, the following code is invalid due the to presence of the "</EM>" characters found inside of the SCRIPT element:
<SCRIPT type="text/javascript">
document.write ("<EM>This won't work</EM>")
</SCRIPT>
A conforming parser would treat the "</EM>" data as an end tag and complain that it was an end tag for an element not opened, or perhaps actually close an open element. In any case, it is recognized as markup and not as data.
In JavaScript, this code can be expressed legally as follows by ensuring that the apparent ETAGO delimiter does not appear immediately before an SGML name start character:
<SCRIPT type="text/javascript">
document.write ("<EM>This will work</" + "EM>")
</SCRIPT>
Each scripting language should recommend language specific support for resolving this issue.
The following describe the attributes used with SCRIPT elements, all of which are optional:
Is there a need to be able to directly embed scripts using byte code data? This could be supported via an ENCODING attribute with values restricted to say: BASE64 or TEXT, with TEXT as the default (as specified by the document character set).
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?
The default scripting language in the absence of TYPE or LANGUAGE attributes can be specified by the HTTP header Content-Script-Language in the server response, for example:
Content-Script-Language: text/tcl
If this is absent, the default can be set by a META element in the document HEAD, for example:
<META HTTP-EQUIV="Content-Script-Language" CONTENT="text/tcl">
where the CONTENT attribute specifies the media type for the scripting language, and the HTTP-EQUIV attribute is the literal string "Content-Script-Language".
In the absence of an HTTP Content-Script-Language header or a corresponding META element, the default is assumed to be JavaScript.
Which should take precedence: the HTTP header or the META element? What if there are several such headers or META elements? What about using the scripting language used by the preceding SCRIPT element if any?
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>
From the perspective of SGML, each such insertion of content can be modelled as a two-step process: (1) dynamically defining an anonymous CDATA entity; and (2) immediately referencing the entity. A compliant SGML parser may operate in these circumstances only as long as the point of reference of such an entity is well-defined. Accordingly, the semantics of such side-effects are restricted to occur (1) immediately prior to processing the Ee (end of entity) for the original document entity; and (2) sequentially with respect to the execution of script code. If more that one script thread is executing at once, then the result of such side-effects are undefined.
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>
Examples from other languages are desired, how about tcl?
Scripting engines are responsible for binding object references in scripts to objects associated with documents. Script engines may support more than one language. This allows handlers to be written in one language, and the event binding to be defined in another, thereby avoiding the limitations of particular languages.
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 reference 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, while NAME attributes for elements defining form fields are limited in scope to the enclosing FORM element.
Scripting systems may allow authors to script objects that occur within an object associated with an OBJECT or IMG element. Document frames allow one document to be nested in another. Script handlers could be placed in a parent document and used to control the behaviour of a child document. Scripts may also be used for objects external to documents, such as the user agent or other applications. A particularly simple form of scripting is to just wire up objects that source events with ones that sink events. One event may 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, objects associated with form elements with matching NAME values may be sought in preference to elements with matching ID values.
Some scripting languages, such as VBScript, limit the scope of references to a given module, but don't provide language specific means for defining modules. If a module is associated with an HTML document then element ID values can be used for binding handlers to objects. If the module is associated with an HTML form, then form field NAME attribute values can be unambigously used by the script engine to bind handlers to objects by placing the handlers in a SCRIPT element within the associated FORM element.
Note Can't we agree to allow a scripting language dependent module name to be specified as an HTML attribute on SCRIPT? This would be passed to the script engine for interpretation. This would allow scripting engines to bind module names to FORM or OBJECT elements etc. as well as to documents in associated frames. I would like to propose a SCOPE attribute for this purpose.
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 default scripting language as specified above for the SCRIPT element.
The script attributes for intrinsic events are defined as CDATA. The SGML processing of CDATA attribute values requires that (1) entity replacement occur within the attribute value; and (2) that the attribute value be delimited by the appearence LIT ('"') or LITA ('\''). The literal delimiter which terminates the attribute value must be the same as the delimited used to initiate the attribute value. Given these lexical restrictions, the delimiters LIT or LITA, ERO (entity reference open - '&'), and CRO (character reference open - "&#") may not freely occur as script code within a scriptlet. To resolve this issue, it is recommended that scriptlet attributes always use LIT delimiters and that occurrences of '"' and '&' inside a scriptlet be written as follows:
'"' should be written as """ or as """
'&' should be written as "&" or as "&"
The following is an example of how intrinsic events are specified in the HTML document type definition:
<!ATTLIST SELECT
name CDATA #REQUIRED
size NUMBER #IMPLIED
multiple (multiple) #IMPLIED
onfocus CDATA #IMPLIED
onblur CDATA #IMPLIED
onchange CDATA #IMPLIED
>
The complete set of intrinsic events are listed below together with the HTML elements they can be used with.
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 both of the following conditions must apply:
If either of these two conditions are not met, then the field is not treated as being 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. Some scripting engines for languages such as JavaScript and VBScript allow the script statements to be enclosed 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>
Note that Netscape Navigator 2.0 and above hides the contents of script elements provided no (non-white) text occurs before the element, except within the TITLE element.
The World Wide Web Consortium:
http://www.w3.org/