DOM events Re: PROPOSAL: User Agent Issue 190:

Cross posted to Protocols & Formats and User Agent groups

I think we should take a step back and look carefully at this again.

Implementing an event model is important if we accept that the web that is
moving into the future is going to rely on scripting and dynamic
effects. Although there will be a requirement for some time to come that it
be possible to use the web without these things, I believe that by ignoring
them altogether we are hiding our heads in the sand - we must work out how
to make them accessible.

The basic requirement is to make the interactions that the user can have, as
defined by the content itself, available to the user without requirement for
a specific type of hardware interface. For example, relying on the presence
of a mouse, or of a visual display of a certain size, is unreasonable.

In HTML terms, what is required is that the User Agent provide some mechanism
to programmatically trigger the event trigger attributes, and that that
function is also available in a device-independent manner to the greatest
extent possible.

One approach to this is to look at the new DOM event set, and map the current
HTML towards that set. (For a note on why this is a good idea, read the
original HTML 4.0 specification at the relevant point...)

Here is a possible way to handle the events:

onClick, onDblClick, onKeyPress, onKeyDown, onKeyUp can all be mapped to the
new onActivate, using a parameter where appropriate. I would suggest that the
value of the parameter be numeric, and that we require of the DOM group that
this event be able to take sufficient parameters to encompass a multiple
click, or differentiating between some number of different keys (I would
suggest that 10 is a better number than 2, for example)

onMouseOver, onFocus be merged to the new equivalent, and similarly with
onMouseOut and OnBlur.

onMouseMove is a bit tricky. Where mouse things are used with X,Y parameters
there is some careful thinking needed to work in a non-visual space - in some
cases a more object-oriented approach will solve the problem (this is a Web
Content Question), but there are cases where it is just very difficult - the
same problem that arises in trying to deal with raster-based graphics.

I think the rest of the events can stay as they are. Gregory has already
pointed to the potential problems raised by ill-considered use of mutation
events such as onChange for submitting forms, and in any event that does not
rely on a particular type of user interface.

To a certain extent this is going over old ground. Which I find extremely
frustrating, but think is pretty important and we still need to get it right.

Charles McCN

On Mon, 14 Feb 2000 schwer@us.ibm.com wrote:

  
  
  
  This is why we were pushing the DOM2 event model as P2.
  
  It is unrealistic to expect the DOM WG to scrap their entire event model
  for accessibility. We should be able to improve upon it in terms of device
  independence. Having people start developing to the DOM 2 event model will
  not require them to rewrite the whole thing.
  
  I do appreciate your concerns.
  
  Rich

Received on Tuesday, 15 February 2000 02:41:35 UTC