W3C home > Mailing lists > Public > public-webapi@w3.org > June 2006

ISSUE-84: DOM3EV: partial custom mouse wheel scrolling

From: Web APIs Issue Tracker <dean+cgi@w3.org>
Date: Tue, 27 Jun 2006 19:45:51 +0000 (GMT)
To: public-webapi@w3.org
Message-Id: <20060627194551.12E8533201@kearny.w3.org>


ISSUE-84: DOM3EV: partial custom mouse wheel scrolling

http://www.w3.org/2005/06/tracker/webapi/issues/84

Raised by: Bjoern Hoehrmann
On product: DOM 3 Events

In http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0094 Ian
points out that the latest proposal for mouse wheel event types does
not appear to address "being able to override horizontal scrolling to
do script-based scrolling, but leaving vertical scrolling as being
handled by the UA" very well.

This use case is rather unclear to me; what is it that the author is
trying to achieve and avoid here? What we have is basically that there
are up to three (possibly related) rotational input devices; when one
or more of them have been rotated, you receive a notification with a
not very meaningful indication of "how much" they have been rotated.

This may or may not trigger scrolling. What should the application do
if the default action is not scrolling, or scrolling is for only one
of the deltas, not both as the use case seems to assume? How important
is it to know by how much the script should scroll if scrolling is
appropriate (currently you can only reverse-engineer some value that
works for you, but may not work for others)?

Is it important that this behavior is specifically attached to one of
the rotational devices or should it be attached to other scrolling
devices also (like keyboard, auto-scrolling by holding a key and moving
the mouse)? How does "script-based scrolling" work at all with e.g.
auto-scrolling?

As an example, in Internet Explorer the default action of mouse wheel
rotational input depends on various factors, e.g. which keys are
being pressed; with no keys pressed, you typically get scrolling, with
CTRL being pressed you change the text size settings, and with SHIFT
being pressed you can navigate back and forth through the history. It
is not clear to me why a user would want scrolling instead; how does
the use case handle that?

So all in all it's not clear to me how this use case is related to the
mouse wheel event types, it seems more like requesting scrolling preview
events.
Received on Tuesday, 27 June 2006 19:46:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:55 GMT