Date: Thu, 17 Jul 1997 06:17:26 -0700 (PDT) Message-Id: <199707171317.GAA13497@norway.it.earthlink.net> To: Chris Ridd <C.Ridd@isode.com> From: Shelley Powers <email@example.com> Subject: Re: HTML 4.0 events and DOM requirements draft Cc: firstname.lastname@example.org > >An alternate possibility is to use the <PARAM> element, as used in ><APPLET>. > ><A HREF="/"> ><PARAM NAME=onclick ACTION="foo()"> ><PARAM NAME=onmouseenter ACTION="bar()">Foo bar</A> > >Chris > 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 events? 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 ============================================================= Shelley Powers YASD email@example.com http://www.yasd.com http://www.dynamicearth.com IDG Books Professional Series book on Dynamic HTML, authored by Shelley Powers. Out early Fall.