[Bug 23259] Expose ticks in wheel events

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23259

Gary Kacmarcik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #2 from Gary Kacmarcik  ---
Now tracking as: https://github.com/w3c/uievents/issues/17

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 23259] Expose ticks in wheel events

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23259

Gary Kacmarcik gary...@google.com changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #1 from Gary Kacmarcik gary...@google.com ---
Moving to UI Events

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Wheel events

[Olli Pettay]

Hi Travis,


On 12/09/2008 02:15 AM, Travis Leithead wrote:

Pixel scrolling / line scrolling aren't intended purpose. They are describing 
the data browser gets from the operating

system.

At least on Windows-OS, this binding of pixel/line scrolling to a wheel event 
does not exist. I think that the design taken for the OS-level event provides 
good design guidance for how the event could be used inside of a web 
application:


From MSDN (http://msdn.microsoft.com/en-us/library/ms645617.aspx) --

wParam
The high-order word indicates the distance the wheel is rotated, expressed in 
multiples or divisions of WHEEL_DELTA, which is 120. A positive value indicates 
that the wheel was rotated forward, away from the user; a negative value 
indicates that the wheel was rotated backward, toward the user.


Windows doesn't have pixel/line scrolling but it *does* have page/line 
scrolling.
See http://msdn.microsoft.com/en-us/library/ms645601.aspx#_win32_The_Mouse_Wheel
and SPI_GETWHEELSCROLLLINES/SPI_SETWHEELSCROLLLINES
http://msdn.microsoft.com/en-us/library/aa932539.aspx


-Olli

Re: Wheel events

[Olli Pettay]

On 12/06/2008 02:32 AM, Travis Leithead wrote:

Why does a mouse-wheel event need to include information about scrolling?

Because OS (OSX at least) generates different kinds of events for different 
kinds of user interactions.
Pixel scrolling when user scrolls only a bit, line scrolling when some 
larger amount is scrolled.



I thought we already have specified a scroll event for this purpose?

That happens after something on the page has been scrolled. Mouse wheel events 
are dispatched
when user uses the wheel (for scrolling, or zooming or whatever the webapps 
want to do with wheel events.)



It seems to me that the act of scrolling is merely related to the default 
action of wheel event (which, according to the wiki, specifies a default action 
of mousewheel (which itself could cause the default action of dispatching a 
scroll event).

After re-reading the proposal on the Wiki,

Wiki doesn't have the version I prefer.


I'm convinced that we're making the whole wheelevent much too complicated. It's 
a wheel. The user rolls it.
If the event starts to make too many assumptions about what the intended 
purpose of the roll is (e.g., pixel scrolling, line scrolling, page scrolling, 
page navigations, etc.)


Pixel scrolling / line scrolling aren't intended purpose. They are describing the data browser gets from the operating 
system.




About collapsing deltaX/Y/Z... one of the reasons we like the three vs. 1 is that 
together they specify a coordinate in 3-dimensional space; a vector that could be used in 
the future to cleanly move/pan in 3-dimensional space. If we went with .delta/.detail 
then the same application would suffer from the jaggies when responding to 
events sequentially.

Good point. So one event which contains .deltaX/Y/Z.


-Olli



-Travis


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olli Pettay
Sent: Wednesday, October 01, 2008 4:46 AM
To: public-webapps@w3.org
Subject: Re: Wheel events


Hi all,

So version 3 got implemented in Mozilla, but in a bit modified way.
There are separate events for line scrolling and pixel scrolling.
In Mozilla the old DOMMouseScroll and a new, currently named
MozMousePixelScroll, but in this message I call those just lineScroll
and pixelScroll:

- If there is only pixel scrolling, dispatch a pixelScroll event
and scroll the current scrollable area unless .preventDefault() was
called.

- If there is only line scrolling, dispatch a lineScroll event, and
dispatch also a pixel scroll event if it is possible to convert line
data to pixel data. Scroll the scrollable area if .preventDefault()
wasn't called on either of those events.

- If there is both line scrolling and pixel scrolling, dispatch line
scroll and pixelScroll and scroll the scrollable are unless
preventDefault was called on either of those events.


This way applications which want to handle pixel scrolling, can always
get those events, and this doesn't break existing applications which
only want to handle line scrolling (Google maps etc.).
Dispatching only pixel scroll events wouldn't work because many
applications don't want to handle small scrolling and there isn't always
a good way to convert pixel scroll data to line scroll data.
So to help web apps, better to have separate events.

Note, currently in Mozilla there are separate wheel events for
horizontal and vertical scrolling and events have .axis property.

So
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-Events-eventgroupings-wheelevents
could be modified a bit. The event name tells whether scrolling is line
scrolling or pixel scrolling and it also specifies what .delta
means. If we want separate events for different axis, we could remove
.deltaX/Y/Z and have just one .delta and use .detail for axis and have
constants X_AXIS, Y_AXIS,  Z_AXIS. This way we could later, if wanted,
add support for pageScrolling and whatever and also add support for any
new axis or other features.

To make this work with existing implementations which have support
for mousewheel event, the spec could say something like:
A default action of user agent generated event objects of this type
causes implementations to dispatch a mousewheel event iff it supports
that event type and WheelEvent.type is lineScroll, WheelEvent.delta is
non-zero and WheelEvent.detail is WheelEvent.Y_AXIS.

I'm not sure what could be the right names for the events.
It is perhaps too easy to confuse 'lineScroll' and 'pixelScroll' with
totally different kind of event 'scroll'.

Not so much related to the new WheelEvent:
Note, if mousewheel event must be defined in DOM 3 Events (as a legacy
event, not obligatory to implement), there is still need to define what
its .wheelDelta means, because that doesn't tell how many lines or how
many pixels to scroll.

-Olli


Olli Pettay wrote:

Hi all,

there has been some discussion about how wheel event should work, and
what kind

Re: Wheel events

[Olli Pettay]

Hi all,

So version 3 got implemented in Mozilla, but in a bit modified way.
There are separate events for line scrolling and pixel scrolling.
In Mozilla the old DOMMouseScroll and a new, currently named 
MozMousePixelScroll, but in this message I call those just lineScroll

and pixelScroll:

- If there is only pixel scrolling, dispatch a pixelScroll event
  and scroll the current scrollable area unless .preventDefault() was
  called.

- If there is only line scrolling, dispatch a lineScroll event, and
  dispatch also a pixel scroll event if it is possible to convert line
  data to pixel data. Scroll the scrollable area if .preventDefault()
  wasn't called on either of those events.

- If there is both line scrolling and pixel scrolling, dispatch line
  scroll and pixelScroll and scroll the scrollable are unless
  preventDefault was called on either of those events.


This way applications which want to handle pixel scrolling, can always
get those events, and this doesn't break existing applications which
only want to handle line scrolling (Google maps etc.).
Dispatching only pixel scroll events wouldn't work because many 
applications don't want to handle small scrolling and there isn't always 
a good way to convert pixel scroll data to line scroll data.

So to help web apps, better to have separate events.

Note, currently in Mozilla there are separate wheel events for
horizontal and vertical scrolling and events have .axis property.

So
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-Events-eventgroupings-wheelevents
could be modified a bit. The event name tells whether scrolling is line 
scrolling or pixel scrolling and it also specifies what .delta

means. If we want separate events for different axis, we could remove
.deltaX/Y/Z and have just one .delta and use .detail for axis and have
constants X_AXIS, Y_AXIS,  Z_AXIS. This way we could later, if wanted,
add support for pageScrolling and whatever and also add support for any
new axis or other features.

To make this work with existing implementations which have support
for mousewheel event, the spec could say something like:
A default action of user agent generated event objects of this type 
causes implementations to dispatch a mousewheel event iff it supports 
that event type and WheelEvent.type is lineScroll, WheelEvent.delta is 
non-zero and WheelEvent.detail is WheelEvent.Y_AXIS.


I'm not sure what could be the right names for the events.
It is perhaps too easy to confuse 'lineScroll' and 'pixelScroll' with
totally different kind of event 'scroll'.

Not so much related to the new WheelEvent:
Note, if mousewheel event must be defined in DOM 3 Events (as a legacy 
event, not obligatory to implement), there is still need to define what
its .wheelDelta means, because that doesn't tell how many lines or how 
many pixels to scroll.


-Olli


Olli Pettay wrote:


Hi all,

there has been some discussion about how wheel event should work, and
what kind of information it should expose.
The current DOM 3 Events (editor) draft has the legacy mousewheel event
and also the new wheel event which has deltaX/Y/Z. The problem is
that what delta means (especially in the new wheel event).
Operating systems create events which may contain several kinds
of information - how many lines to scroll but also how may pixels.
Currently Safari seems to support also pixel scrolling, but doesn't 
dispatch events for events which don't have line scrolling = 1.
And that causes problems like 
http://mozilla.pettay.fi/moztests/pixelscrolling.mov


Web applications should be able handle that situation and IMO
should know what kind of wheel event just happened.
So either deltaX/Y/Z (I'm talking about the new event here, not the 
legacy event) should be always in pixel units (or fragment of such)

or the event should somehow have information about the units.
In latter the case there is the problem that same system event may
contain both pixel and line information. So either two DOM events
should be dispatch or one event should be able to carry information
about the different kinds of units.

But if the event contains only pixel information, web app can't know
how many pixels mean a line-scroll. And that is valuable when trying
to make web app to act like a native application.

So there are (at least) 5 options
1. only pixel delta
- Web app can't know what delta value means a line scroll
2. events with both line and pixel scroll information (maybe also page
scroll etc?)
- Web apps would get all the needed information in one event,
but the event interface would probably look pretty ugly
3. separate events for pixel scrolls and line scrolls
- Web app can't know whether user did one or two gestures
4. linked events; if the native event contains both line and pixel
data, dispatch one event for line delta and one for pixel data
but add some attribute to the event interface which links these
events together, something like
readonly attribute WheelEvent

Re: Wheel events (ISSUE-9)

[Markus Stange]

Doug Schepers wrote:
And that causes problems like 
http://mozilla.pettay.fi/moztests/pixelscrolling.mov


Can you provide some context for what is going on in that video?  What 
is the problem that illustrates?  Does it relate to the scrolling vs. 
zooming of the map?


The problem is that calling .preventDefault() on line scroll events 
doesn't have any effect on the pixel scroll events. So we need to 
dispatch pixel scroll events, too, in order to give web applications a 
reliable way to prevent scrolling.


Markus