Defining Event Handlers with SCRIPT

Defining Event Handlers with SCRIPT
You can include the handler for an event in an HTML document using the SCRIPT element. Each event handler needs a separate SCRIPT element. Here is an example of an event handler for a text box:

This example handles "OnChange" events for the INPUT element with the the value "edit1" for the NAME attribute. The EVENT attribute defines the event name. This is either one of the intrinsic events, or an event specific to this object. The FOR attribute is used to bind the handler to appropriate HTML elements. It uses the URL fragment identifier to provide a flexible means of addressing within HTML documents. It has the following syntax:
FOR = " URL#expression "
Typically the SCRIPT element is in the same document as the HTML elements it binds to. As a result the URL part is typically void. The expression is a URL fragment identifier with its syntax matching one of the following:
id:id-value
This is used when the script binds to a single HTML element. The element must have an ID attribute with a matching value.
field:field-name
This is used when the handler is to be used for one or more form fields with the same NAME attribute
field:form-name/field-name
When there are several forms in an HTML document, there may be a possibility of the same NAME value being used by both forms. This syntax allows you to prefix the field NAME by the corresponding name for the enclosing FORM element.
tag:tag-name
This is used when a handler is to be used with all elements with the same tag name
tag:tag-name/class-name
Similar to the above, but this syntax allows you to restict the handler to be used with those elements that belong to a given subclass. That is have matching CLASS values.
... a bunch of motivating examples are needed, either here or in a separate document ...
Parameter Passing
Most events are associated with one or more parameters. For some languages, for example HyperTalk, the parameters are passed via global variables (e.g. the mouse location is accessible via "the clickLoc"). This is problematic if the global variables are overwritten by subsequent events of the same type. Other languages require explit parameter lists. The type of a parameter may be implicit, according to its position in the list, or given explicitly as with C++. Some languages use tagged data that include type info within each parameter (e.g. Poplog).
(a) Implicit Parameters
With this approach, the names and types of parameters are implied by the event name. In the example below, button and location are implicit for all OnClick events: (b) Named ParametersWith this approach, the EVENT attribute includes a bracketed list of parameter names after the event name. The types of the parameters are implicit depending on the event name and position in the list. This also works well for languages with tagged data types, as then, the parameters carry their own type information. The above example becomes: (c) Typed ParametersWith this approach, typing information is included with the parameter names. The types need to be mapped to the typing system in use for each scripting language. The example becomes: For this approach to work, it seems like a standard syntax will be needed for typing information. Would the following be okay? param-name as type-nameWhere type-name is one of: integer, string, real, point, or object for a self typed object.