RE: Wheel events

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

The wheel rotation will be a multiple of WHEEL_DELTA, which is set at 120. This is the threshold for action to be taken, and one such action (for example, scrolling one increment) should occur for each delta.

The delta was set to 120 to allow Microsoft or other vendors to build finer-resolution wheels in the future, including perhaps a freely-rotating wheel with no notches. The expectation is that such a device would send more messages per rotation, but with a smaller value in each message. To support this possibility, you should either add the incoming delta values until WHEEL_DELTA is reached (so for a delta-rotation you get the same response), or scroll partial lines in response to the more frequent messages. You could also choose your scroll granularity and accumulate deltas until it is reached.
--------------------------------------------------------------------

In summary, the OS-level wm_mousewheel event and its delta is _independent_ from any action to be taken by the application.

Specing pixel, line, etc., data into the W3C event just does not seem like ideal design for a new event (for which there would be no initial application compatibility)


-----Original Message-----
From: Olli Pettay [mailto:Olli.Pettay@helsinki.fi]
Sent: Saturday, December 06, 2008 7:44 AM
To: Travis Leithead
Cc: olli@pettay.fi; public-webapps@w3.org
Subject: Re: Wheel events

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: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] 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 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 relatedEvent;
>> or
>> readonly attribute WheelEventList relatedEvents;
>> 5. no pixel scrolling at all
>> - causes http://mozilla.pettay.fi/moztests/pixelscrolling.mov
>>
>> I just came up with the idea 4, need to think that a bit more.
>>
>>
>> -Olli
>>
> ....
>> Or 6.
>> Perhaps the type of deltaX/Y/Z shouldn't be just long.
>> It could an array of longs or an array of wheelrollvalues (whatever
>> those are).
>
>
>

Received on Tuesday, 9 December 2008 00:15:51 UTC