Re: HTML 4.0 events and DOM requirements draft

Shelley Powers (
Thu, 17 Jul 1997 06:17:26 -0700 (PDT)

Date: Thu, 17 Jul 1997 06:17:26 -0700 (PDT)
Message-Id: <>
To: Chris Ridd <>
From: Shelley Powers <>
Subject: Re: HTML 4.0 events and DOM requirements draft

>An alternate possibility is to use the <PARAM> element, as used in 
><A HREF="/">
><PARAM NAME=onclick ACTION="foo()">
><PARAM NAME=onmouseenter ACTION="bar()">Foo bar</A>

I prefer this alternative then to litter EACH of the HTML tags with a list
of ever-changing event handlers. It would be more inconvenient for web page
authors and developers but new releases of the HTML spec, or browsers
extending the list of events are inconvenient, also. Another approach could
be similar to the one for CSS1: one attribute for events such as EVENT and
then, within parens, a listing of events and their event handlers.

My preference, though, would be to not list anything with the tags, and have
event trapping occur within the script. MS supports something like this
using two different approaches, though neither is the best approach, and one
approach is for VBScript only. Netscape uses an actual event capturing
mechanism which I like, but which needs to be extended to cover all the
impacted HTML elements and extended to handle events for specific tags.

With this, event trapping can be enclosed within a script block and can be
hidden. Then, I can use something like drgdrp for one browser and a
combination of mouseup and checking for button and source element for
another, and the HTML spec won't get into business of determining how user
agents(browsers) implement event trapping. Additionally, I can trap an event
in one scripting block for one user agent, and not have to code a dummy
event handler for another user agent. And I can place scripting into one
area, rather than be scattered all over. 

Following from CSS1, global event handlers can be handled within script
blocks, or linked in from external sources. Specific events for specific
items can be handled within these blocks, or inline using something like the
EVENT= attribute. With this approach, making change to a global event
handler, such as adding an argument to a function that is used by the
onsubmit event for several forms across several pages would only need to
occur in one place. Works for CSS1, why not be consistent and apply it to

This would mean listing inline event handlers and probably deprecating them,
to provide a means of backward compatibility while authors/developers (and
the tools) make the switch over to the new technique.

Event handling should be handled within DOM working group, not the HTML
group.  Event trapping is not a markup language issue, it is an object model
issue. Unfortunately, it was forced into this realm with the use of inline
event handlers.

Shelley Powers       YASD

IDG Books Professional Series book on Dynamic HTML, authored by 
Shelley Powers. Out early Fall.