ISSUE-33: Multiple devices generating events

As the request to get suggestions from the MMI WG didn't get any  
answer (see
http://lists.w3.org/Archives/Public/public-webapi/2006Feb/0131), here  
are some
personal thoughts to deal with ACTION-86 in order to move forward for a
resolution of ISSUE-33.

These thoughts have partly be inspired by some discussions raised by  
ISSUE-30
about the mousewheel event, which led to some interesting  
contributions about
the relationships between device events and semantic (or UA) events.

In my opinion, some of the difficulties in defining event naming and  
event
propagation are that DOM3EV deals with three different levels and  
with two
mappings between these levels which can be summarized as:

device event ----(1)-----> DOM Event <----(2)----> UA targets and  
actions

The mapping (1) is mostly implicit and based on a kind of abstract  
device model
which is:

- 1 pointing device like a mouse (continuous absolute x and y, 2D)
- 1 wheel device (continuous relative, 1D)
- 1 keyboard (discrete)

The mapping (2) is explicit and constitutes a part of the DOM Event  
model
specification. It defines mappings between DOM Event names, such as  
mouseover or
scroll, and UA actions like visual state change and/or internal state  
changes
and side effects. The mapping (2) also defines means to cancel event  
propagation
and to prevent actions. The mapping (2) is bidirectional as some of  
event flows
initiated from a device (eg. Tab keypress) can lead to a change in  
the UA state
that results in a new DOM Event (eg. focus/blur) which itself will  
result in a
change in the UA state (eg. current focused element highlighting).

In case of new devices or multiple devices (ie. devices that go  
beyond the
abstract device model), my opinion is that the ISSUE-33 can be  
splitted in two
orthogonal concerns.

The 1st concern is to define an assignment between a new/mutiple  
device and the
UA targets and actions. This is usually done at the platform level,  
or at the UA
level, specifying preferences and settings with a specialized input
configuration languages.

The 2nd concern is to give access to a UA client side script to the  
new/multiple
device generated events which have not been addressed by an input  
configuration
defined by the 1st concern.

My impression is that the 1st concern should not be part of the DOM3EV
specification. The rationale is that input configuration is by itself  
a complex
issue comparable to some extent to the issue of "output  
configuration" which has
been addressed in part with stylesheet languages. Some day, if  
required by the
growing number of input methods and devices, it could be dealt  
specifically with
an input configuration language (ie. "input stylesheet language").
Such language for instance would allow the user to specify that his/her
second mouse emulates a mousewheel event, or that "shift-drag"
with the principal mouse emulates a mousewheel event on the focused  
element.

The 2nd concern is currently more an innovation than a  
standardisation of
existing implementations. My suggestion at that point would be to  
leave it as a
simple recommendation that UA should (or may) generate some  
CustomEvent events
for the extra devices (eg. a second mouse or keyboard) which have not  
been
configured by the platform or the UA (through user preferences or by  
default)
to emulate one of the devices of the abstract device model.

Stéphane S.
---

Received on Monday, 20 March 2006 19:13:06 UTC