Re: DOM events Re: PROPOSAL: User Agent Issue 190:

hi all

At 2:41 AM 2/15/00, Charles McCathieNevile wrote:
>Cross posted to Protocols & Formats and User Agent groups
>
>I think we should take a step back and look carefully at this again.

Charles, I agree that we need to step back and look carefully at this
again, and yes it is frustrating.  However, I'm now concerned that
we only have half of the puzzle.  Creating a device independent
event model (as per below) and then placing it inside DOM is a mistake in my
mind.  Especially without evaluating all the other options, and
conerns.    The i18n group weighed in heavily at the end of DOM2
in regards to the keyboard events, for example.


>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.


If we ever hope to control scripts or make them accessible, I think we need
to look at maintaining some separation between the data (content) and the
UI.  This will grow in importance as dynamic UI continue to
flourish.  Some of the following articles review the tradeoffs, and
I would hope the DOM group would at least consider these issues
as they move ahead with DOM 3.

http://webreview.com/pub/1999/06/18/feature/index.html
http://www.mozilla.org/xpfe/xulrdf.htm


>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.

Actually, I think you mean to say that the basic requirement is to make the
interactions that the user can have, defined by the *user needs or abilities*,
and to a lesser degree, perhaps by the device capability, not by content.
The content as I
think of content, is just "data".   The content or "data" of a spreadsheet
doesn't change, whether I view the entire spreadsheet visually on a monitor
all a once, whether my low-vision co-worker views a magnified view
of only one row/column at a time, whether another co-worker at the
customer site views the same one row/column view on their limited
screen sized Palm Pilot, and whether another co-worker listens to an
audio or feels a tactile representation of the speadsheet, since they are
blind.  The
content (data) has not changed.  However, each users' view and ability
to interface (control, input events)to  their view (e.g., visual, audio,
tactile, etc.) is
based on the user needs or abilities, and to a lesser degree, perhaps by the
device capability.

mark

>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 12:09:26 UTC