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

Re: ISSUE-30: mousewheel event

From: Matthew Raymond <mattraymond@earthlink.net>
Date: Sun, 05 Mar 2006 22:30:14 -0500
Message-ID: <440BACC6.8010601@earthlink.net>
To: ROBO Design <robodesign@gmail.com>
CC: Doug Schepers <doug@schepers.cc>, public-webapi@w3.org

ROBO Design wrote:
> Le Sun, 05 Mar 2006 13:41:50 +0200, Doug Schepers <doug@schepers.cc> a  
> écrit:
>> I would like to point out that we need to accommodate not only existing
>> desktop/laptop devices, but also existing devices like phones,  
>> Blackberries, etc., [...]

   That was my line of thinking

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

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

>> Obviously, this is overrideable by the author via script, and depends
>> on the UA to determine what best fits their UI metaphor. It is not up
>> to DOM or WebAPI to dictate what a UA does with the event, just that
>> it makes the event available.

   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.

>> These arguments lead me to the conclusion that neither "mouse" nor  
>> "scroll" are applicable to this event.

   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

>> Since we are redefining what the behavior and syntax of the wheel is
>> anyway, and since implementation are inconsistent, I say that we should
>> just call it something with no legacy confusions. That way, existing
>> content that uses the non-standard method still works, and UAs that will
>> support the standard event will have a motivation to implement it
>> as specified, not just let their old behavior persist. Either "wheel" or
>> "DOMWheel" seems most appropriate to me; it is simple, descriptive, and
>> unlikely to be confused with anything else (unless DOM is extended to
>> driving cars).
> 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...

   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.
Received on Monday, 6 March 2006 03:30:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:20 UTC