RE: ISSUE-30: mousewheel event

Hi, Matthew-

Matthew Raymond wrote:
| 
| >> [...] which have a wheel that is not necessarily connected 
| to a pointer at
| >> all. The Web is not just about desktop browsers anymore 
| [insert Web2.0
| >> buzzord/slogan here].
| 
|    Whether the wheel is a physical one connected to a mouse or not, it
| still should probably be associated with the pointer device.

Can you provide a rationale for that reasoning? They seem orthogonal to me.
I might tab to a focusable element that reacts to a wheel event, on a device
where there is no pointer.


| >> Additionally, most of the discussion seems to be revolving 
| (sorry) around
| >> HTML. In SVG, the wheel would more often be used to zoom 
| than to pan
| >> (scroll) since an SVG canvas is infinitely wide as well as 
| infinitely  
| >> long, and the document design constraints are different; 
| thus, I would
| >> expect that in a Compound Document, an UI might use the 
| wheel to scroll
| >> when over an HTML control or window, and zoom when over an 
| SVG (by default).  
| 
|    Here, you seem to unconsciously agree that the events in question
| would occur to elements under the pointer device. How else could you
| scroll "over" and HTML control?

Again, whether there is or is not a pointer is irrelevant to the wheel
event. I did assume for this illustrative example that there was a pointer,
but could just have easily used an example that has only a tab and a wheel,
or where the type of a standalone document determined the effect, or some
other example.

Please don't take the fact that there are mousewheels lead you to the
conclusion that there are no other wheels inputs.


| I don't know about that. If the UA has to pass an event to scripting
| without regard for how that same event is handled by the UA, you could
| end up with a situation where the web site handles input differently
| from the browser containing it, which is bad from a usability 
| standpoint.

It is not the place of a Spec to dictate or mandate how a UA or
document/webapp uses the events described. It only provides normative
conformance criteria. If I want my page to have all click events translate
the text into a different language, or have wheel events spawn images of
animated puppies running, then that's what I want my page to do. 


|    I think "mouse" is fine, because we have an established 
| precedent for
| using "mouse" in events related to the pointer device. You may have a
| point about "scroll", since it does narrow

I read and understood your posts, and I realize your position on this issue.
I just happen to disagree. Again, pointers and wheels are orthogonal.  


| > I do have to agree with this. Probably "wheel" is a proper 
| name for the  
| > event, instead of "DOMWheel".
| 
|    I disagree. "DOMWheel" (or "wheel") would obviously become 
| a superset
| of the "scroll" event if it's not associated with a pointer device. In
| that case, "mousewheel" may actually be the optimal name, oddly...

That's not true at all, for the reasons I stated in my original post.


|    I do think that a "DOMZoom" event might be useful. For instance, in
| SVG, you may want to hide certain details of a drawing when 
| you zoom out.

SVG already has a zoom event, for reasons like that one.

There must be an abstraction from the physical event and the DOM event.
Zoom, pan, and scroll are all DOM events that might be mapped to physical
events such as the pressing of specific keys or activation of various
physical interfaces, but they are not the same thing.

Regards-
Doug

doug.schepers@vectoreal.com
www.vectoreal.com ...for scalable solutions.

Received on Monday, 6 March 2006 05:31:50 UTC